AMP CMDB

AMP CMDB components split into discovery policy, exporter policy and supporting script which form an integration toolchain for integration of applications between AMP and CMDB. Such a split allows customization of application data in the middle of integration pipeline.

Application data

Application data can differ vastly from CMDB to CMDB. Therefore, CMDB application name and CMDB application ID is a bare minimum required to achieve basic integration with AMP. See data model of each policy below.

Policies

Both discovery policy and exporter policy share the same configuration set: command, env, period, start.sensor where command is mandatory.

command is a shell command that takes input, produces output and can be parametrized with environment variables - env. The following command example demonstrates flexibility of forming data pipeline for discovery policy to consume, in particular, applications to integrate filtered by name with command-line JSON processor - jq:

The role of the command and way that is used on the policies are designed for offering the maximum flexibility for integrating AMP with high configurable external tools.

Cloudsoft can provide by arrangement a script for connecting AMP to multiple AWS accounts and multiple ServiceNow instances configuring profiles.

command: cat $CMDB_FILE | jq '.applications[] | del(select(.name == "'$APPLICATION_TO_EXCLUDE'"))'
env:
  CMDB_FILE: /tmp/discovered_applications.json
  APPLICATION_TO_EXCLUDE: foo

The policy monitors the sensor configured by start.sensor and only starts when is set to true, the default sensor is service.isUp.

period of type org.apache.brooklyn.util.time.Duration allows repeat policy, and can be set from milliseconds to days. If period not set then policy runs only once.

Discovery policy

Discovery policy consumes application data as output of shell command configured, and lists applications as children nodes under the node the policy applied to. The policy expects the following data format of the command output

{
  "applications":
  [
    {
      "id": "<CMDB APPLICATION ID>",
      "name": "<CMDB APPLICATION NAME>",
      "details":
      {
        "<STRING>": "<OBJECT>"
      }
    }
  ]
}

where details to be directly mapped to sensors so that any other entity can subscribe to them, aggregate the sensor data and respond to a change. CMDB application ID displayed in sensors as application_external_id.

See this example of a discovery policy blueprint.

Exporter policy

Exporter policy produces application data of a single application (root node of AMP application) as input for shell command configured, regardless of whether policy applied to root node or any of its children. The policy produces data in the following format for the command input

{
  "id": "<AMP APPLICATION ID>",
  "name": "<AMP APPLICATION NAME>",
  "sensors":
  {
      "<STRING>": "<OBJECT>"
  }
}

See example of exporter policy blueprint.

Incident policy

ItsmIncidentsPolicy produces incident output to be published in ServiceNow to create or update ongoing incidents for existing AMP applications.

If the application is already stored and tagged in the application table, for example using the exporter policy, the created incident will add it as the cmdb_item impacted for the incident.

The incident is detected based on a unique boolean sensor configurable using the ConfigKey failureSensorToMonitor.

The model for the incident is

{
  "app_id": "<AMP APPLICATION ID (string)>",
  "app_external_id": "<EXTERNAL APPLICATION ID (optional string)>",
  "state": "<INCIDENT STATE (string  one of 'open' or 'close')",
  "details":  "<INCIDENT DETAILS (string)"
}

The details field will be used as title when the incident is created, and also as “work notes” in subsequent updates and as “closing notes” when the incident is closed

See blueprint example of incident policy blueprint that also publish the application in ServiceNow using the exporter polocy. See also expanded blueprint version with all policy properties involved.

Integration Examples

See ServiceNow and AWS AppRegistry integration examples.