Add dashboards and alerts as code, mark Phase 6 done

Dashboards: observability/dashboards/generate.py (Grafana Foundation SDK)
writes k8s/grafana/dashboards/*.json -- a RED dashboard per HTTP service
and a system overview -- shipped through a file provider and
configMapGenerators, so `kubectl apply -k k8s/` rebuilds them. Verified by
deleting Grafana and its volume and re-applying. Adds tracesToMetrics to
the Tempo datasource.

Alerts: Prometheus rule files delivering to Alertmanager, under a
labels/annotations contract enforced by observability/alerts/check_contract.py,
with runbooks in docs/runbooks/.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
Movses Aslanyan
2026-10-25 20:01:52 +03:30
co-authored by Claude Sonnet 5.5
parent b50f8c3b24
commit fef735c922
19 changed files with 1314 additions and 7 deletions
@@ -0,0 +1,27 @@
# LedgerlineHighErrorRatio
**Fires when:** a service's 5xx ratio is above 5% for 5 minutes, with more than
0.05 requests/s (so it is not one failed request on an idle service).
**Severity:** warning · **Team:** payments
## What it means
A meaningful share of the requests this service serves are failing with a server
error. 4xx responses (for example a 404) are deliberately not counted.
## First five minutes
1. **Look at the `RED: <service>` dashboard** (linked in the alert). Is the error
ratio still elevated, or already back to normal? Did the request rate or the
latency change at the same time?
2. **Find a failing request.** In Tempo, search for the service with an error
status, or in Loki: `{service_name="<service>"} | json | level="ERROR"`.
3. **Follow one trace.** The `trace_id` in the log line opens the whole request
across services. Look for the first span in the trace with an error status.
4. **Is it only this service?** The System overview's service graph shows whether
its callers or callees are failing as well.
## Escalate when
The ratio is still rising after ten minutes, or the failing requests are on the
critical path (transactions), not a side route.
+29
View File
@@ -0,0 +1,29 @@
# LedgerlineTargetDown
**Fires when:** Prometheus has failed to scrape a Ledgerline service for 2 minutes.
**Severity:** critical · **Team:** platform
## What it means
Prometheus scrapes all seven services through one address,
`https://ledgerline.vione.cloud/metrics/<service>` (czy's Traefik, basic auth).
"Down" means that scrape failed. It does **not** by itself prove the service is
down: the service, the proxy, or the credentials can each cause it.
## First five minutes
1. **How many targets?** Open the alert in Alertmanager. One service alerting is
likely that service. All seven at once points at the shared path (Traefik on
czy, DNS, the scrape credentials), not at the services.
2. **Ask Prometheus why.** In Prometheus → Status → Targets, find the target and
read its `Last error`.
3. **Is the container running?** `ssh czy docker compose ps` for the service.
4. **What did it last say?** `ssh czy docker logs ledgerline-<service>-1`, or in
Loki: `{service_name="<service>"}`.
5. **Is traffic still flowing?** Open the `RED: <service>` dashboard. Traces and
logs can still be arriving while only the metrics scrape is broken.
## Escalate when
The shared path is down (all seven targets), or the service is down and not
recovering after a restart.