Weekly Padgett

No. 0101 min read

Alarm fatigue: your monitoring system found the caps lock key

ELK and HP OpenView helped cut resolution time for actionable Sprint mediation alarms by half. Tell the operator what to do, folks. Making noise is the easy part.

A person rests their head on folded arms at a desk crowded with red telephones and a computer.
File photoDramatization. No observability was harmed.

Your monitoring system tells you something is wrong, and then leaves you to find the system, figure out what happened, decide whether it matters, and work out what the hell to do. I've got some complaints about that.

At Sprint[1]Ref. 1Sprint en.wikipedia.org I deployed the ELK stack[2]Ref. 2ELK stack elastic.co and HP OpenView[3]Ref. 3HP OpenView en.wikipedia.org across multiple billing mediation platforms for observability and alerting. Time-to-resolution for actionable alarms dropped 50%.

That measurement covered actionable alarms.

For mediation, a file identifier can tell you more than a generic severity label. What happened to this piece of work between collection and delivery? "ERROR" tells me somebody found the caps lock key. I still need to know what happened to the file.

An operator shouldn't need to open a dashboard to find out which machine sent the message.

I want to know what the person receiving an alarm can do about it. If all we've got is "look at it," we've given an operator who already has a job another blinking light to watch.

References

  1. Sprint en.wikipedia.org ↩
  2. ELK stack elastic.co ↩
  3. HP OpenView en.wikipedia.org ↩
observabilityelkmonitoringtelecomincident-response

More on this beat