<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi David - Just a bit of insight from my own experience:<div><br></div><div>Common issues when monitoring (and the associated escalation processes) don't work and similar issues are seen as you described:</div><div>- Inconsistent HTTP response codes across services and service layers (nginx vs the backend tomcat), means you can't use them properly.</div><div>- Monitoring on arbitrary metrics (90% of something) as opposed to metrics linked to an actual outcome (response times for example).</div><div>- No runbook in place (engineer to change some setting to switch on/off maintenance mode).<br></div><div>- No central view of what engineer is doing what to which systems.</div><div><br></div><div>Some fairly simple example of when I've seen things work pretty well:</div><div>Organisation uses HTTP code monitoring, alerting on 5xx but not 503.</div><div>Services configured (and tested!) to return other, specific 5xx errors, but keep 503 as a 'known and expected maintenance' mode.</div><div>Runbook in place to let other engineers know what's happening (slack message for example) and then maintenance page on the reverse proxy.</div><div>Monitor and report on the common 90% metrics (disk space, memory) but no alerts.</div><div>Don't fill up the disk with logs, only to delete them and let it fill up again.. :)</div><div>Remove all non-actionable alerts.</div><div><br></div><div>Of course a good solution could be to implement a rolling-upgrade / ha maintenance strategy, but in reality (depending on how ancient the app is) this can be quite hard.</div><div><br></div><div>ps. This is a really good read: <a href="https://landing.google.com/sre/sre-book/toc/index.html">https://landing.google.com/sre/sre-book/toc/index.html</a></div><div><br></div><div><br></div><div>Cheers</div><div>Heath</div><div><br></div><div><br></div><div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 9:03 AM David H <<a href="mailto:ispcolohost@gmail.com">ispcolohost@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-4448531762990926626WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hey all, was curious if anyone knows of a website monitoring service that has the option to incorporate a human component into the decision and escalation tree?  I’m trying to help a customer find a way around
 false positives bogging down their NOC staff, by having a human determine the difference between a real error, desired (but different) content, or something in between like “Hey it’s 3am and we’ve taken our website offline for maintenance, we’ll be back up
 by 6am.”  Automated systems tend to only know if test A, or steps A through C, are failing, then this is ‘down’ and do my preconfigured thing, but that ends up needlessly taking NOC time if the customer themselves is performing work on their own site, or just
 changed it and whatever content was being watched, is now gone.  So, the goal would be to have the end user be the first point of contact if it looks like more of a customer-side issue.  If they can’t be reached to confirm, THEN contact NOC, and unlike email
 alerts, keep contacting until a human acknowledges receipt of the alert.<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
</div>
</div>

</blockquote></div>