SolarWinds Integration With xMatters for Different Alerts and Severities

Not Yet Reviewed

How are you guys integrating SolarWinds Orion with xMatters for different alerts and severities? Are different integration plans being configured or maybe there are different communication plans?

I want to make sure that communications are going out to the correct teams and team members depending on the specific SolarWinds context and what resources are currently scheduled to be on call.

Severity 1

  • Incident for a server going down in SolarWinds
  • xMatters sends notification alerts to all infrastructure teams via text, email, and phone
  • Everyone joins an xMatters initiated WebEx bridge call

Severity 2

  • Incident for network performance being degraded
  • xMatters sends notification alerts network team via text, email, and phone
  • Network team joins xMatters initiated WebEx bridge call

Severity 3

  • Incident for a server using near max disk space
  • xMatters sends notification alerts to NOC members via text, email, and application
0

Comments

1 comment
Date Votes

Please sign in to leave a comment.

  • Hi Phillip, 

       I am resident Product Evangelist so I'm not on the receiving end of xMatters, and I would be very interested to hear what other, actual users of our platform chime in with, but I can give some ideas on how to accomplish those things. 

    I'm going to assume you're using the latest and greatest version of the SW integration (docs here), if that is not the case the details will vary, but the general idea will be the same. 

    I'm going to break this up into two parts: recipients and conference bridge. You will need to "eject" the built-in integration to a Comm Plan so you have access to the inbound integration scripts. This is where I am able to see how the recipient is determined. 

    First, recipients can be determined a couple of different ways. You can "hard code" them on the SW side, in the Trigger Actions page in the Alert. Just add a "recipient": "Network" entry to the JSON and the code will pick that up and target them. This way you can tweak the Alert conditions to target different recipients. I would encourage changing the name of the action to reflect the recipient to save on headaches. 

    Alternatively, you could use subscriptions. They are pretty well documented here, but in short they allow you to let xMatters determine who should be notified. The idea is users or groups "subscribe" to events that come in. So you could create a Sev 1 subscription that targets all the infrastructure related groups when a SW event comes in with a Severity of 1. Then you can have an additional subscription for Sev 2 events that targets the Network group when the Severity is 2. Etc. Generally subscriptions are self service, but you can lock things down so users can't subscribe or unsubscribe inappropriately. 

    The second piece is around the conference bridge. Create another form and add all the same properties and add the conference bridge section. Then in your inbound integration script, add some logic to inspect the severity and if it is 1 or 2, then make an http call to the other form. Something like this:

    if( data.severity == "1" || data.severity == "2" ) {
    var conferenceEventPayload = {};
    conferenceEventPayload.properties = data; // Put in all the properties from SW

    // Add the conference bridge, note the bridgeId is the name of the
    // external bridge.
    conferenceEventPayload.conference = {
    "bridgeId": "WebEx",
    "type": "EXTERNAL"
    }

    // build the new event request. the "Alert - Conference Bridge" constant
    // will be the path portion of the "Alert - Conference Bridge" form target url.
    var req = http.request({
    "endpoint": "xMatters",
    "path": constants[ 'Alert - Conference Bridge' ],
    "method": "POST",
    "headers": {
    "Content-Type": "application/json"
    }
    });

    // Create the event
    var resp = req.write( conferenceEventPayload );

    // Stop the script here so we don't create another event
    return;
    }

    This assumes you've created the new form "Alert - Conference Bridge" and created the constant called "Alert - Conference Bridge" and set the value to the path portion of the form endpoint. 

    Oh, now that I think of it, if you go the subscription route, this means your Sev 1 and 2 subscriptions will need to be against this Conference Bridge form, not the original Alert form.

    I hope that helps. It's a little overly complicated because we have to create the new form. I submitted a request to tweak the API so we can do this all in one form, but that's the way it is now. 

    Happy Tuesday!
       --- Travis

     

     

     

    0

Didn't find what you were looking for?

New post