VMware Telco Cloud Service Assurance Event Example
In this example, events are coming in from Kafka in the VMware Telco Cloud Service Assurance format. The external data is coming in on a different topic. The Enrichment adds an event priority attribute to the VMware Telco Cloud Service Assurance events.
[
{
"type": "CISCO-ACI",
"instance": "KC-1",
"timestamp": 1573186658,
"processedTimestamp": 1573186659,
"metricType": "Interface-Statistics",
"properties": {
"dataSource": "10.100.10.10",
"deviceType": "Switch",
"deviceName": "Switch-1.1.1.1",
"entityType": "Port",
"entityName": "PORT-node-113/eth1/51-10.106.124.197"
},
"metrics": {
"metric-1": 2.71828,
"metric-2": 3.141592
},
"tags": {
"parent": "EPG::EPG-1|Switch::SW-1",
"model": "CAN-100",
"version": "1.0.0.1",
"customer": "customer-1",
"location": "Server Room A",
"city": "Ottawa",
"address": "24 Sussex Drive",
"zip": "K1M 1M4",
"region": "Canada",
"deviceCoordinates": "45.444348, -75.693934"
}
},
{
"type": "CISCO-ACI",
"instance": "KC-2",
"timestamp": 1573186658,
"processedTimestamp": 1573186659,
"metricType": "Interface-Statistics",
"properties": {
"dataSource": "10.100.10.10",
"deviceType": "Switch",
"deviceName": "Switch-1.1.1.1",
"entityType": "Port",
"entityName": "PORT-node-113/eth1/51-10.106.124.197"
},
"metrics": {
"metric-1": 2.71828,
"metric-2": 3.141592
},
"tags": {
"parent": "EPG::EPG-1|Switch::SW-1",
"model": "CAN-100",
"version": "1.0.0.1",
"customer": "customer-1",
"location": "Server Room A",
"city": "Ottawa",
"address": "24 Sussex Drive",
"zip": "K1M 1M4",
"region": "Canada",
"deviceCoordinates": "45.444348, -75.693934"
}
}
]
These two events are the same, except for having a different instance ID.
[
{
"key": "KC-1",
"data": {
"priority": "HIGH"
}
},
{
"key": "KC-2",
"data": {
"priority": "LOW"
}
}
]
For this example, an event coming in is given a priority of HIGH, if its instance ID is KC-1 and LOW if its instance ID is KC-2.
[
{
"type": "CISCO-ACI",
"instance": "KC-1",
"timestamp": 1573186658,
"processedTimestamp": 1573186659,
"metricType": "Interface-Statistics",
"properties": {
"dataSource": "10.100.10.10",
"deviceType": "Switch",
"deviceName": "Switch-1.1.1.1",
"entityType": "Port",
"entityName": "PORT-node-113/eth1/51-10.106.124.197"
},
"metrics": {
"metric-1": 2.71828,
"metric-2": 3.141592
},
"tags": {
"parent": "EPG::EPG-1|Switch::SW-1",
"model": "CAN-100",
"version": "1.0.0.1",
"customer": "customer-1",
"location": "Server Room A",
"city": "Ottawa",
"address": "24 Sussex Drive",
"zip": "K1M 1M4",
"region": "Canada",
"deviceCoordinates": "45.444348, -75.693934",
"priority": "HIGH"
}
},
{
"type": "CISCO-ACI",
"instance": "KC-2",
"timestamp": 1573186658,
"processedTimestamp": 1573186659,
"metricType": "Interface-Statistics",
"properties": {
"dataSource": "10.100.10.10",
"deviceType": "Switch",
"deviceName": "Switch-1.1.1.1",
"entityType": "Port",
"entityName": "PORT-node-113/eth1/51-10.106.124.197"
},
"metrics": {
"metric-1": 2.71828,
"metric-2": 3.141592
},
"tags": {
"parent": "EPG::EPG-1|Switch::SW-1",
"model": "CAN-100",
"version": "1.0.0.1",
"customer": "customer-1",
"location": "Server Room A",
"city": "Ottawa",
"address": "24 Sussex Drive",
"zip": "K1M 1M4",
"region": "Canada",
"deviceCoordinates": "45.444348, -75.693934",
"priority": "LOW"
}
}
]
Both events have been given a priority tag based on their instance ID.
Enrichment Usage on the Multi-tenancy Use Case
In the previous example, we can see that customer information is enriched to the metrics by the Enrichment function. Besides the metrics, the Enrichment service can also enrich the Event records in the same way as the metric records are enriched. After the events are enriched, the user can see the enriched information in the event dashboard.
For example, the following diagram shows that the customer information is displayed in the dashboard for the admin user (the admin user can see all of the data of the tenants):
If the user is logged in as customer-1, the dashboard shows only the events for customer 1.
Matching Multiple Keys to External Data
Official regex is not currently supported, but there is a workaround to match multiple event-keys to external data using "contains".
Consider the following event-key:name.contains('IPNET') ? 'IPNET' : name.contains(’10.107’) ? ’10.107’ : ‘’
{"key":"IPNET","data”:{"location":"Bangalore”,“customer”:”SITA”}}
{"key”:”10.107”,”data”:{"location":"UK”,“customer”:”VF”}}
If 'IPNET' is anywhere in the name field, it can match with the external data that has key 'IPNET'. Likewise, if ’10.107’ is anywhere in the name field, it can be matched with the external data that has the key '10.107'.
So in this example, any events with names such as "IPNET", "IPNET/ROUTERA", or "NODE-A-IPNET-1" can be enriched with "location":"Bangalore” and “customer”:”SITA”, and any events with names such as "10.107", "10.107.20.10", or "IP-10.107.30.145" can be enriched with "location":"UK” and “customer”:”VF”.
