@@ -388,6 +388,18 @@ The Graph API includes a number of interfaces for managing a graph representing
All of this is automated in what is called the graph pipeline bash script located at **scripts/clmc-service/graph-pipeline.sh**. Whenever graph-based monitoring is requested through the CLMC service API, this script is ran in the background in a child process (the CLMC application server is the parent process). The graph API allows certain level of control operations over this process - start, stop and fetch status.
In current implementation, we still have two manual steps to perform after each platform deployment:
* Edit the **src/service/resources/GraphAPI/network_clusters.json** file (on the CLMC container) which maps the IP address of a service router to the host name of the cluster that is connected to this service router
* Edit the **src/service/resources/GraphAPI/network_ues.json** file (on the CLMC container) which maps the IP address of a service router to the host name of a user equipment that is connected to this service router
Afterwards, the platform operator must build the network topology graph by either:
* sending a post request to the graoh API - `curl -X POST http://<clmc-host>/clmc-service/graph/network`
* running a bash script (on the CLMC container) that continuously rebuilds the network topology, thus updating latency measurements received from the SDN controller - `graph-network-topology.sh &`
Requesting graph-based monitoring then is as simple as sending a JSON configuration to the CLMC service API. See the API documentation for more details on this.
#### Implementation details of the Alerts API
The Alerts API is implemented on top of the Kapacitor HTTP API and includes the following main parts: