Topology Modeling using Agile Service Manager: A tutorial.

Pictures say a thousand words. A Topology View does wonders to the observability of your IT or cloud environment.

Over the past few months, I have been working with a topology tool called Netcool Agile Service Manager (ASM) and have been quite surprised at how easy it is to use. So, I thought of writing a blog series to share the experience. As this is the first blog in the series on Topology Modeling, this blog will be more of a tutorial. It is the “hello world” equivalent to learning a programming language.

Let us start by looking at a typical Event Management dashboard in an Operation Centre. Typically, when something goes wrong, the dashboard is often flooded with a stream of events. Something like

- Database Server XXX heartbeat check: not accessible.
- Router A Interface 1 failed ping check.
- Web Server YYY heartbeat check: not accessible.
- Database Server ZZZ: not accessible
- Router A Power Module Going Down.
- Web Server WWW heartbeat check: not accessible.
- Router B Interface 2 failed ping check.

If you are the operation engineer, what is the first thing you need to do to bring everything back to normal? The web server might be customer facing, so you might start addressing the issue there first; but, is it the right one? Without any insight knowledge, it is hard to determine which component you should be troubleshooting first.

If you have the topology of the environment, however, you can visually find the possible Root Cause much faster. Consider if you have the following topology available:

From the above topology, the monitoring server is connected to Router A. One of the events says that Router A Power Module failed. That explains why the Monitoring Server has lost its connectivity to all other components. Fixing the power module at router A most likely will resolve all other events. Topology view saves the day.

The Tool.

To build the previous topology, I was using an IBM application called Agile Service Manager (ASM), a component of Netcool Operation Insight (NOI).

ASM comes with a set of out-of-the-box data ingestion components that allows you to discover the topology of a lot of solutions such as OpenStack, VMWare vCenter, New Relic, Dynatrace, etc. The focus of this blog, however, is on how to build the topology from scratch, so I will not be using these out-of-the-box topology solutions. In fact, the first topology that I will go through has nothing to do with the Information System; I will go through building a simple organization chart.

The building block of a topology.

What makes up a topology? Let us start with a node representing a resource. For an organization chart, a node is a person.

We can describe a resource using JSON, it looks like this:

{
  "uniqueId": "Adam",
  "name": "Adam Dynamic",
  "type": "person"
}

A resource can have many properties. We start with a small set: a name, a type, and an UniqueId, so we can uniquely identify the resource.

To create a topology the resource needs to be connected to another resource. The connection has a direction. A Manager manages a person. The manage connection or relationship has a direction from a manager to a person. Using JSON to represent it:

{
"uniqueId":"Joe",
"name":"Joe Topo",
"type":"manager"
}
{
"from":"Joe",
"type":"manages",
"to":"Adam"
}

What we have now is a simple organization chart with one manager and one person.

It is useful for a resource to have a status. For an organization chart modelling point of view, the status of a person can be his/her availability. When somebody is on Leave let us display the person’s icon in yellow. We can represent the state as follow:

{
  "status": "Availability",
  "state": "open",
  "description": "Currently On Leave",
  "severity": "minor"
}

We want the status to have a state and severity. The state can be open (valid) or closed (no longer valid). The severity gives the model its color. Yellow is the color of a minor severity in the Netcool Operation Insight (NOI) Event Management tool, in which ASM is a component of.

A resource also may have a snapshot. This is valuable if we want to use the topology to represent the ever-changing cloud infrastructure. We will later see an example of this.

From JSON to topology.

We have modeled a simple organization chart with one person and one manager in JSON. Let us now use ASM to build the topology. We will write the JSON model into a text file and then will ask ASM to build the topology from it.

First, we need to adjust the previous generic JSON representation to something that ASM recognize, this is how ASM will understand a resource:

V:{
  "uniqueId": "Adam",
  "name": "Adam Dynamic",
  "entityTypes": [
    "person"
  ],
  "matchTokens": [
    "adam",
    "adam dynamic"
  ]
}

Where:

