opensearch-project / opensearch-project/alerting
Record more info about alert to know it's triggered by error or real data and when
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 82
- Forks
- 133
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 9
Description
Issue by ylwu-amzn
Friday May 08, 2020 at 03:14 GMT
Originally opened as https://github.com/opendistro-for-elasticsearch/alerting/issues/201
Is your feature request related to a problem? Please describe.
Currently monitor will create an alert if any error happen. But we can't know the historical alert triggered by error or real data as the state becomes "COMPLETED" or "ACKNOWLEDGED". And if alert triggered by some error first, then triggered by real data later, we don't know when the real data alert started. Example:
- Alert triggered by timeout error at 5:00 PM .
- Monitor next run at 5:05PM, timeout error gone, but monitor's input meets trigger condition, alert will stay at active.
- Monitor run at 5:10PM, no error, and monitor input doesn't meet trigger condition, alert becomes COMPLETED.
In this example, we can't know the real data alert starts from 5:05PM.
Describe the solution you'd like
- Option1:
Suggestion from @dbbaughe
Add a counter map on the alert to keep track of each states number for the lifetime of an alert
So when it’s completed you end up with a nice map of
Alert: { error: 1, active: 9, acknowledged: 5 }
i.e. the alert during the 15 executions was in error state once, active 9 times, and acknowledged 5
Question:
Can we add two more fields, so we can query easily?
- error_start_time
- real_data_alert_start_time
Or something else is ok, only if we can query easily to get which alert triggered by real data and know the real data alert start time.
- Option2:
Add alert type filed. For alert triggered by error, we can call it "ERROR_ALERT". For real data alert, we can call "REAL_ALERT". For the above example:
- Alert triggered by timeout error at 5:00 PM . We create a "ERROR_ALERT".
- Monitor next run at 5:05PM, timeout error gone, but monitor's input meets trigger condition, alert will stay at active. We close the "ERROR_ALERT" and create a "REAL_ALERT".
- Monitor run at 5:10PM, no error, and monitor input doesn't meet trigger condition, alert becomes COMPLETED. We close the "REAL_ALERT"
We can show different style for different alert types on Kibana page and surface error message for "ERROR_ALERT".
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the monitor and alert lifecycle described in the issue, including error-triggered alerts, real-data alerts, and transitions to COMPLETED or ACKNOWLEDGED. Compare the two proposed designs and determine how alert history, alert type, and start times should be queried; the issue does not name files or tests, so the implementation entry point is not specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100