ALERT! - Updated Management Pack for ServiceNow

Updated Management Pack for ServiceNow

vRealize True Visibility Suite Management Pack for ServiceNow

This blog was written by VMware’s own Brock Peterson and is also posted on his personal blog here. Brock is a Cloud Solutions Architect in the Cloud Management Business Unit and an avid Packer fan (but we try not to hold that against him).

VMware introduced the ServiceNow Notification Plugin in vRealize Operations 7.5, giving customers the ability to send vRealize Operations Alerts to ServiceNow. We covered this and the subsequently released vRealize True Visibility Suite Management Pack for ServiceNow 3.0 in a previous blog. Since the original GA, the vRealize True Visibility Suite development team has added several key new features in the latest version 4.1 (Release Notes), we’ll discuss two of them here:

1. Alert synchronization supporting Alerts, Events, and Incidents
2. CMDB population and synchronization

First, let’s take a step back and look at the higher level architecture.

The original ServiceNow Notification Plugin that comes with vRealize Operations converts vRealize Operations Alerts to ServiceNow Incidents. The latest vRealize True Visibility Suite Management Pack for ServiceNow 4.1 has the ability to convert vRealize Operations Alerts to Alerts, Events, or Incidents in ServiceNow, whichever you choose. Additionally, once they are updated (in either vRealize Operations or ServiceNow), those updates will be synchronized across both the source and target destinations.

What does this look like in practice? Once you’ve installed the vRealize True Visibility Suite Management Pack for ServiceNow 4.1, configure the adapter.

There are several different fields available, all formally documented here. A few highlights:

1. ServiceNow Host – ServiceNow instance the adapter will pull CMDB data from.
2. Configuration File – Configuration File used by the adapter itself, this is the most important piece of the adapter. For example, this is where you’ll tell the adapter to forward vRealize Operations Alerts to ServiceNow and create them as Alerts, Events, or Incidents.
3. Upload Dashboards | Upload Reports – Toggle telling the adapter to create dashboards/reports based on settings in the configuration file.
4. ServiceNow Proxy Host | ServiceNow Proxy Port – Giving the adapter proxy capabilities if necessary. The out-of-the-box ServiceNow Notification Plugin doesn’t have proxy support.

The configuration file literally defines the adapter, it exists in the $VCOPS_BASE/user/plugins/inbound/servicenow_adapter3/work directory and will look like this:

Let’s explore the Alert Synchronization section of the configuration file. Taken directly from the documentation:

Alerting configurations for the alert-sync feature define what alerts will be synced between vRealize Operations and ServiceNow, and how they will be represented in ServiceNow. The three supported representations are INCIDENT (default), ALERT, and EVENT. Once the vROps alert is present in ServiceNow, the ServiceNow Management Pack performs the following additional features:

• If an alert is cancelled in vRealize Operations, the corresponding incident or alert in ServiceNow is closed.
• If an incident or alert is closed in ServiceNow, the corresponding alert in vRealize Operations is suspended. Alerts in vRealize Operations are generally triggered automatically by breaching thresholds. Because we cannot control this, if an incident or alert is closed in ServiceNow it should be due to the underlying issue being resolved. Thus, we suspend the Alert in vROps (for a configurable length of time) to allow the alert to resolve. If the threshold(s) is still breached when the alert suspend time has ended, the alert will re-trigger and reopen the ServiceNow incident or alert.
• If a synced vRealize Operations alert is on a vRealize Operations ResourceKind that is present in one of the resourceTypes sections above, the ServiceNow Management Pack will create a reference from the incident/alert/event cmdb_ci column to the CI representing the resource in ServiceNow. Note: A resourceType section can be created with empty groupTypes and hierarchies arrays for matching to a resource type, without creating any groupings and hierarchies.
• The ServiceNow Management Pack can be configured to watch a predefined set of incident/alert/event columns and display the current values in the corresponding vRealize Operations alert as a series of notes.

If alert sync is not desired, alertingConfigs can be omitted entirely, or an empty list can be used:

“alertingConfigs”: []

If you wish to create ServiceNow Incidents (which is the default), your alertingConfigs stanza might look like this:

“alertingConfigs”: [ { “callerId”: “vROps Service User” “propagateAlertUpdates”: true, “retrieveIncidentUpdates”: true, “incidentElementsToRetrieve”: [“assigned_to.name”, “state”, “cmdb_ci.sys_id”], “incidentReopenState”: “In Progress”, “incidentCloseState”: “Closed”, “vropsSuspendMinutes”: 30 }]

