AMP CMDB
AMP CMDB components split into discovery policy, exporter policy and incident policy 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.