Improvement/bb 605 alert for ingestion processing - #2821
benzekrimaha wants to merge 4 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
@@ Coverage Diff @@
## development/9.6 #2821 +/- ##
===================================================
- Coverage 76.09% 75.98% -0.11%
===================================================
Files 206 206
Lines 14426 14426
===================================================
- Hits 10977 10962 -15
- Misses 3439 3454 +15
Partials 10 10
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
bd6999f to
2f9c7f5
Compare
0e20eb4 to
a682dd2
Compare
570a524 to
24f4b57
Compare
bf0d146 to
4a35f25
Compare
Hello benzekrimaha,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
There was a problem hiding this comment.
this branch is on top of an outdated (merged) branch
- appears to include 4 commits, which do not belong in this branch
- the changes are unrelated
- the branch conflicts with upstream
→ rebase before asking for review
| description: "Ingestion producer has been unable to start reading from a source for the last 10 minutes, so the objects of that location are not ingested. Check the producer logs for the bucket it fails to resolve." | ||
| summary: "Ingestion producer cannot start reading from a source" |
There was a problem hiding this comment.
| description: "Ingestion producer has been unable to start reading from a source for the last 10 minutes, so the objects of that location are not ingested. Check the producer logs for the bucket it fails to resolve." | |
| summary: "Ingestion producer cannot start reading from a source" | |
| description: "Ingestion producer has been unable to read from a source for the last 10 minutes, so the objects of that location are not ingested. Check the producer logs for the bucket it fails to resolve." | |
| summary: "Ingestion producer cannot read from a source" |
There was a problem hiding this comment.
I did not take “read”: this alert is getRaftId, i.e. reader setup, not a journal read. I Worded it as “cannot set up a source” so it does not collide with getRaftLog
| # alerts above stay far below their threshold when a single source is stuck. | ||
| - alert: IngestionProducerSourceSetupFailing | ||
| Expr: | | ||
| sum(rate(s3_ingestion_source_operations_total{op="getRaftId", status="error", namespace="${namespace}", job="${job_ingestion_producer}"}[5m])) |
There was a problem hiding this comment.
should we sum by bucket or location? So the alert points to the specific bucket/location which does not work?
There was a problem hiding this comment.
Not possible today. s3_ingestion_source_operations_total only has origin, op, status. No bucket and no location sum by would be empty and locationNameRaftID exists on the journal gauges, not on this counter. We can add a locationName label, but it would apply to every source op (getRaftLog, metadata, …), not only getRaftId. I would keep this alert cluster-wide for now and add the label in a follow-up if we want the firing alert to name the location.
| # be resolved fails continuously. It is a handful of errors against the reads | ||
| # of every healthy source, so it only shows up on the absolute rate: the ratio | ||
| # alerts above stay far below their threshold when a single source is stuck. | ||
| - alert: IngestionProducerSourceSetupFailing |
There was a problem hiding this comment.
this alert is a sub-class of the previous one (IngestionProducerSourceErrorRate5Percent) :
- Why does it not report issues? Is this because of the threshold, or because one location's error may be lost in the other location's success, or because other calls are incorrectly reducing the ratio?
- Should we adjust the threshold instead? Or skip some ops which are not relevant to the alert? Or sum by bucket/location?
There was a problem hiding this comment.
For me it is the aggregation. A stuck source retries getRaftId every few seconds and those errors are drowned by getRaftLog successes from healthy sources. Lowering the ratio would noisy-alert on read errors and filtering the existing ratio to op="getRaftId" would fire, but then “error rate 5%” would mean setup failure...
The dedicated absolute rate on getRaftId, with for: 10m, is the smallest change that names this failure mode in my opinion
Both rules of the source error rate pair were named IngestionProducerSourceErrorRate3Percent, so the critical one could not be told apart from the warning one. Name it after the threshold it uses, as the zookeeper and publish error rate pairs already do. Issue: BB-605
A source whose setup fails is now retried on every cron tick, so it reports a getRaftId error roughly every five seconds for as long as it cannot be resolved, while its location ingests nothing. Nothing reports it today: the journal size and read offset gauges of that source are never published, so the lag and NoMessagesQueued alerts stay blind, and the error ratio alerts drown the failures in the reads of every healthy source, which are orders of magnitude more frequent. Alert on the absolute rate of getRaftId errors instead, which is only called to set a reader up. Ten minutes of sustained failures are needed to fire, so a source that recovers on its own, typically while its location restarts, does not alert. Issue: BB-605
The ingestion alerts were the only ones shipped without a rendering and unit test step, so a rule could be published broken or silent. Cover the new setup failure alert: it fires on a source that keeps failing, stays silent on one that recovers, and the ratio alerts are asserted silent on the same series to pin down why it is needed. Issue: BB-605
getRaftId is reader setup. Calling it a read failure would collide with getRaftLog. Issue: BB-605
a682dd2 to
0c452ac
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following reviewers are expecting changes from the author, or must review again: |
|
Assigning @DarkIsDude for review since Mael is on PTO |
4 participants
Issue: BB-605