vRealize Operations sending alerts to Events API

I am finding it strangely difficult to find discussion or example of others integrating vRealize Operations (aka vROps) Alerts into Pagerduty via webhook or REST. Especially considering how widespread use of this tool must be. Can anyone describe what is required? What you put into vROps outbound webhook config?
I found some articles by VMware about using a webhook “shims” feature. But maybe it would be simpler than that these days, with the advent of rule-based Dynamic field capture and re-assembly feature released by PagerDuty last fall.

It’s not an uncommon request, and the “shims” solution is a viable approach. Ultimately, you need to send data from vROps towards PagerDuty, and if it’s not in a format we expect, you need to transform it somewhere in the middle using a “shim”, an AWS Lambda, or even PagerDuty’s Custom/Application Event Transformers (CET/AET).

The ideal solution is that VROps can send webhooks in PagerDuty’s Event API v2 format, then you’re golden!

Yes, v2 is the path I’m trying to take. As long as vROps is emitting ‘standard’ JSON, I expect I would not need a shim in the middle. However, judging from vRealize docs, it may be doing something that is preventing the PagerDuty receiver from accepting:

Specifically, the append to URL they mention might be effectively poisoning the route on the PagerDuty side:
URL to which you are sending the alerts. The URL must support HTTPS. When an alert is sent to the REST Web server, the plug-in appends /{alertID} to the POST or PUT call.

First, see if you have control over the payload formatting. I can’t find any reference that you can do this. (why they have ‘shims’)

If it can’t be configured, let’s build a CET/AET-based integration! Happy to help if you’d like.

disclosure: I opened a Support case on this

vRealize docs state that typical JSON ‘set of fields’ is provided. One can use the Customize Event Fields feature (in Global Event Rulesets) to accomplish what formerly would have required CET scripting. But I can’t even get the content to arrive yet at PagerDuty, probably because of the {alertID} (appended to the PagerDuty URL as it leaves vRealize, if I read that correctly) since it poisons the web path to PD endpoint.

Translating the content itself would be a piece of cake. Example content seems to contain sufficient fields for us:
{
“startDate”:1369757346267,
“criticality”:“ALERT_CRITICALITY_LEVEL_WARNING”,
“Risk”:4.0,
“resourceId”:“sample-object-uuid”,
“alertId”:“sample-alert-uuid”,
“status”:“ACTIVE”,
“subType”:“ALERT_SUBTYPE_AVAILABILITY_PROBLEM”,
“cancelDate”:1369757346267,
“resourceKind”:“sample-object-type”,
“alertName”:“Invalid IP Address for connected Leaf Switch”,
“attributeKeyID”:5325,
“Efficiency”:1.0,
“adapterKind”:“sample-adapter-type”,
“Health”:1.0,
“type”:“ALERT_TYPE_APPLICATION_PROBLEM”,
“resourceName”:“sample-object-name”,
“updateDate”:1369757346267,
“info”:“sample-info”
}

Due to said path contamination, I asked Support to request development of an official PagerDuty webhook plugin to allow out-of-box integration with vRealize Operations. Webhook is preferred – I could slush this in via email, but some benefit is lost there.

VMware provides a shim mechanism, but it involves the vRealize administrator deploying an extra container to run the translator. This is a much more complex endeavor than a simple webhook or out-of-box plugin (that runs natively in vRealize) would be.
vRealize + Webhooks = Infinite Integrations - VMware Cloud Management

I have a meet with my local vRealize Ops admins on Wed. Maybe they will have some ideas or be willing to pursue vRealize vendor support. My main point in posting here is that I hoped some other interested party would have done this same integration between these two major vendors. As popular as these two are in their markets, it must have happened before. But the impression I get so far is that most people just give up on the API method and go with smtp – because time.
Sorry if I’m using the wrong terminology. I have found if I can get a legit JSON payload to arrive at PagerDuty somehow, PagerDuty has the power to digest and re-assemble it, even if I must make the rules. This capability has only gotten more powerful in recent months. As the vast majority of integrations I have configured up to now have been API based (what I call anything non-smtp), I can probably afford one or two scraps of smtp.