Where are "Comments" viewed in Alert Manager?

[DeanDeleon0]

When using the "Edit Incident" option and adding a "Comment" in Incident Posture, where do these comments appear? The informational tab does not display any comments nor can I find anywhere on this app where it is displayed. One would assume it would be in the "History", but nothing in there appears to be populating.

[DeanDeleon0 · Accepted solution]

I managed to find the GitHub for this app and found a similar issue posted regarding comments not showing up.

There appears to be something wrong with the history table loading:

[https://github.com/simcen/alert_manager/issues/179][1]

Replaced everything in incident_history(1) with the query:

index=alerts incident_id="$incident_id$" | table _time,user,action,details,comment

This helped me resolve it.

If anyone can figure out what is wrong with this one that would be awesome:

eventtype=incident_change incident_id="$incident_id$" | sort - _time | eval previous_value=coalesce(previous_status, previous_owner, previous_urgency) | eval attribute=case(isnotnull(owner),"owner",isnotnull(urgency),"urgency",isnotnull(status),"status") | eval attribute_val=case(isnotnull(owner),owner,isnotnull(urgency),urgency,isnotnull(status),status) | eval suppression_rules=if(isnotnull(suppression_rule),mvjoin(suppression_rule,", "),"") | eval details=case(action="auto_previous_resolve","Incident resolved by system (because of a new incident)",action="auto_ttl_resolve","Incident resolved by system (TTL reached)",action="create","Incident created",action="change",attribute + " has been changed from '" + previous_value + "' to '" + attribute_val+"'", action="suppress", "Incident suppressed by rules: " + suppression_rule, action="auto_suppress_resolve", "Incident auto-suppressed by rules: " + suppression_rule, action="comment", "Comment added", action="new_subsequent_incident", "New identical incident with incident_id='"+ new_incident_id +"' has been created and automatically resolved.", action="auto_subsequent_resolve", "Incident resolved by system (because of a identical pre-existing incident)") | table _time, user, action, details, comment

[DeanDeleon0]

Looking further into this, I only needed to change the eventtype=incident_change to index=alerts instead. This fixed everything!

index=alerts incident_id="$incident_id$" | sort - _time | eval previous_value=coalesce(previous_status, previous_owner, previous_urgency) | eval attribute=case(isnotnull(owner),"owner",isnotnull(urgency),"urgency",isnotnull(status),"status") | eval attribute_val=case(isnotnull(owner),owner,isnotnull(urgency),urgency,isnotnull(status),status) | eval suppression_rules=if(isnotnull(suppression_rule),mvjoin(suppression_rule,", "),"") | eval details=case(action="auto_previous_resolve","Incident resolved by system (because of a new incident)",action="auto_ttl_resolve","Incident resolved by system (TTL reached)",action="create","Incident created",action="change",attribute + " has been changed from '" + previous_value + "' to '" + attribute_val+"'", action="suppress", "Incident suppressed by rules: " + suppression_rule, action="auto_suppress_resolve", "Incident auto-suppressed by rules: " + suppression_rule, action="comment", "Comment added", action="new_subsequent_incident", "New identical incident with incident_id='"+ new_incident_id +"' has been created and automatically resolved.", action="auto_subsequent_resolve", "Incident resolved by system (because of a identical pre-existing incident)") | table _time, user, action, details, comment

[centrafraserk]

Thanks for this, I was having the same issue. The reason it was happening is because in larger environments with a lot of large indexes, its going to take a long time for Splunk to find a specific eventtype, because it needs to traverse all the indexes. Specifying the index solved my issue as well, but I kept eventtype=incident_change after the index specification. I think there may be a very slight performance boost by filtering the incidents by those labeled by the event type, but its probably negligible. Thanks again!