@@ -73,9 +73,9 @@ There is a dedicated endpoint which starts an automated graph monitoring script,
constantly executing a full processing pipeline - build temporal graph, query for end-to-end delay, write results bach in InfluxDB, delete
temporal graph. The pipeline uses the defined configuration to periodically build the temporal graph and query for the end-to-end delay
from all possible UEs to every deployed service function endpoint and writes the result back into a dedicated measurement in the time-series database (InfluxDB).
For more information on the graph monitoring pipeline, see the [graph RTT slides](https://owncloud.it-innovation.soton.ac.uk/remote.php/webdav/Shared/FLAME/Project%20Reviews/2nd%20EC%20Review%20(technical)/drafts/WP4_FLAME_Graph_RTT.pptx).
For more information on the graph monitoring pipeline, see the relevant section below.
"response_time_field":"<field measuring the service delay of a service function - as described above>",
"request_size_field":"<field measuring the request size of a service function - as described above>",
"response_size_field":"<field measuring the response size of a service function - as described above>",
"measurement_name":"<the name of the measurement which contains the fields above>"
},
...
}
}
```
`curl -X POST -d <JSON body> http://platform/clmc/clmc-service/graph/temporal`
The CLMC would then build the temporal graph in its graph database (Neo4j) and populate it with the time-series data valid for the defined time window.
#### Querying the temporal graph
The temporal graph built in the previous step can be used to retrieve the end-to-end delay by sending a GET request to the
**/clmc/clmc-service/graph/temporal/{uuid}/round-trip-time?starpoint={ue, cluster or switch}&endpoint={service function endpoint}**.
This endpoint requires the UUID of the temporal graph received in the response from the previous step, as well as a UE and service function endpoint identifiers.
The query is, thus, configured to return the end-to-end delay from a particular UE (User Equipment) to a particular service endpoint deployed on the FLAME platform.
For example:
`curl -X GET http://platform/clmc/clmc-service/graph/temporal/ac2cd21c-9c36-44ea-a923-51ca3f72bf7a/round-trip-time?startpoint=ue20&endpoint=fms-storage-endpoint`
The automated graph monitoring process (described in the previous sections) executes this query for every possible pair of a UE and a service function endpoint to
ensure that all metrics are collected.
#### Writing results in InfluxDB
The response of the previous requests will contain metrics such as round-trip-time, network delay and service delay. These are returned in JSON format
which must then be converted to the InfluxDB line protocol format. An example would look like:
The graph monitoring process described in the beginning of this document automates the steps described above. When defining a query period, e.g. 30 seconds,
the process will start executing the pipeline every 30 seconds, by defining a non-overlapping, contiguous time windows. For each time window, a temporal graph is built,
then queried for end-to-end delay and finally deleted.