The Self-Healing Data Center (Part 4) – Configuration of the vRO Example Workflow

So far we have discussed the reasoning behind the Webhook Shims, installed it, configured it, started and tested the shim server.  In this blog post, we will set up things on the Orchestrator side so that the workflow is ready to go when an alert is fired from vRealize Operations.  This will enable self-healing by having Orchestrator attempt a simple remediation of restarting a service.

This blog post assumes you have familiarity with vRealize Orchestrator and some experience with importing workflows and working with the HTTP-REST plugin.  If these are new concepts for you, please don’t be discouraged.  Some great references to get comfortable with Orchestrator are:

HOL-1721-SDC-5 – Introduction to vRealize Orchestrator
Blog from vcoteam.info on using the REST plugin
Postman + vRO = HTTP-REST Plug-in Operations

Let’s dive in.

The Included Example Workflow

Within the Webhook Shim repository we cloned earlier is an example workflow that we will use in the blog post to restart a service on a Linux virtual machine.  This example workflow requires only one input – the alert ID.  The workflow is linear; there are no decision branches to validated data, handle errors, etc.  It’s really just a very simple example.

Several of the steps in the workflow are using a REST operation to gather information from vRealize Operations.  Here’s a summary of the workflow.

1. The workflow uses the alert ID input to get the vR Ops alert (including all the details of the alert).
2. The resource ID for the impacted resource is extracted from the alert.
3. The resource details are fetched, using the resource ID.
4. Because the alert is due to a service monitored by the Endpoint Operations agent, the workflow needs to get the ID of the parent resource.  The parent resource is the guest operating system where the agent is installed.
5. The parent resource details are fetched, using the resource ID for the parent from step 4.
6. Now the workflow extracts the operating system IP address from the resource details.
7. Using the IP address, the workflow now issues an SSH command to restart the service.

In this workflow, the service that needs to be restarted (VMtools) is hard coded.  I leave it up to the reader to modify this workflow to suite their needs.  It wouldn’t be difficult to modify the workflow to determine which service needed to be restarted based on the alert information.

You can import the example workflow package into your Orchestrator instance.  If you aren’t familiar with Orchestrator, I highly recommend you visit the vcoteam.info and check out the great tutorials there.

Once you import the package, make a note of the workflow ID for the Restart Service from Alert workflow.  You’ll need that for the next steps.

Configure the REST Host and Create Operations

As mentioned, Orchestrator uses REST to gather information from vR Ops.  So, we will need to add vR Ops as a REST host within Orchestrator.  Additionally, the workflow is making three different REST API calls to vR Ops.  We will create three REST operations in Orchestrator to support the workflow.

Let’s start with adding vR Ops as a REST host.  In the Orchestrator client, you can run the workflow from Library > HTTP-REST > Configuration > Add a REST Host.  The following screen shots walk through the inputs for my lab environment.

For simplicity in testing, I recommend using Basic authentication.

Create REST Operations

Now that we have added the vR Ops server as a REST host, we can create three REST operations that the workflow will require.  They are:

GET /api/alerts/{alertId}
GET /api/resources/{resourceId}/properties
GET /api/resources/{resourceId}/relationships

Each of these will be added using Library > HTTP-REST > Configuration > Add a Rest operation workflow.

Once added, you can configure the workflow to use these REST operations.  Edit the workflow Restart Service from Alert and modify the attributes for each of the REST:RESTOperation data types, selecting the appropriate REST operations.

Now edit the workflow SSH Restart VMtools and modify the attributes for username and password to an account that has permission to SSH into the OS and start a service.

Now Orchestrator is ready to run the workflow to restart a service with the input of an Alert ID from the Translation Shim!  In the next blog post, we’ll set up the alert notification, configure an alert and trigger the alert to test everything out.