Create alert using SWIS API

Hello Thwack community.

I'm researching possible ways to create an alert in Solarwinds using the SWIS API. Most of what I was able to find relates to importing and exporting alert definitions. However, I want to create an actual alert in Solarwinds using the API.

Background: my company has built its Event Management system around Solarwinds alerts. Alerts in Solarwinds are reviewed and tracked by Event Management with incident tickets and (sometimes) page outs to functional areas. Company now standing up Red Hat Openshift as an application platform. Openshift includes Grafana monitoring with Alertmanger for alerting. Alertmanager has a pretty customizable notifications module which means I should be able to send an alert over to Solarwinds. Just now sure how I would write the SWIS call to create an alert.

I welcome any ideas from the community on best way to integrate Openshift alerts with Solarwinds.

Thanks!

Find more posts tagged with

swis

openshift

Alerting

Accepted answers

monitoringlife

Are you looking to monitor Openshift with SolarWinds, or send Openshifts alerts to SW who relays them to your ITSM tool?

Found a feature request for Openshift.

What I have done is integrate my monitoring tools (2-8 depending on client) to an ITSM. Then the ITSM handles prioritization and call outs.

If you want to integrate the two the easiest that comes to mind are events/traps or API monitor/script.

All comments

monitoringlife

Are you looking to monitor Openshift with SolarWinds, or send Openshifts alerts to SW who relays them to your ITSM tool?

Found a feature request for Openshift.

What I have done is integrate my monitoring tools (2-8 depending on client) to an ITSM. Then the ITSM handles prioritization and call outs.

If you want to integrate the two the easiest that comes to mind are events/traps or API monitor/script.

robert777

Thank you.

I believe the phase 1 goals will be to send selected alerts from openshift/prometheus to Solarwinds. At the present time the company incident response effort is engineered around Solarwinds alerting.

My current thoughts are that for alerting to work we need to add the openshift clusters/projects/nodes/pods (still working on the terminology) to Solarwinds. It could be that the SW "External" node type will work for that.

I'm reading a Red Hat article on configuring "external" Alertmanager instances (alertmanager that part of openshift/prometheus handling alerts and alert flow). Wondering... since the Prometheus monitoring ecosystem is open-source, then developing a capability to configure Solarwinds as an external alertmanager instance might be a fairly quick time to market. (??)

Thanks again for responses from the community.

christopher.t.jones123

@robert777, there's a couple of different ways that you could handle this until (if it ever gets implemented) native OpenShift monitoring is a feature provided by SolarWinds.

1. Have the built-in AlertManager for OpenShift have an alert action (or whatever vernacular is equivalent) that writes an event to the SolarWinds Events table (you can do this via a CRUD operation against the API). SolarWinds can then have a value that it uses to trigger its own alert that then integrates with the ITSM integration you already have created. I personally wouldn't recommend this because of the level of complexity it creates, and the multiple points of failure that inherently comes with this method.

2. You could investigate a way to query the Prometheus endpoint that OpenShift exposes for the alertable condition you would like and turn it into a Script Component Monitor (PowerShell or IX based would probably work). This would look very similar to the Powershell scripts that ship out of the box to monitor Office 365. Then typical SolarWinds alert creation practices would come into play. If I had to choose between the two due to a lack of native integration I would probably explore this route first. It maintains that SolarWinds is still the primary metric collector and alert engine and doesn't rely on the availability and reliability of another collector or alert engine for continued monitoring to be current.