chore(infra): `GET /healthz?deep=1` through the database and a `status.woven` probe; SLO measured on it

Offen
  • Stimmt etwas nicht?
#42 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
postgresql, rust
Bereich
backend, databases, observability

Rechercherichtung

Start with crates/thrust-api/src/lib.rs and the Database port in crates/thrust-ports/src/lib.rs; read the existing /healthz handler and the blocker #37 outcome before choosing the probe path. Check the contract test and the Gatus configuration in the infrastructure repository, since both repositories are involved. Done means the deep probe reports database availability, Gatus records it as the SLO source, and the specified ADR, questions, and spec updates are complete.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area:infra prio:p0 review:fable-2026-10-19

Context

/healthz returns ok without touching the database (crates/thrust-api/src/lib.rs:132-134, mounted at line 271; research/0004:389), and the Database port has no ping method (crates/thrust-ports/src/lib.rs:92-138). status.woven is the Gatus page, configured in shared/aws/status-page/files/gatus.yaml in the infra repository (process: infrastructure/.claude/rules/status-page.md). It does not probe the Thrust database path (research/0010:176). Q-0130.3 was answered in round 18: Gatus probes health and API SLIs (QUESTIONS.md:247). The SLO is 99.5 % availability (SPEC.md:78), which over 30 days allows about 3.6 hours of downtime.

Problem

Product availability now includes:

  • woven-o11y, an observability cluster that was upgraded from 1.32 to 1.37 four days before the Postgres landed, with a primary PodDisruptionBudget of 0 on thrust-pg;
  • the tunnel's cloudflared pods, which both clusters share;
  • a beta Workers VPC (ADR-0094:39; research/0010 §6 risks 1, 2 and 7).

Q-0094.4 (QUESTIONS.md:303) asks whether that is acceptable for the SLO and whether status.woven should probe the path; Q-0094.7 (QUESTIONS.md:339) lists the probe too. Nothing measures the coupling today, so a breach of the budget would go unseen.

Proposal

Answer Q-0094.4 with three conditions (ADR-0094 round-29 note):

  1. Deep probe. GET /healthz?deep=1 on the product hostname runs one statement through the database and returns 200 ok, or 503 with no error detail; plain /healthz stays database-free. Add an untenanted ping to the Database port (under the SystemScope from #35). Use a statement that Hyperdrive never caches, such as SELECT now(): Hyperdrive caches reads that use only IMMUTABLE functions, so select 1 could be answered from its cache on any config with caching enabled (hyperdrive/concepts/query-caching). If #37 picks the Durable Object, the probe goes through the object instead.
  2. Probe and SLO. status.woven probes that URL every 60 s, and the SLO is measured on the probe end to end, so cluster upgrades and tunnel outages count against the budget.
  3. Exit trigger, written into ADR-0094: two breaches of the monthly budget in one quarter, or an EKS upgrade that needs more than the budget, moves the database to ADR-0094 Option 3 (managed Postgres) or to the #37 outcome.

The probed path must stay outside any Access gate. The prober is a non_identity WARP session, and gating a probed host breaks it (ADR-0141:17). Product hostnames are planned behind Access (SPEC.md:89), so the bypass for /healthz belongs with #50.

Acceptance criteria

  • Contract test deep_healthz_reports_the_database returns 200 with the database up and 503 with it unreachable. The control is a Connector that always fails, or a stopped native-pg container.
  • curl -s http://status.woven/api/v1/endpoints/statuses lists the Thrust deep probe with recent results. A deliberate failure (stopping the dev database, or pointing at a wrong path) turns it red within two intervals, and it turns green again afterwards.
  • A 30-day availability figure is read from the probe's Gatus uptime, and SPEC §6.4 and Q-G5.2 name the probe as the SLO source.
  • ADR-0094 carries the exit trigger, Q-0094.4 is answered, and the probe item of Q-0094.7 is closed.

References

  • Review: .agents/plans/contrail/reviews/2026-10-19-fable-architecture-review.md (FR-10)
  • crates/thrust-api/src/lib.rs:132-134,271; crates/thrust-ports/src/lib.rs:92-138
  • ADR-0094 (.agents/plans/contrail/adrs/infra/0094-postgres-hosting-cnpg-tunnel-vpc.md:39,44,58-61); ADR-0141:17; ADR-0130 (Q-0130.3)
  • Q-0094.4 (QUESTIONS.md:303), Q-0094.7 (QUESTIONS.md:339), Q-G5.2 (QUESTIONS.md:299); SPEC §6.4 (SPEC.md:78,83,89)
  • research/0010-thrust-postgres-infra-plan.md:174-187; research/0004-rust-on-workers-binding-matrix.md:389
  • Infra repository: shared/aws/status-page/files/gatus.yaml, infrastructure/.claude/rules/status-page.md
  • Cloudflare docs: hyperdrive/concepts/query-caching

Blocked by: #37

Finding: FR-10

Vorherrschende Sprache
Rust
Sterne
0
Forks
0
Ø Merge
1 Std. 35 Min.
Gemergte PRs (30 T.)
67

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aRustyDev/thrust

Alle Issues in aRustyDev/thrust

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.