• V = Vertex. It represents the resource.
• entityTypes is the resource type represented as a list. The list allows a resource to have more than one type.
• matchTokens is used in searching and matching it with the Events. It is a list as well, so the resource can be matched in multiple ways.

For the manager, let us combine the declaration of the resource with its relationship and status:

V:{
  "uniqueId": "Sam",
  "name": "Sam Topo",
  "entityTypes": [
    "person",
    "manager"
  ],
  "matchTokens": [
    "sam",
    "sam topo"
  ],
  "_status": [
    {
      "status": "Availability",
      "state": "open",
      "description": "Currently On Leave",
      "severity": "minor"
    }
  ],
  "_references": [
    {
      "_toUniqueId": "Adam",
      "_edgeType": "manages"
    }
  ]
}

The status (_status) and the relationship (_references) are also lists.

So far the JSON had been written to increase its human readability. ASM, however, expects the resource (vertex) to be expressed in a single line. As an example, the first resource needs to be written like this:

V:{"uniqueId":"Adam","name":"Adam Dynamic","entityTypes":["person"],"matchTokens":["adam","adam dynamic"]}

We then need to tell ASM through its File Observer configuration where we wrote the 2 vertices as shown in the screenshot:

Now we can run the ASM File Observer and view the topology through ASM’s Topology Viewer:

Just to show possible customization, I have chosen to represent the manager with a dollar sign in a light bulb icon. The green tick mark and the orange exclamation point at the top right of the icons represent the severity of the resource.

As we saw at the beginning of this blog, Event Management supported by Topology View can accelerate your problem resolution. Just to give you a taste of the integration, ASM can automatically forward the resources’ status to the Event Management System. We can see in the following screenshot, the minor event, representing Sam currently on Leave, had been forwarded by ASM and is displayed in the Event Management dashboard. This integration will be explored further in this series’ future blogs.

So, we have gone through some simple steps of building a topology by specifying the resources and their relationship in JSON and writing them in a text file. To build a more complex topology with more resources, we just need to specify more Resources and their Relationships in the file and re-run the ASM file observer.

Dynamic Topology.

As mentioned earlier one constituent of a resource is its snapshot. Let us see how this can be useful.

Assume that Adam has a promotion, and he is being replaced by Mary Logy. To represent this, I changed the content of my text file to the following three lines:

V:{"uniqueId":"Mary","name":"Mary Logy","entityTypes":["person"],"matchTokens":["mary","mary logy"]}
V:{"uniqueId":"Sam","name":"Sam Topo","entityTypes":["person","manager"],"matchTokens":["sam","sam topo"],"_status":[{"status":"Availability","state":"open","description":"Currently On Leave","severity":"minor"}]}
E:{"_fromUniqueId":"Sam","_edgeType":"manages","_toUniqueId":"Mary"}

Note the last line. We have now separated the relationship into a line by itself and started the line with an “E:”. It is easier to maintain the model if we keep the definitions of the relationship separate. This is similar to a database table normalization concept. The “E:” stands for Edge, the relationship in ASM.

Running the ASM file observer again, we get a new topology.

But here is the good part. Remember we mentioned that a resource may include snapshots? ASM keeps that snapshots. We can ask ASM to display and compare two snapshots of the model by turning ASM Topology Views’ Delta option on. If we do that, we got the following:

Adam’s icon is displayed shaded with dotted lines and a negative sign on its top left-hand corner. Sam Topo does not experience change, the icon is displayed normally without any negative or positive sign. Mary Logy is a new addition to the model; her icon has a positive sign.

Pictures say a thousand words. A series of pictures capture the past. It allows us to go back in time and see what changes. In the ever-changing cloud environment, snapshots of the topology are a valuable problem management tool.

Summary.

In this blog, we have gone through the simple steps in building a dynamic topology using JSON and ASM. In my next blog, I will use a script to create the topology. The script will make REST API calls to ASM, allowing the topology to be created from another application.

Bring your plan to the IBM Garage.

Are you ready to learn more about working with the IBM Garage? We’re here to help. Contact us today to schedule time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development and startup communities we work in, and the deep expertise and capabilities we bring to the table.

Schedule a no-charge visit with the IBM Garage.