<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1110556&amp;fmt=gif">
April 20, 2021

Business Service Definition Made Easy via AIOps API

by: Nestor Falcon Gonzalez

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 Goal

 

ESD_CY21_Academy-SkillBuilder.Business Service Definition Made Easy via AIOps.Figure_01

Figure 1: The use case goal is a two-tier business service

 

 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:

  • A single pane of glass to see business health and availability
  • Quick identification of which part of the service is degraded (Network, App, Infra, Geo..)
  • Root cause analysis by leveraging ML/AI for noise reduction
  • Unified topology for the whole digital chain
  • Flexible service hierarchy to model IT services in the context of business and organization

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.

 

Data Ingestion via API

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.

 

Business Service Definition via API

 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:

  1. The JSON payload contains 2 blocks: vertices (services or sub-services) and edges (relationships).
  2. Each vertex is a collection of attributes. “Name”, “state” and “root_service” are mandatory fields.
  3. The “serviceContent” clause defines which CIs will belong to this service. For instance, the subservice “VirtualEnv” will contain all CIs that have an attribute “vmware.Cluster” equals to “FranceCluster”.

    This is extremely useful and powerful because we can build our services by matching labels of the elements existing in our data lake (e.g All CIs with “geo”=“europe”, “department”=“finance”, “deployment”=“version2.0”).
  4. Edges are made of a target, a source, and weights for health and risk, so you can customize the weight of each subservice to impact the health/risk of the parent.

 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"

}

 

Best Practices Creating Services via API

Some helpful best practices when working with service analytics APIs:

  1. Start small. Do not try to match a high number of CIs in the first runs of service creations via API/GUI.
  2. Plan carefully. Do not create services that nobody will look at. Having a big number of services (+1000) will introduce overhead and it will be hard to maintain.
  3. Make sure all your services/sub-services are relevant and abstract complexity from a virtual group: Geo, Business, Team, Technology, Domain or Host Groups are common sub service categories.
  4. You can start by creating your first service via UI, then exporting it to have a master reference for future API ingestions. To see all services definitions run this API call:
    GET https://doi.dxi-na1.saas.broadcom.com/oi/v2/sa/services
  5. Do not create a very deep layer of subservices unless necessary. This introduces complexity and it is not ideal for maintenance. We recommend keeping the depth at 3-4 levels max.
  6. Wherever possible use "IN" clauses in “serviceContent” to add exact entity names rather than regexes with "MATCH" clauses. Too many regexes can cause performance issues

 

Conclusion

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.