<div dir="ltr"><div dir="ltr">On Wed, Jun 5, 2019 at 5:44 AM William Waites <<a href="mailto:ww@styx.org">ww@styx.org</a>> wrote:<br></div>> It's not enough to have monitoring and a ticket system. You need to pay<br>> attention to them, care for them and feed them. I can't count the number<br>> of ticket systems full of ancient and irrelevant things or monitoring<br>> systems that people have forgotten about or don't know how to add new<br>> stuff to. Even the cycle of,<div><br></div><div>Some points to consider when monitoring your network:</div><div><br></div><div>1. Beware early automation. If you write a generator to go and monitor all your stuff without addressing how operators will change things one-off (which is hard to design well) the other operators will find the monitoring system unusable. Which means they won't update it when stuff is added and changed. Making it quickly useless.</div><div><br></div><div>2. Careful aggregating alarms. That big green or red light is useless. The operator has to be able to start with the alarm and immediately trace back to exactly what tests and results bubbled up in to the aggregate and from there to the malfunctioning component. If you lose this information during the aggregation process, you're just producing noise.</div><div><br></div><div>2. Every alarm must be actionable. When the light goes red, what -exactly- do you want the operator to do as a result? Don't create an alarm until you can offer a detailed and specific answer, and link that answer to the alarm so the operator doesn't have to hunt for it.<br><div><br></div><div>Regards,</div><div>Bill Herrin</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>William Herrin</div><div><a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a></div><div><a href="https://bill.herrin.us/" target="_blank">https://bill.herrin.us/</a><br></div></div></div></div></div>