Context
Two recently-added anomaly signals currently dead-end at a bare log line with no way for a human to see them without already knowing to grep for them:
reviewBurst/reviewFailureBurst (src/review/ops-wire.ts:124-197) — gated behind GITTENSORY_REVIEW_OPS (off by default); on detection, does exactly console.error(JSON.stringify({level:"error", event:"ops_anomaly", ...})). Correctly event:-keyed (unlike the other logging-key issue in this batch), so it can reach Sentry — but there is no Prometheus metric, no Grafana panel, and no alert rule referencing ops_anomaly, review_burst, or reviewFailureBurst anywhere in prometheus/rules/ or grafana/dashboards/.linked_issue_label_propagation_filtered (src/review/linked-issue-label-propagation-fetch.ts:75-83) — tracked separately under the logging-key-rename issue since it's also ev:-keyed, but even once renamed, it has no metric/panel/alert either.
Requirements
- Emit a counter metric (e.g.
incr("gittensory_ops_anomaly_total", { repo, kind })) alongside the existing console.error in ops-wire.ts:188.
- Add one Prometheus alert rule (e.g.
increase(gittensory_ops_anomaly_total[1h]) > 0) and one Grafana panel for it.
- Add panels for
gittensory_reviews_published_total and gittensory_gate_decisions_total — both already emitted, currently undashboarded and unalerted, and the two metrics most directly answering "what did the review pipeline do to this PR."
- Document that
GITTENSORY_REVIEW_OPS has no practical value without either SENTRY_DSN set or a Loki alert on {event="ops_anomaly"} — currently a silent dependency.
Deliverables
- New metric emission in
src/review/ops-wire.ts.
- New/updated files under
prometheus/rules/ and grafana/dashboards/.
- A doc note on the
GITTENSORY_REVIEW_OPS dependency.
Expected outcome
A review-burst or repeated-failure anomaly is visible on a dashboard and can page/alert a human, instead of requiring someone to already be tailing container logs.
Context
Two recently-added anomaly signals currently dead-end at a bare log line with no way for a human to see them without already knowing to grep for them:
reviewBurst/reviewFailureBurst(src/review/ops-wire.ts:124-197) — gated behindGITTENSORY_REVIEW_OPS(off by default); on detection, does exactlyconsole.error(JSON.stringify({level:"error", event:"ops_anomaly", ...})). Correctlyevent:-keyed (unlike the other logging-key issue in this batch), so it can reach Sentry — but there is no Prometheus metric, no Grafana panel, and no alert rule referencingops_anomaly,review_burst, orreviewFailureBurstanywhere inprometheus/rules/orgrafana/dashboards/.linked_issue_label_propagation_filtered(src/review/linked-issue-label-propagation-fetch.ts:75-83) — tracked separately under the logging-key-rename issue since it's alsoev:-keyed, but even once renamed, it has no metric/panel/alert either.Requirements
incr("gittensory_ops_anomaly_total", { repo, kind })) alongside the existingconsole.errorinops-wire.ts:188.increase(gittensory_ops_anomaly_total[1h]) > 0) and one Grafana panel for it.gittensory_reviews_published_totalandgittensory_gate_decisions_total— both already emitted, currently undashboarded and unalerted, and the two metrics most directly answering "what did the review pipeline do to this PR."GITTENSORY_REVIEW_OPShas no practical value without eitherSENTRY_DSNset or a Loki alert on{event="ops_anomaly"}— currently a silent dependency.Deliverables
src/review/ops-wire.ts.prometheus/rules/andgrafana/dashboards/.GITTENSORY_REVIEW_OPSdependency.Expected outcome
A review-burst or repeated-failure anomaly is visible on a dashboard and can page/alert a human, instead of requiring someone to already be tailing container logs.