Monitoring en logs

Health en readiness

Onderdeel	Endpoint	Wat het zegt
control plane	GET /healthz	status (ok of degraded), de DID, de versie en per onderdeel de toestand
data plane	GET /healthz	of het proces leeft, de versie, of deze instance actief is, of het vastleggen van bewijs lukt, en het aantal verloren logregels
data plane	GET /readyz	200 alleen voor de actieve instance; een instance in standby geeft 503
gebouwservice	GET /healthz	de versie en of de database bereikbaar is; zo niet, dan 503

De /healthz van de control plane antwoordt altijd met 200; kijk naar status en de onderdelen. status is degraded als de database niet bereikbaar is of het vastleggen van bewijs faalt, want dan gaat er geen protocolbericht meer door.

Onderdeel in components	ok	anders
database	PostgreSQL antwoordt	down
redis	Redis antwoordt	down: niemand kan inloggen
evidence	vastleggen lukt	degraded: het mislukte in de laatste vijf minuten minstens één keer
anchoring	nieuw bewijs krijgt op tijd een anker bij de notaris	degraded: de notaris weigert de keten, bijvoorbeeld na een herstel (zie back-up), of nieuw bewijs wacht langer dan tien minuten op een anker
dataplane	de data plane is actief en legt vast	degraded: hij staat in standby of het vastleggen faalt; down: geen antwoord
authority	de Trust Authority antwoordt	down

Je connector probeert elke minuut te verankeren. Lukt dat niet, bijvoorbeeld omdat de Trust Authority onbereikbaar is, dan gaat anchoring op degraded zodra het oudste bewijs zonder anker ouder is dan tien minuten (BL_ANCHOR_STALE_AFTER). Een connector zonder nieuw bewijs heeft niets te verankeren en blijft ok. Weigert de notaris de keten, dan is het meteen degraded, en dat blijft zo tot er weer een anker lukt, ook na een herstart van de connector of Redis. Het laatste anker, de laatste fout met de reden en het aantal mislukte pogingen staan onder Bewijs en in GET /api/v1/evidence/anchoring.

Een mislukte poging komt als warn in het log, een weigering door de notaris als error: de eerste meteen, daarna hooguit één regel per kwartier met het aantal pogingen dat niet gelogd is. Lukt verankeren weer, dan meldt een regel op info na hoeveel mislukte pogingen.

De control plane vraagt voor dataplane en authority zelf hun /healthz op, met een time-out van drie seconden per stuk. Gebruik /healthz van de control plane daarom niet als liveness-probe met een korte time-out; een trage Trust Authority is geen reden om je connector te herstarten. Voor de data plane is /healthz de liveness en /readyz de readiness.

Dezelfde toestand staat in de beheeromgeving onder Status, met het verkeer van de data plane. De Trust Authority vraagt /healthz van je control plane ook zelf op, elke 15 seconden.

Logs

Alle onderdelen schrijven alleen naar stdout. Bewaren doet je container-runtime of een logverzamelaar naast de connector.

• RUST_LOG bepaalt het niveau, standaard info (met sqlx en hyper op warn). Een niveau per module kan ook, zoals RUST_LOG=info,connector=debug.
• BL_LOG_JSON=true schrijft elke regel als JSON, voor een logverzamelaar.
• Een request wacht nooit op het log. De regels gaan via een buffer van 100.000 regels; is die vol, dan vallen regels weg in plaats van dat de dienst vertraagt. Hoeveel er verloren gingen, zegt log_lines_dropped in /healthz van de data plane.

Het verzoekenlog

De data plane schrijft per verzoek op /public en /gateway een regel naar stdout, onder de target request, volgens het niveau dat je kiest onder Instellingen, Verzoekenlog. Een wijziging werkt binnen tien seconden; daarvoor heb je de rol operator of admin nodig.

Niveau	Wat erin komt
Uit	niets; de tellers voor de schermen lopen gewoon door
Fouten	verzoeken waarbij de data plane zelf faalt (error)
Waarschuwingen	daarnaast weigeringen, trage verzoeken en 5xx van je systeem (warn); de standaard. Weigeringen hooguit tien per minuut per soort en tegenpartij, de rest in één samenvattende regel
Alles	elk verzoek, de beantwoorde op info

