This is the second practitioner post regarding how AIOPs APIs can help you to automate and simplify operational tasks in DX Operational Intelligence. The first one was Leveraging DX Operational Intelligence APIs to Extract AIOps Insights. In this use case, we will cover how we can leverage service ingestion APIs to define a business service made of IT components and some best practices when working with service analytics.
Our starting point is a “living” AIOps data lake made of topology, logs, alarms, events, or unstructured data coming from multiple sources and domains.
You have been tasked to abstract the complexity and variety of this data by defining services that will connect the business to the underlying technology.
Service analytics will offer you and your customers a single pane of glass to visualize Health, Availability, and critical KPIs for your business.
Let’s see how to define a business service via API.
The image above displays the goal of the use case: two critical domains (a VM cluster and a key repository) that support your CDN service.
This service definition will bring you value with these key benefits:
It’s important to note that service analytics provides dynamic automated service discovery with attribute and graph-based traversal for creating a service. This means that AIOpss can import topology definitions from external services. This is a tremendous help to define business services from 3rd party tools.
Also, we can use the API or UI service definition to enrich or augment these imported services/topologies or simply to create a completely new business service.
Before jumping to the service definition API, let’s see first how we can ingest topology via API in our AIOps data lake.
Any AIOps solution should be flexible and elastic to accept data from multiple sources. DX Operational Intelligence can get data out of the box from connectors (pull or stream) or we can just ingest data via API to the data lake. In this section, we will cover how we can use ingestion APIs to insert a topology entity (database) that could be extracted from a customer database.
The ingestion API is very simple: it needs an authentication Tenant Bearer token and a JSON payload made of key-value pairs as shown below.
POST https://apmgw.dxi-na1.saas.broadcom.com/tas/graph/store
{
"ttl":null,
"graph":{
"edges":[],
"vertices":[
{
"attributes":{
"database": "oracle",
"name": "BusinessDeliveryBE",
"type": "backend",
"ipAddress": "10.23.31.31",
"classLabel": "premiumTier",
"owner": "Mark F.",
"hostname": "BusinessDeliveryBE",
"ci_unique_id": "322-backend",
"ITservice": "backend-business-delivery"
},
"externalId":"CUSTOM:MyexternalDatabase"
As you can see, we trigger a POST against our topology store endpoint, and the payload, in this case, is made of a single vertex (CI) and no edges (no relationships). The “ttl” or time to live defines for how long (in seconds) this element will live in our topology store (default 24 hours) and the “externalId” defines the layer and uniqueId of the ingested element. All the other attributes are optional key-value pairs to further describe our ingested entity.
We will use this ingested entity for our service definition in the next section.
Our parent service will be called “CDN-Service” and it will be made of two sub-services “VirtualEnv” (made of a VMWare cluster) and “BackendCDN” (made of the entity we just ingested in the previous section).
Any alarm impacting the sub-services will be propagated up to the parent “CDN-Service” to show how the business gets degraded when a subdomain is impacted.
The API call is just a POST against the endpoint of service analytics.
For authentication, we use a Bearer Token again. Details on how to get it are here.
Some key points about this API call:
POST https://doi.dxi-na1.saas.broadcom.com/oi/v2/sa/save
{
"vertices": [
{
"attributes": {
"name": "CDN-Service",
"state": "ACTIVE",
"root_service": [
"CDN-Service"
],
"tags": [
"CDN Business"
],
"location": "Boston",
"description": "CDN IT components",
"customProperties": [
{
"name": "businessOwner",
"value": "ACME"
}
]
}
},
{
"attributes": {
"name": "VirtualEnv",
"state": "ACTIVE",
"root_service": [
"CDN-Service"
],
"metrics": [],
"serviceContent": [
{
"query": [
{
"attributeName": "vmware.Cluster",
"attributeValue": "FranceCluster"
}
]
}
],
"tags": [
"Critical VMs"
],
"description": "VM cluster supporting CDN",
"customProperties": [
{
"name": "France Cluster"
}
]
}
},
{
"attributes": {
"name": "BackendCDN",
"state": "ACTIVE",
"root_service": [
"CDN-Service"
],
"metrics": [],
"serviceContent": [
{
"query": [
{
"attributeName": "ITservice",
"attributeValue": "backend-business-delivery"
}
]
}
],
"tags": [
"Backend for CDN"
],
"description": "HA repo for CDN",
"customProperties": [
{
"name": "CMDB ingested"
}
]
}
}
],
"edges": [
{
"targetExternalId": "VirtualEnv",
"attributes": {
"semantic": "AggregateOf",
"health_weight": 0.5,
"risk_weight": 0.5
},
"sourceExternalId": "CDN-Service"
},
{
"targetExternalId": "BackendCDN",
"attributes": {
"semantic": "AggregateOf",
"health_weight": 0.5,
"risk_weight": 0.5
},
"sourceExternalId": "CDN-Service"
}
]
}
Triggering this call will kick off the service definition in service analytics.
If things do not go as expected, do not panic: the deletion API is here to help and clean up. But as with any deletion API, use it with caution.
POST https://doi.dxi-na1.saas.broadcom.com/oi/v2/sa/service/status?recursive=true
{
"name": "CDN-service",
"action": "delete"
}
Some helpful best practices when working with service analytics APIs:
So we have seen how to define Business Services in DX Operational Intelligence by using Service Analytics APIs in a programmatically way. This is a great kick start to orchestrate and automate service definitions from the Broadcom AIOps platform.
For advanced usage and optional API, fields refer to the official documentation.
If you enjoyed this blog, visit our AIOps space on Enterprise Software Academy for additional resources.
