Alerts Description and Summary

[sayf.eddi...@gmail.com]

Hello, I have looked online and I cant find any best practices for filling up the description and the summary. from the examples I see that Summary should be the shortest (plus the minimum usage of labels). But maybe it is an observation bias. 

I am trying to generate some automatic documentation around alerting and having a lot of labels makes it as user friendly as reading the yaml file directly

Regards

[Stuart Clark]

It really depends how you are wanting to use those. If you are wanting
to use the summary in an email's subject line then you probably want it
to be fairly short for example. You can have as many labels/annotations
as you like, so you don't even have to have one called "summary" if you
don't want to, and there's nothing stopping you from having much more
specific labels (e.g. severity, service, environment) which you can then
include in email/ticket subjects.

--
Stuart Clark

[sayf.eddi...@gmail.com]

Thanks for the response

By generating automatic documentation I meant automatically creating developer documentation of the existing alerts and their descriptions from the yml files rather than runtime information.

which means the labels will not be replaced, so the less labels the more readable the result.

I am considering the addition of an extra annotation field for that purpose I think it is better to separate the concerns here.

[Brian Candler]

If it's only for consumption by developers reading the rules files, then would YAML comments be sufficient?

[sayf.eddi...@gmail.com]

well yeah but I cant guarantee they understand the alerting format. also product operator can access the documentation too.