In case you are managing a multitude of datacentres and are relying on vROps and vRLI to monitor your environments, by now you have found out that some alerts are present in vROps and other alerts are present in vRLI.
You can configure alerts in both products, but while you can export and import vROps alert definitions and symptom definitions created in environment A into environment B, this does not go as easily for vRLI when you are using vROps fallback objects .
If you are not using fallback objects, you can disregard this post.
- Postman or any other REST API client. I use Postman myself.
- Notepad ++
Create some alerts in vRLI
Create some alerts in environment A and then use postman to find your alerts.
The results will look like this:
Copy the results of this GET operation, if you want to import these same alerts into the next environment, and paste them in Notepad ++.
Now take a closer look at the 2 following parameters:
Even if the value for “vcopsResourceName” is the same across your environments, the value for “vcopsResourceKindKey” will be different from environment A to environment B. Using these same values across different environments will not work. So you will have to change them.
The easy manual way to export and import vRLI alerts into other environments
In your new environment, decide which object you will use as a fallback object and create a single new alert using this specific fallback object.
Use Postman to find this alert and copy the “vcopsResourceName” and “vcopsResourceKindKey” of your newly created alert.
Now in your notepad++, which still contains the output of ” GET https://vrli.fqdn/api/v1/alerts in environment A” replace the values for “vcopsResourceName” and “vcopsResourceKindKey” with the values found in your new alert for environment B.
To publish these alerts into environment B, again use Postman, which should still be connected to environment B’s vRLI instance, perform POST https://vrli.fqdn/api/v1/alerts by using the modified outputs from environment A.
That’s all there is to it. Of course, if you use different fallback objects for each alert, this won’t prove very useful. So before you export your alert, decide on a single or a few fallback objects for all your alerts.
Also, give each alert a clever naming convention, so even if you use only a single fallback object, you know what the alert has been generated for.