-
Notifications
You must be signed in to change notification settings - Fork 31
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
Alertmanager 0.1 and restricting to tracked projects #14
base: master
Are you sure you want to change the base?
Conversation
JSON payload contains "alerts" key instead of "alert" key.
# try version 1 format | ||
process_alerts(json_data.get("alert", []), Template(self.store.get("v1_message_template"))) | ||
# try version 2+ format | ||
process_alerts(json_data.get("alerts", []), Template(self.store.get("v2_message_template"))) |
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.
Your comments say "try" - does this mean this is an either/or situation? If so, can we please have the control flow indicate this (e.g. via an if else
) rather than blindly processing both types.
If it is possible for both types to co-exist in the same webhook, then can you tweak the wording so it's less confusing, thanks!
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 find the code as it is to be much simpler and more readable. It should be an either or situation, but process_alerts() does nothing in the case that there are no alerts. The alternative is code that looks like this:
alerts = json_data.get("alert", [])
if len(alerts) > 0:
process_alerts(alerts, Template(self.store.get("v1_message_template")))
else:
alerts = json_data.get("alerts", [])
if len(alerts) > 0:
process_alerts(, Template(self.store.get("v2_message_template")))
Which to me feels unnecessarily verbose. I will make the change to that if you want me to.
Broadly speaking, this LGTM. I'm not familiar with the Prometheus webhook API, so I would like to see some comments which explain the hack and how the hack can be fixed (mainly where that information would be coming from). |
Also, if you can mention somewhere about Alertmanager 0.1 support in the code itself rather than just the title of this PR that would be super. You also said you tested it with a fabricated payload - there's no shame in putting said payload as a block comment |
try: | ||
room_projects = self.rooms.get_content( | ||
event["room_id"], | ||
PrometheusPlugin.TYPE_TRACK)["projects"] |
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.
maybe put the closing bracket )
into the newline, to increase readability.
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 agree. This was a copy and paste from the jenkins plugin with only indentation changes. I thought it was difficult to see the closing )
too.
This is all a bit of a hack.
Basically to 'enable' alerts from prometheus to be sent to a room, I just
!prometheus track prometheus
in that room. prometheus is set as a known_project in the config file so that then when issuing that command, the room state is changed for tracking.Then, when the NEB instance is hit on the prometheus endpoint, it checks the room's state to see if the prometheus plugin state member for the room contains anything (it doesn't do actual project matching as I'm not plucking anything from the prometheus alertmanager payload to identify it yet) and if so then it will send the message to that room, else not.