Improvement: Add severity to alert definitions in Atlas MongoDB
The alert payload only contains status field with 'open' or 'closed' value. No severity definition option is available.
Vikas
shared this idea
-
Seyfullah
commented
Although we've used Opsgenie Team Integration API, alarms generated by Mongo aren't included in the team information when they're forwarded to Opsgenie, preventing escalation to the team. We also want to consolidate alarms on a common platform and receive alerts via email, app popups, or calls when a critical situation occurs. Currently, this doesn't seem possible because it's not associated with the team, and alarms, regardless of their criticality, appear as "Moderate" severity in Opsgenie.
-
David
commented
When sending to events v1 there is no way to send a custom event with json. It needs some more work to make it useful.
custom json event sample:
{
"client": "opsman_account1",
"dedup_key": "opsmanager1",
"event_action": "trigger",
"payload": {
"severity": "warning",
"source": "opsmanager",
"summary": "Ops Manger Alert -- Alert Text"
},
"routing_key": "MyKey"
}If you had multiple ops manager installs it would be possible to route them off details.groupId contains your groupid, but without being allowed to pass a json payload can only trigger events can't do any auto resolves, set title, etc
-
Sylvain
commented
A use case in our company: we forward Ops Manager alarms to a central monitoring system (using the API). Only some of those alarms should trigger a call to the hotline / wake us up.
Severity should be the criteria (eg. errors should wake us up during the night, warning should be handled within a day, info should be audited from time to time).
-
Mark
commented
It would be helpful for the subject lines to be more descriptive. The timestamp isn't that helpful, it's already part of the email. We would like to see a human-friendly cluster name, for cluster-specific alerts, and something specific, like "Oplog", "Storage", "Maintenance", "Restart", and so on.
-
Ini
commented
At the moment, it appears one cannot customize the messaging or subject line of the alerts. This makes it difficult to categorize the alerts. For instance, we would like to categorize alerts into different severity levels, such that severity level will help determine the level of attention that is paid to the alerts when they trigger. If it is possible to prefix or append some customization code and message to either the subject line and/or actual message, then a monitoring team can use the custom code/message to determine the severity or category of the alert when it triggers.
Some alerts may just be informative, warnings and severe and one should be able to categorize as flexible but standardized as works for the organization.