If you want to monitor the health status of yuuvis® RAD including visualizations and notifications, the metrics-manager is your best choice. However, if you already have your own (company wide) monitoring system like Nagios or alike, then http API endpoints are probably more what you are looking for. This page describes for each component of yuuvis® RAD in detail which endpoints you can use and which information you get out of it.
...
- http response 200 with body: {"status": "UP"} → this means the service itself an all dependencies are available and running correctly.
- http response 200 with body: {"status": "DOWN"} → this means either the service itself and/or one / multiple dependencies are not available or not working correctly.
- connection refused → service is not available → → this means the service is either not started / crashed or it is not working correctly.
Attention: The structure microservice behaves differently and even reports status "UP" when one or more of its dependencies is "DOWN". The depencies are listed in the body and show which one is "UP" or "DOWN".
An overview of all possible microservices including their ports or port-ranges can be found here: https://help.optimal-systems.com/yuuvisRAD/v60/admin/de/architecture/microservices/mic_ref_uebersicht-microservices.htm
...
Alternatively the admin-microservice offers an API endpoint that aggreagates all states together: http://<service-manager-ip>:7273/applications
If the admin-service itself is up and running correctly the call returns a an http response of 200 and a body like below.
...
| Note | ||
|---|---|---|
| ||
Unfortunately in the currently used version of the admin-servicethere service there is a bug that prevents the admin-service from obtaining and thus returning correct states from some or all of the microservices. When this bug happens, the services.log log file will contain outputs from the admin service as follows: adminservice.7273 : 2021-01-26 17:36:58.101 ERROR 8628 --- [freshExecutor-0] d.c.b.a.s.c.d.InstanceDiscoveryListener : Unexpected error. In this case you can not rely on the returned states. The problem can be resolved by restarting the admin-service but it can happen again at any time. |
Rendition-Plus
The health status of rendition-plus can be queried just like a microservice of the service-manager (see above) by using this URL: http://<rendition-plus-ip>:8090/osrenditioncache/app/management/health.
If rendition-plus is DOWN the microservice renditon-sidecar will also be DOWN and vice versa.
Elasticsearch
The health status of elasticsearch can be queried by calling this URL: http://<elasticsearch-ip>:9200/_cat/health
The endpoint requires authorization. If the connection is not refused (elaasticsearch is offline) and the authorization is correct, a an http response of 200 and a body like below will be returned.
[
{
"epoch": "1611682123",
"timestamp": "17:28:43",
"cluster": "es-red",
"status": "green",
"node.total": "1",
"node.data": "1",
"shards": "11",
"pri": "11",
"relo": "0",
"init": "0",
"unassign": "0",
"pending_tasks": "0",
"max_task_wait_time": "-",
"active_shards_percent": "100.0%"
}
]
The values of "status" and "active_shards_percent" determine the health of elasticsearch.
...