Each config contains a callerId (the only required field) which identifies the user the ServiceNow incident/alert/event comes from. This is the user configured in the out-of-the box ServiceNow Notification Plugin.

To explicitly call out the three ServiceNow types, your config files might look like this:

1. Incidents: “alertingConfigs”: [ { “callerId”: “vROps Service User”, “serviceNowDestination”: “INCIDENT” }]
2. Alerts: “alertingConfigs”: [ { “callerId”: “vROps Service User”, “serviceNowDestination”: “ALERT” }]
3. “alertingConfigs”: [ { “callerId”: “vROps Service User”, “serviceNowDestination”: “EVENT” }]

They can also be found here:

$VCOPS_BASE/user/plugins/inbound/servicenow_adapter3/conf/config_samples/alert

I’ve created a config file in my environment to do some testing, it looks like this.

This is designed to send vRealize Operations Alerts to ServiceNow and create Incidents for them. I’m sending as callerId “vRealize Operations” and I’ve filtered it down to VMs only via the objectTypes filter. Documentation for these fields (and others) can be found here. Here are the vRealize Operations Alerts on the left and their corresponding ServiceNow Incidents on the right.

If you want to be a bit more descriptive with your callerId, adjust the config file and be sure their is a ServiceNow user with the same name. Mine looks like this.

As mentioned previously:

• If an Alert is cancelled in vRealize Operations, the corresponding incident or alert in ServiceNow is closed. Here I’ve canceled a vRealize Operations Alert (which makes it Inactive) and the corresponding ServiceNow Incident was closed.

• If an Incident/Alert is closed in ServiceNow, the corresponding vRealize Operations Alert is suspended.

• If any of the default ServiceNow Incident fields (State, Assigned to, Priority, Urgency) get updated, those updates get sent back to the corresponding vRealize Operations Alert and are logged as Notes.

You can pull additional ServiceNow field updates back into vRealize Operations by adding them to the serviceNowElementsToRetrieve array in your configuration file. Here, you can see my updated config file, the ServiceNow Incident, and the associated vRealize Operations Alerts with Notes.

Now that we have vRealize Operations Alerts synced, let’s do a CMDB sync by adding the following to your configuration file. Documentation can be found here.

“cmdbSync”: {

“cmdbSyncMethod”: “IRE_API”,

“syncMode”: “POPULATE_AND_DELETE_WHEN_NOT_EXISTING”, “objectIdentifierSource”: “MOID”,

“builtInTreeEnabled”: true,

“customTreesEnabled”: false,

“additionalColumns”: {},

“nameFilter”: {}

Currently, the only supported sync method is via the IRE_API. There are three sync modes available:

1. POPULATE_ONLY: Populates the CMDB, but does not remove CIs. If a resource is Not Existing, it sets the operational status to ‘6’ (retire).
2. POPULATE_AND_DELETE_WHEN_NOT_EXISTING: Populates the CMDB and removes CIs that have been marked as Not Existing in vROps
3. POPULATE_AND_DELETE_WHEN_REMOVED: Populates the CMDB and removes CIs that have been removed from vROps. If a resource is Not Existing, it sets the operational status to ‘6’ (retire).

There are several example configuration files available here: /usr/lib/vmware-vcops/user/plugins/inbound/servicenow_adapter3/conf/config_samples/cmdb_sync.

There are combined example configuration files here: /usr/lib/vmware-vcops/user/plugins/inbound/servicenow_adapter3/conf/config_samples/combined.

We’ll use the moid_incidents_and_populate_only.json config file to get what we need. I’ve adjusted it to include our previous alertingConfigs array. As indicated in the documentation:

This configuration filters vRealize Operations alerts to the following ResourceKinds: VirtualMachine, ClusterComputeResource, Datacenter, Datastore, HostSystem. It creates ServiceNow Incidents for these vRealize Operations alerts and associates them with their CI if it is present in the CMDB. The mapping uses a combination of UUID and vCenter UUID as identifiers for all ResourceKinds.

Also, it syncs vRealize Operations resources to the CMDB. The MOID is used as the object_id for cmdb_ci_vmware_instance (Virtual Machine) CIs and the UUID is used as the object_id for all other CI Classes. This configuration populates the CMDB, and deletes resources from the CMDB when they are deleted from vRealize Operations.

You’ll notice now, each ServiceNow Incident (generated by a source vRealize Operations Alert) has an associated CI.

There is a lot we can do with this latest version of the vRealize True Visibility Suite management pack for ServiceNow, these are just two of the main use cases. For more information on this management pack and others in vRealize True Visibility Suite you can find us here.