Vanaf wanneer een verzoek traag is, stel je daar ook in (standaard 1000 ms). Tot je het in de beheeromgeving instelt, gelden BL_REQUEST_LOG (off, errors, warnings of all) en BL_REQUEST_SLOW_MS van de data plane. Op all kost het loggen de data plane een paar procent CPU en ongeveer 320 bytes per verzoek; zet het daarom alleen tijdelijk aan, bij het zoeken naar een probleem.

TechnischHet verzoekenlog bewaren en terugzoeken

Laat een logverzamelaar, zoals Vector of Fluent Bit, de regels met target request apart wegschrijven naar S3-compatibele opslag, onder requests/<deelnemer>/dt=<JJJJ-MM-DD>/hour=<UU>/level=<error|warn|info>/ (UTC), als JSON Lines met gzip. Geef de verzamelaar een sleutel die alleen mag schrijven, en zet een levenscyclusregel op de prefix.

Dan leest de connector het log terug, met BL_LOG_STORE_URL (s3://<bucket>/requests/<deelnemer>), BL_LOG_STORE_ENDPOINT, BL_LOG_STORE_REGION en een sleutel die alleen die prefix mag lezen (BL_LOG_STORE_ACCESS_KEY, BL_LOG_STORE_SECRET_KEY). Het endpoint is GET /api/v1/request-log?from&to&level&counterparty&process, voor de rol viewer, hooguit 31 dagen per vraag. Zonder opslag antwoordt het met 503. Vanaf de command line:

bl login https://connector.example.nl
bl logs requests --from 2026-10-01T08:00 --to 2026-10-01T12:00 --level warn

Draait de connector niet, dan leest bl logs requests --direct de opslag zelf, met een leessleutel in AWS_ACCESS_KEY_ID en AWS_SECRET_ACCESS_KEY en het adres in AWS_ENDPOINT_URL. bl logs runtime --direct doet hetzelfde voor de gewone logs van de diensten, als je verzamelaar die onder runtime/ schrijft.

Statistiek

De beheer-API geeft het verkeer en de processen, voor de rol viewer:

Endpoint	Wat
GET /api/v1/stats	onderhandelingen en leveringen per status, het aantal overeenkomsten en vastleggingen, en van de data plane over 24 uur: verzoeken, fouten, weigeringen, p50 en p95 en een reeks per uur; met de toestand van de onderdelen en de laatste heartbeat
GET /api/v1/stats/live	verzoeken en fouten per minuut over het laatste uur, licht genoeg om elke paar seconden op te vragen
GET /api/v1/activity	de laatste gebeurtenissen uit het eigen activiteitenlog
GET /api/v1/outbox	berichten aan tegenpartijen die nog verstuurd moeten worden of zijn mislukt
GET /api/v1/evidence/anchoring	of verankeren werkt, met het laatste anker en de laatste fout

In deze cijfers telt elke 4xx en 5xx als fout, dus ook een terechte 404 van je systeem. De data plane telt per minuut en schrijft de tellers elke 10 seconden weg; ze blijven 90 dagen (BL_REQUEST_COUNTS_DAYS). Er is geen Prometheus-endpoint.

Een bericht aan een tegenpartij probeert de connector af te leveren tot het 24 uur oud is (BL_OUTBOX_MAX_AGE). Daarna staat het op mislukt, en kan een operator het opnieuw laten versturen of laten vallen.

Wat de Trust Authority ziet

Zodra je connector lid is, stuurt hij elke 30 seconden een heartbeat naar de Trust Authority. Hoeveel erin staat, kiest een admin onder Instellingen, Telemetrie:

Niveau	Wat de Trust Authority krijgt
Alleen gezondheid	de versie en de toestand van de onderdelen
Gezondheid en aantallen	daarnaast de aantallen uit /api/v1/stats
Gezondheid, aantallen en activiteit	daarnaast de gebeurtenissen: soort, tijdstip en tegenpartij, met een pseudoniem in plaats van het id van het proces; de standaard

De inhoud van berichten en data gaat nooit mee.