(CTTC) Separation of Monitoring
Proposers
- Waleed Akbar (CTTC)
- Panagiotis Famelis (Ubitech)
- Lluis Gifre (CTTC) [reviewer]
Description
A separation of the collection of data and their analyses is proposed. As it stands now, Monitoring component collects monitoring data from devices and also includes an alarm mechanism. The idea is to disentangle these two areas, following the ETSI ZSM architecture. Monitoring component should only collect data, store them and expose an API to provide those data. Analytics component will include any analysis that may be done on them, from simple threshold-based alarms, to complex statistical analysis and potentially ML. The first step towards this separation is to port the alarm manager, as it is now, i.e., with a simple threshold-based alarm system, to its own component. Following that, an abstraction layer with an accompanying API should be developed, which will allow the expansion of Analytics with a plethora of different algorithms. Beginning with simple statistical analysis (i.e. smoothing, simple regression, etc.) and potentially continuing to the domain of ML algorithms, tailored for specific needs.
Demo or definition of done
The issue should be considered done, when the alarm mechanism from Monitoring has been ported to its own component and integrations with other components has been resolved.
Acknowledgements
This work is funded by the European Commission through the HORIZON-JU-SNS-2022 FLEX-SCALE project with Grant Agreement number 101096909.
References
- Zero-touch network and Service Management (ZSM);Closed-Loop Automation
- Flex-Scale project: D5.1 - Preliminary design of sustainable transport SDN control enablers for 6G
Feature Design (for New-Features)
Clarifications to Expected Behavior Changes
The gRPC calls of Monitoring related to alarms will be ported to the new Analytics components:
- MonitoringService/SetKpiAlarm
- MonitoringService/GetAlarms
- MonitoringService/GetAlarmDescriptor
- MonitoringService/GetAlarmResponseStream
- MonitoringService/DeleteAlarm
In that way Monitoring will have three functionalities:
- Collect KPI values
- Register KPI
- Provide KPI monitors
Analytics component should be developed in a way that is extensible. That means that the first iteration should be about KPI Alarms based on thresholds, but in the future it should support other type of more sophisticated analytics. For that reason, it is possible that the existing protobufs will be changed to allow better descriptions.
Assumptions
Analytics depends on the Monitoring component to be deployed. This issue is not currently blocked by any other issue, to the best of our knowledge. If an issue arises regarding Monitoring component, it should be compared to this one and tied to the appropriate component Monitoring or (new) Analytics, respectively.
Impacted Components
Policy Any other component that uses the Alarm mechanism.
Policy Impact
With the Alarm mechanism moving to another component, Policy should implement an Analytics client and port any interaction with the monitoring to that client.
Testing
To test that the Analytics component is working correctly, a test case that already uses its alarm mechanism can be altered. A prime candidate for that is the HPSR23 demo (p4 demo), that involves Policy.
The steps taken should be the following.
- A KPI is registered to the Monitoring component
- An alarm on that KPI is registered to the (new) Analytics component with a specific threshold
- A change in the KPI values is implemented, which goes over the threshold
- An alarm is raised by the (new) Analytics components
Following the HPSR23 demo, the KPI could be latency of a service.