Monitoring Spec Example

The following model exemplifies a configuration intended to be created by Vertical Slicer and posted to an endpoint from MDA:

{
    "transaction_id": "ab51f3e1-7b61-4f9d-85a4-9e9f366b593b",
    "instance_id": "15cce067-4818-4afc-b0f8-0e4a1babf753",
    "product_id": "10",
    "tenant_id": "domain-operator-a",
    "context_ids": [
        {
            "resource_id": "10",
            "network_slice_id": "15cce067-4818-4afc-b0f8-0e4a1babf753",
            "parent_id": "10"
        }
    ],
    "topic": "operator-a-in-0",
    "monitoring_endpoint": "http://172.31.8.183:4500/osm/api/v1/query",
    "data_source_type": "OSM",
    "timestamp_start": "2022-03-14T14:30:00",
    "timestamp_end": "2022-05-14T14:30:00",
    "metrics": [
        {
            "metric_name": "osm_requests",
            "metric_type": "numerical",
            "step": "1m",
            "aggregation_method": "AVG",
            "step_aggregation": "2m"
        }
    ]
}

Resource Monitoring information

Parameter	Type	Description
transaction_id	String	Unique Business Flow UID which represents the transaction in hand.
instance_id	String	Instance ID.
product_id	String	Product ID.
tenant_id	String	Tenant ID.
resource_id	String	Unique ID of resource for which we are collecting monitoring data.
network_slice_id	String	ID of the network slice.
parent_id	String	ID of the parent entity (e.g., NS ID of the VNF, Slice ID of the NS).
topic	String	Kafka topic name where to report and push the encrypted hashed data.
monitoring_endpoint	String	(per resource) URL for whom we are fetching the metric values.
data_source_type	String	Type of data source.
timestamp_start	Datetime	The time at which the configuration starts.
timestamp_end	Datetime	The time when the configuration is finished.
metric_name	String	Name of metric being monitored.
metric_type	String	Type of metric being monitored.
step	String	Metric reading interval.
aggregation_method	String	Type of aggregation method.
step_aggregation	String	Metric readings aggregation interval.

The resourceID represents the resource for which we are collecting monitoring data. If the resource used to be part of one SLA and is now part of another SLA, it may make sense to use a distinct resourceID for the different epochs, so that data from one epoch is not used to influence decisions in another epoch. The referenceID might be the SLA identifier to which this resource is dedicated and is used to look up all relevant monitoring data for that reference. The monitoring data provided to postMonitoringData() should be a list of such structures, with one entry per metric being recorded.