-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend Discord Notifier #3761
base: main
Are you sure you want to change the base?
Extend Discord Notifier #3761
Conversation
This looks nice! Thank you very much for your contribution -- can you please show me an example of the after with multiple labels? |
I'd love to get some first feedback @gotjosh |
Hey. I‘d love to get some feedback on this. |
I‘ll correct a few minor things this weekend. Afterwards it should be ready to be merged |
The visual changes look nice! You'll need to remove the one message per alert change though as it interferes with alert grouping behavior. For example, if a user wants one message per alert then grouping can be disabled in the route, like so: route:
receiver: test
group_by: ['...'] You can find it documented here. |
Good catch! Thank you!
Could you please have a look at the latest changes? Grouping is now allowed by only sending one message per alert - containing as much 'embeds' (those alert boxes you're seeing) as allowed per Discord API limits. Is it okay like that? I still have to clean the code up and make it a bit more readable before this is ready to be merged tho. (Argh.. and signing off the past commits. I always forget to do it.. I will add a signed-off git message template now 😄) |
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Signed-off-by: Luca Kröger <l.kroeger01@gmail.com>
Title string `yaml:"title,omitempty" json:"title,omitempty"` | ||
Message string `yaml:"message,omitempty" json:"message,omitempty"` | ||
TitleURL string `yaml:"title_url,omitempty" json:"title_url,omitempty"` | ||
SkipFields bool `yaml:"skip_fields,omitempty" json:"skip_fields,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove this as I haven't seen users asking for this in the past. It's much easier to add it later if we need. It's much harder to remove something once it's been added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kinda agree. On the other hand... #3821 wants to add them. So apparently users are asking for them. What do you think? I'm okay with both options. I'll let you guys - as the actual code owners - decide what direction to choose here. It would certainly reduce the huge amount of validation / truncation I had to add 😄 On the other hand - customizability is always a good thing I guess. @gotjosh what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd side with George here unless we're explicitly using them I'd be in favour of removing them - I get when you're coming from on the customization approach but we're very short on hands in the Alertmanager, the less code we have to maintain the better.
My approach for this tends to be: Create an issue with the specific functionality you want to introduce, if we get enough support (number of reactions or comments on the issue) for it we can always add it.
// 2000 characters per message is the limit (not counting embeds). | ||
maxMessageContentLength = 2000 | ||
// 10 embeds per Message is the maximum. | ||
maxEmbedsPerMessage = 10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A concern I have here is that it's not uncommon for users to have large groups (more than 10 alerts). If Discord is limited to 10 embeds then this might make notifications less useful for those users as truncation will become a regular occurrence for them. What do you think @gotjosh?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 good point, I think this is OK for now - I really like the look of this notification as a whole. If users find 10 is too minimal for them to pay attention (in single group) we can always improve it later on.
All I care is that when we have more than 10, we provide a clear message that states we couldn't fit them all.
data := notify.GetTemplateData(ctx, n.tmpl, as, n.logger) | ||
tmpl := notify.TmplText(n.tmpl, data, &err) | ||
if err != nil { | ||
return false, err | ||
} | ||
|
||
title, truncated := notify.TruncateInRunes(tmpl(n.conf.Title), maxTitleLenRunes) | ||
author, truncated := notify.TruncateInRunes(tmpl(n.conf.BotUsername), maxEmbedAuthorNameLenRunes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
author, truncated := notify.TruncateInRunes(tmpl(n.conf.BotUsername), maxEmbedAuthorNameLenRunes) | |
username, truncated := notify.TruncateInRunes(tmpl(n.conf.BotUsername), maxEmbedAuthorNameLenRunes) |
if alerts.Status() == model.AlertFiring { | ||
color = colorRed | ||
w := webhook{ | ||
Username: author, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Username: author, | |
Username: username, |
|
||
alerts := types.Alerts(as...) | ||
|
||
for alertIndex, alert := range alerts { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can use idiomatic variable name i
here:
for alertIndex, alert := range alerts { | |
for i, alert := range alerts { |
break | ||
} | ||
|
||
title, truncated := notify.TruncateInRunes(tmpl(n.conf.Title), maxTitleLenRunes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The title gets repeated for each embed which is kind of weird. For example: [FIRING:2] but each embed contains just one alert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I'm gonna refactor this - using the embed title for displaying the alert summary (CommonAnnotations.summary) and adding the total alert count to the message above the embeds.
I'd love to finalize this and get this into 0.27.1. @gotjosh could you please have a look at the discussions above? |
I've been waiting for over two months now, and my PR still hasn't been fully reviewed, nor have my questions been answered. I know everyone is busy, but it's getting a bit frustrating. I'd love to help improve the software we all use day to day, but I'm not sure if I can keep contributing if things don't change. For those who might not know what I'm talking about, here is my current focus: Improving Discord Integration in Alertmanager.
Please don't get me wrong; I love your work and want to keep contributing. I do honor your tight schedules. It's just getting a little... frustrating for me and, looking at the comments on some of the PRs, for many others as well. |
Hi Luca! 👋 I think we are still waiting on some changes since the last time, no?
I don't see any commits since this comment, is this still something you want to change?
I believe this isn't working as it should, did you get time to take a look? |
I solved some locally without pushing because I'm waiting for the discussions above to resolve. As long as I don't know what way you want me to implement things, I don't know how to continue working on this. See:
|
Oh! Please push those changes so we can take a look! I think those two (repeated title and missing embeds) are unrelated to the other discussions so 100% recommend we push those fixes to be reviewed 👍 I'll check in with @gotjosh, let's keep making progress on the remaining issues and we can come back to this! 👍 I'm not sure I see where #3821 is adding a |
Hi @LucaDev! Do you want to push the changes you made so we can take a look? |
Hi @LucaDev! We are preparing an Alertmanager 0.28 release, are you still interested in this? |
I apologise @LucaDev - as you can appreciate, my GitHub notifications are just unmanageable and other priorities have kept me away from Alertmanager duties. I don't think I'll have the time herd this PR into the cut for 0.28 which is sad - but can we try to attempt for the next release? |
Hey all. Apologies for letting you wait for so long. I had quite a few busy months. I’ll rebase the code and push the latest changes soon. Would love to see it in 0.28 (especially due to the long release cycles of alertmanager) but 0.29 would also be fine I guess. Better late then never after all 😄 |
This PR extends the Discord notifier to improve the readability of alerts.
It changes 5 key elements:
It also fixes UI builds on apple silicon by forcing the linux/amd86 platform for the elm container
Before: