dab

I've been talking with PagerDuty support as well about this, and they've committed to reaching out to SolarWinds to see if the two companies can agree on an approach sanctioned by both sides.

Yes, we've already established what's causing the issue. Question is, how to fix it? What I'm hearing so far from both companies is that it's the other sides fault. Pagerduty are providing a JSON api, Solarwinds is putting characters into the macros that are outside of the acceptable list of JSON characters, without any…

We're using their documented SolarWinds integration method, which involves POSTing some JSON to their site; https://www.pagerduty.com/docs/guides/solarwinds-npm-integration-guide/ This was something they introduced earlier this year.

We just saw this again on a http monitor. I restarted the SolarWinds Collector Data Processor via the Orion Service Manager and the problem cleared. So that appears to be a working fix for it until we can upgrade to 6.1.

Great, thanks for the speedy response. Am I correct in assuming that only Down time goes into calculating non-Availability? So whether we are Up, Warning, or Critical, it all counts towards 100% Availability? If so, is there a way of reporting 'non-Up' time instead of 'non-Down' time? We want to consider Warning and…

So I heard back from PagerDuty; "Thank you for bringing this to our attention. Unfortunately, it looks like, due to the nature of Windows-path names, SolarWinds is sending out invalid JSON (verified here:http://jsonlint.com/), which contains unescaped "\" characters, to our integration API. " So I guess what we have here…

Possibly a new bug - I only just noticed it, so I don't know how long it's been around for. It's the text in the description field. I don't think the pagerduty api has subject or body fields, just description (see below). If I hard-code the text in the JSON I send over, "S: Label: 86b4c87d" works fine, but "S:\ Label:…

So pretty much as I suspected. What happens if the page doesn't return at all, and we hit the Application Monitor Polling TImeout before we get any response?

The problem resolved itself after about 12 hrs. While I was seeing the issue I could navigate there in a browser just fine and could see the text that the Search String was configured to look for. Didn't try removing the test to see what would happen. Hasn't reoccurred since, but if it does I'll try that test.

In the ipMon dashboard, we're used to having a host list where the colored status icons reflect the status of the underlying monitors (cpu/memory/disk). Are you saying that in SAM, these won't change state if one of the underlying metrics passes into a warning/critical state? That they'll always be green unless the host…

Was there ever a solution to this? I'm seeing something very similar (SAM 6.2.1) where we are consistently getting really long response times for https monitors (90 - 100 seconds), but when I go into Edit Application Monitor and test the Component Monitor manually I get around 10 seconds before it reports back as being…