Overview
The System Management Agent is the microservice with which other systems or services communicate and to which they make management requests. The System Management Agent communicates with the other Edge Xpert microservices or the System Management Agent Executor to satisfy the requests. Essentially, the System Management Agent serves as the connection point of management control for Edge Xpert.
The System Management Agent default routes requests as follows:
-
Metric requests to the System Management Agent Executor
-
Operations to start, stop, restart and remove services to the System Management Agent Executor
-
Service metrics and configuration requests to the relevant Edge Xpert service
Docker can provide the requester with service metrics, such as memory and CPU use.
Configuration Properties
System Management Agent has the following properties:
- General: General properties provide general system management configuration settings.
The general properties are described in the following table:
| Property | Description |
|---|---|
| ExecutorPath | Specifies the path to the executor used for system management requests that are not configuration requests. Default is /sys-mgmt-executor |
| MetricsMechanism | specifies whether to use the direct-service or executor to tell the Service Management Agent where to go for service metric information.
executor |
For details of the configuration properties that are common to all services, see Common Configuration on EdgeXFoundry Document.
Example API Calls
The following examples show requests and the responses provided by the System Management Agent to the caller.
Service Metrics Example
The request for the metrics of the core command and core data services would be as follows:
GET /api/v2/system/metrics?services=core-command,core-data
The response, in JSON format, would be as follows:
[
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-data",
"metrics": {
"cpuUsedPercent": 0.03,
"memoryUsed": 6328156,
"raw": {
"block_io": "508kB / 0B",
"cpu_perc": "0.03%",
"mem_perc": "0.15%",
"mem_usage": "6.035MiB / 3.842GiB",
"net_io": "65.2kB / 55.7kB",
"pids": "6"
}
}
},
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-command",
"metrics": {
"cpuUsedPercent": 0.03,
"memoryUsed": 5541724,
"raw": {
"block_io": "0B / 0B",
"cpu_perc": "0.03%",
"mem_perc": "0.13%",
"mem_usage": "5.285MiB / 3.842GiB",
"net_io": "53.4kB / 42.5kB",
"pids": "6"
}
}
}
]
Service Configuration Example
The request for the configuration of the core data service would be as follows:
GET /api/v2/system/config?services=core-data
The response, in JSON format, would be as follows:
[
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-data",
"config": {
"apiVersion": "v2",
"config": {
"Clients": {
"core-metadata": {
"Host": "edgex-core-metadata",
"Port": 59881,
"Protocol": "http"
}
},
"Databases": {
"Primary": {
"Host": "edgex-redis",
"Name": "coredata",
"Port": 6379,
"Timeout": 5000,
"Type": "redisdb"
}
},
"MessageQueue": {
"AuthMode": "none",
"Host": "mqtt-broker",
"Optional": {
"AutoReconnect": "true",
"ClientId": "core-data",
"ConnectTimeout": "5",
"KeepAlive": "10",
"Qos": "0",
"Retained": "false",
"SkipCertVerify": "false"
},
"Port": 1883,
"Protocol": "mqtt",
"PublishTopicPrefix": "edgex/events/core",
"SecretName": "mqtt-bus",
"SubscribeEnabled": true,
"SubscribeTopic": "edgex/events/device/#",
"Type": "mqtt"
},
"Registry": {
"Host": "edgex-core-consul",
"Port": 8500,
"Type": "consul"
},
"SecretStore": {
"Authentication": {
"AuthToken": "",
"AuthType": "X-Vault-Token"
},
"DisableScrubSecretsFile": false,
"Host": "localhost",
"Namespace": "",
"Path": "core-data/",
"Port": 8200,
"Protocol": "http",
"RootCaCertPath": "",
"SecretsFile": "",
"ServerName": "",
"TokenFile": "/tmp/edgex/secrets/core-data/secrets-token.json",
"Type": "vault"
},
"Service": {
"CORSConfiguration": {
"CORSAllowCredentials": false,
"CORSAllowedHeaders": "Authorization, Accept, Accept-Language, Content-Language, Content-Type, X-Correlation-ID",
"CORSAllowedMethods": "GET, POST, PUT, PATCH, DELETE",
"CORSAllowedOrigin": "https://localhost",
"CORSExposeHeaders": "Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma, X-Correlation-ID",
"CORSMaxAge": 3600,
"EnableCORS": false
},
"HealthCheckInterval": "10s",
"Host": "core-data",
"MaxRequestSize": 0,
"MaxResultCount": 1024,
"Port": 59880,
"RequestTimeout": "5s",
"ServerBindAddr": "",
"StartupMsg": "This is the Core Data Microservice"
},
"Writable": {
"EventMaxLimit": 1000,
"InsecureSecrets": {
"DB": {
"Path": "redisdb",
"Secrets": {
"password": "",
"username": ""
}
}
},
"LogLevel": "INFO",
"PersistData": true
}
}
}
}
]
Service Operation Example
The request for the services operation would be as follows:
POST /api/v2/system/operation
[
{
"apiVersion":"v2",
"action":"start",
"serviceName":"core-data"
},
{
"apiVersion":"v2",
"action":"stop",
"serviceName":"core-command"
},
{
"apiVersion":"v2",
"action":"restart",
"serviceName":"core-metadata"
}
]
The response if the operation was successful, in JSON format, would be as follows:
[
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-data"
},
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-command"
},
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-metadata"
}
]
Service Health Check Example
The request for a health check of core data and support-notifications would be as follows:
GET /api/v2/system/health?services=core-data,support-notifications
The response, in JSON format, would be as follows:
[
{
"apiVersion": "v2",
"message": "support-notifications service is not registered. Might not have started... ",
"statusCode": 404,
"serviceName": "support-notifications"
},
{
"apiVersion": "v2",
"statusCode": 200,
"serviceName": "core-data"
}
]
Note
Health check requires Registry service to be up and running
For further information on the system agent API, see API Documentation