...
In this case it refers to monitoring the data that the participants will provide to DMaaP. Participants will send events to DMaaP which will be pulled by the CL_MonitoringSupervision_Service in to the runtime database. Monitoring service provides APIs to display the statistics data from runtime database to the Monitoring GUI. The data provided should include a reference id to the control loops that are instantiated on the participant, as well as the applications that have been instantiated as a part of that control loop for that participant. Data should also include the time that the application has started, state of it (running/terminated) and any other critical information which would help to determine the health of an instantiated control loop and its components. Idea is for the participant to provide events every certain period of time, similar to a health-check, in order to provide consistent monitoring.
...
| PlantUML Macro | ||
|---|---|---|
| ||
@startuml control CL_Instance_Control database Runtime_DB participant Monitoring_Service participant DMaaP collections Participants CL_Instance_Control -> DMaaP : INSTANTIATE Event (JSON/Yaml) Participants -> DMaaP : Pulls its part of CL and starts instantiation of components Participants -> DMaaP : Starts sending monitoring events once instantiation of components begins note over DMaaP : Events are sent at set intervals MonitoringSupervision_Service service-> DMaaP : Consistently pulls events off the monitoring topic Monitoring_Service -> Runtime_DB : Puts and updates the monitoring data on the DB @enduml |
...
| PlantUML Macro | ||
|---|---|---|
| ||
@startuml actor Client participant Commissioning_API control CL_Instance_Control database Runtime_DB participant Supervision_Service participant Monitoring_Service participant DMaaP collections Participants ==Instantation== Client -> Commissioning_API : Fetch all Commissioned Control Loops Commissioning_API -> Runtime_DB : Rest call to get Commissioned Control Loops Runtime_DB -> Commissioning_API : Return Commissioned Control Loops Commissioning_API -> Client : Provide the data Client -> Client : Select CL for instantiation and provide config Client -> CL_Instance_Control : Instantiate CL POST REST API call alt case where Client sends commissioned CL id instead of the full CL in the body CL_Instance_Control -> Runtime_DB : Fetch the Commissioned Control Loop from Models table Runtime_DB -> CL_Instance_Control : Return the requested Commissioned Control Loop data end CL_Instance_Control -> DMaaP : INSTANTIATE Event (JSON/Yaml) note over CL_Instance_Control, DMaaP : List of Participant ID's containing Participant Metadata Blocks Participants -> DMaaP : Pulls its part of CL and tries to Instantiate ==Monitoring== Participants -> DMaaP : Starts sending monitoring events \nOnce instantiation of components begins note over DMaaP : Events are sent at set intervals, one per participant MonitoringSupervision_Service -> DMaaP : Consistently pulls events off the monitoring topic Monitoring_Service -> Runtime_DB : Puts and updates the monitoring data on the DB ==Supervision== Supervision_Service -> Runtime_DBDMaap : Periodic check on monitoring data alt CL successfully instantiated Supervision_Service -> Client : Return Instantiation Successful else CL failed to instantiate ... TIMEOUT CL state not changed to INSTANTIATED ... Supervision_Service -> CL_Instance_Control : Timeout, error occured CL_Instance_Control -> DMaaP : TEARDOWN Event (JSON/Yaml) Participants -> DMaaP : Pulls its part of CL and starts Teardown note over Monitoring_Service : Monitoring Service receives events and updates state note over Supervision_Service : Supervision Service finds that status has changed Supervision_Service -> Client : Return Instantiation Failed (http code and an error message) end @enduml |
...