kubernetes-monitoring · artiegold · May 20, 2019 · metalmatze · Jun 6, 2019
@@ -3,7 +3,7 @@
 As Rob Ewaschuk [puts it](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit#):
 > Playbooks (or runbooks) are an important part of an alerting system; it's best to have an entry for each alert or family of alerts that catch a symptom, which can further explain what the alert means and how it might be addressed.
 
-It is a recommended practice that you add an annotation of "runbook" to every prometheus alert with a link to a clear description of it's meaning and suggested remediation or mitigation. While some problems will require private and custom solutions, most common problems have common solutions. In practice, you'll want to automate many of the procedures (rather than leaving them in a wiki), but even a self-correcting problem should provide an explanation as to what happened and why to observers.
+It is a recommended practice that you add an annotation of "runbook" to every prometheus alert with a link to a clear description of its meaning and suggested remediation or mitigation. While some problems will require private and custom solutions, most common problems have common solutions. In practice, you'll want to automate many of the procedures (rather than leaving them in a wiki), but even a self-correcting problem should provide an explanation as to what happened and why to observers. In addition, it would be useful to include a URL to a dashboard that includes the relevant information; distributed systems being what they are, the more you know. the more you might be able to determ,ine just how significant an individual alert might be.
-It is a recommended practice that you add an annotation of "runbook" to every prometheus alert with a link to a clear description of its meaning and suggested remediation or mitigation. While some problems will require private and custom solutions, most common problems have common solutions. In practice, you'll want to automate many of the procedures (rather than leaving them in a wiki), but even a self-correcting problem should provide an explanation as to what happened and why to observers. In addition, it would be useful to include a URL to a dashboard that includes the relevant information; distributed systems being what they are, the more you know. the more you might be able to determ,ine just how significant an individual alert might be.
+It is a recommended practice that you add an annotation of "runbook" to every prometheus alert with a link to a clear description of its meaning and suggested remediation or mitigation. While some problems will require private and custom solutions, most common problems have common solutions. In practice, you'll want to automate many of the procedures (rather than leaving them in a wiki), but even a self-correcting problem should provide an explanation as to what happened and why to observers. In addition, it would be useful to include a URL to a dashboard that includes the relevant information; distributed systems being what they are, the more you know. the more you might be able to determine just how significant an individual alert might be.
-It is a recommended practice that you add an annotation of "runbook" to every prometheus alert with a link to a clear description of its meaning and suggested remediation or mitigation. While some problems will require private and custom solutions, most common problems have common solutions. In practice, you'll want to automate many of the procedures (rather than leaving them in a wiki), but even a self-correcting problem should provide an explanation as to what happened and why to observers. In addition, it would be useful to include a URL to a dashboard that includes the relevant information; distributed systems being what they are, the more you know. the more you might be able to determ,ine just how significant an individual alert might be.
+It is a recommended practice that you add an annotation of "runbook" to every prometheus alert with a link to a clear description of its meaning and suggested remediation or mitigation. While some problems will require private and custom solutions, most common problems have common solutions. In practice, you'll want to automate many of the procedures (rather than leaving them in a wiki), but even a self-correcting problem should provide an explanation as to what happened and why to observers. In addition, it would be useful to include a URL to a dashboard that includes the relevant information; distributed systems being what they are, the more you know. the more you might be able to determine just how significant an individual alert might be.
 
 Matthew Skelton & Rob Thatcher have an excellent [run book template](https://github.com/SkeltonThatcher/run-book-template). This template will help teams to fully consider most aspects of reliably operating most interesting software systems, if only to confirm that "this section definitely does not apply here" - a valuable realization.