SUMMARY and DESCRIPTION should be optional for alerts

[brian-brazil]

For a new user it's not immediately obvious that summary/description are roughly the subject/body of an email. This creates friction to creating alerts, so I propose that we make both fields optional and put in a reasonable default for each. This would make only the alertname and expression mandatory.

[matthiasr]

+1

[juliusv]

Ok with me.

[beorn7]

Err... yeah, as I keep saying... make all the fields optional and freely nameable. Generalize it!

Alertname and expression should be the only "special" fields. everything else should be some kind of label, where users have to define what kind of fields they need and want given their respective notification mechanism.

The only argument against that approach I heard so far is that we cannot do static spell checks on the field names in that way (with the connected problem that we first needed to agree what fields are so important that they should be treated in that way). However, since you can/should always provide all the labels at the end of a notification in some way, even misspelled labels would show up there.

[brian-brazil]

As I indicated elsewhere, summary/description are unique in that it'll be very common for them to vary at each evaluation cycle - or put another way they're the only non-advanced use case where templating in alert definitions is going to be common. Thus making them labels is unwise, as it'll mess up the ALERT timeseries.

[beorn7]

Yes, that's where the idea kicked in that we need some special group of labels (let's call them "annotations" for now) that are not labels of the ALERT timeseries but nevertheless propagated with the alert to the alertmanager and from there to other notification mechanisms.

[brian-brazil]

#1002 now covers this.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.