Skip to content

Kontrollrom

Kontrollrommet er den felles hendelsesinngangen for Team eSyfos operative flåte. Det starter med forventede ressurser fra runtimeinventaret og fyller inn bevist telemetry. En app kan derfor ikke forsvinne fra oversikten bare fordi signalet mangler.

Leveransen er coverage-first: det vi kan måle korrekt vises live; det vi ikke kan bevise står som UKJENT, IKKE DEFINERT, IKKE EVALUERT eller BLOCKED. #211 forblir åpen til browser-, pipeline-, SLO- og deploykontraktene faktisk er levert.

Firetrinns hendelsesløype

  1. Handle nå: Se etter OTel-feilstatus, runtimefeil, restarts og lav ready/desired. Les alltid span- og kube-dekning ved siden av.
  2. Finn raden: Flåtematrisen viser forventet tjeneste, kritikalitet, livssyklus, telemetry og observerte avvik. Manglende signal gjør raden rød/ukjent; den forsvinner ikke.
  3. Avgrens én tjeneste: Velg runtime i Detaljtjeneste. Request-rate, OTel-feilratio og P95 gjelder da bare denne identiteten, ikke en uleselig miks av hele flåten.
  4. Følg runbook og drilldown: Hver runtime og pagerkandidat lenker til APM, avgrensede logger, Feiloversikt og relevant runbook.

Operativt område filtrerer bare oversiktskortene og flåtematrisen. Detaljtjeneste styrer bare detaljpanelene og er uavhengig av området. Faste seksjoner har sitt eget scope og endres ikke av valgene.

Tilstandsord

DimensjonTillatte tolkninger
BrukerimpactPÅVIST, INGEN PÅVIST IMPACT, UKJENT
Teknisk helseOK, DEGRADERT, FEILET, UKJENT
TelemetryFERSK, STALE, MANGLER, datasourcefeil
TrafikkAKTIV, forventet nulltrafikk, uventet nulltrafikk, UKJENT
KontraktVERIFISERT, IKKE DEFINERT, IKKE EVALUERT, BLOCKED

Kontrollrommet lager ikke én samlet grønn status. Den tidligere sykepengedager-informasjon-hendelsen demonstrerte hvorfor: HTTP-sporene kunne vise ingen påvist synkron impact samtidig som runtimefeil og restarts viste reell teknisk degradering.

Hva dashboardet dekker

Runtime

  • Scope velges som hele flåten eller ett av ni kuraterte operative områder.
  • Runtimeinventaret per 28. august 2026 gir 26 forventede GCP-appkomponenter i den generiske flåten.
  • De tre avviklede syfooppfolgingsplanservice-komponentene i FSS er ikke generiske flåterader eller del av dekningsnevneren. Hvis de fortsatt observeres etter tjenestestoppen, vises de som runtime-drift som følges i #208.
  • RED bruker traces_spanmetrics_calls_total og traces_spanmetrics_latency_bucket, avgrenset til service_namespace=team-esyfo, k8s_cluster_name=prod og span_kind=SPAN_KIND_SERVER for de 24 profilene med HTTP/SERVER-kontrakt.
  • esyfovarsel og syfo-budstikka er workers. De står som ANNEN KONTRAKT i SERVER-kolonnen og inngår ikke i SERVER-dekningsnevneren; deres operative kontroll ligger i pipeline-/jobbsignalene.
  • OTel STATUS_CODE_ERROR omtales som spanstatus, ikke automatisk HTTP 5xx eller bevist brukerimpact.
  • De to Dine sykmeldte-panelene avgrenser GET /api/minesykmeldte og GET /api/virksomheter. Rute-/labelkontrakten og 200/STATUS_CODE_UNSET er live-verifisert mot NAIS APM-spanmetrikker. 2xx uten OTel-feilstatus er good; 4xx uten OTel-feilstatus vises nøytralt som http_4xx, mens 5xx eller OTel-feilstatus er technical_failure. Texas kan maskere tekniske introspeksjonsfeil som 401, så 4xx kalles ikke forventet før et bounded appsignal skiller årsakene i dinesykmeldte-backend#729.
  • Kube-signaler dedupliseres og desired=0 filtreres bort.
  • Flåtematrisen teller bare positivt klassifiserte detected_level=error|critical|fatal siste fem minutter. Browserlogger videresendt via next-logger med x_isFrontend=true er ekskludert fra runtimekategorien; browser-exceptions måles separat i Faro der det er konfigurert. Matrisen gjør ikke en ekstra full-loggskann for å konstruere null; No data er ukjent. Valgt tjeneste kan undersøkes over dashboardets valgte tidsrom.

Telemetrykolonnen er inventarforankret:

  • FERSK: aktuell SERVER-spanserie finnes for en SERVER-eligible profil. Det måler scrape-/seriesignal, ikke siste request.
  • STALE: serien er sett siste 30 minutter, men er ikke aktuell.
  • MANGLER: ingen serie siste 30 minutter for en SERVER-eligible profil.
  • ANNEN KONTRAKT: workerprofil som ikke skal vurderes med inbound SERVER-spans.
  • En datasourcefeil feiler queryen og blir aldri mappet til MANGLER eller grønt.

Browser

Kontrollrommet viser en kompakt browserstatus og en diagnostisk exception-graf. Det detaljerte runtimeinventaret viser de 11 browserflatene, kildekodekonfigurasjon, browseridentitet, side-ID, privacygap og høy-impact issue. Bare Faro kind=exception er live-verifisert i denne leveransen. Miljødimensjonen er ikke verifisert, så exception-grafen har ukjent miljøscope og må ikke omtales som produksjonsstatus. #206 definerer browserkontrakten; page loads, sessions og CWV p75 står eksplisitt ukjent til den enkelte flaten har bevist identitet, miljø, numerisk samplingrate og queryschema i sin rollout.

En sampled exception, page load eller session skal aldri omtales som en unik bruker. Verdier med ulik samplingrate skal ikke summeres.

Pipelines og jobber

Kontrollrommet viser fortsatt samlet pipelinehelse som IKKE EVALUERT, ikke som et feilresultat. Som første avgrensede tekniske slice viser det nå poll-alder per pod og committed consumer-group-lag for sykmeldingstopicen inn til syfo-oppfolgingsplan-backend. Poll-alder viser sekunder siden Kafka-klienten kalte poll(); committed lag viser observert transportbacklog. Begge er diagnostikk, ikke alene bevis på korrekt behandling, ende-til-ende-leveranse eller brukerimpact. No data er UKJENT.

Sju pipelinegrupper og ti team-topics er kartlagt i runtimeinventaret, mens Kafka-kontraktene skiller bevist nåtilstand fra åpne beslutninger. Operativ helse kan først evalueres når #212 har godkjent frister, nulltrafikk, progresjon og terminale utfall.

Varslingsreisen viser syfo-budstikka som målprosessor og esyfovarsel som migrerende legacy-prosessor. Airflow er ekstern sekundærkonsument og er utenfor scope. esyfovarsel-job får kun et tidsavgrenset Kubernetes failure-guardrail; No data betyr ikke suksess.

Pager readiness

De tre kandidatene fra #210 har egne diagnostikkpaneler og runbooklenker:

  • Budstikka-lag er kun transportdiagnostikk. Produsentens outbox og Budstikkas egne inbox-/delivery-køer vurderes separat i #212 og rulles ut via #219.
  • Oppfølgingsplan har et verifisert legacy-signal for observerte deserialiseringsfeil. Signalet skiller ennå ikke terminal forkasting fra retryforsøk; dette og recovery/reconciliation avklares i syfo-oppfolgingsplan-backend#449.
  • syfomotebehov har guarded ready/desired sammen med single-service RED; tuning og konsekvens avklares i syfomotebehov#753.

Alle tre står BLOCKED. Dashboard og runbook aktiverer ikke pager; aktivering krever observasjonsperiode, shadow-evidens, second-person-verifikasjon og eksplisitt beslutning i #217.

Kjente gap

  • SLO-burn er IKKE DEFINERT; alert-policy er ikke en SLO-kontrakt.
  • Siste deploy er UKJENT; pod-alder og kube_deployment_created brukes ikke som deploybevis.
  • Browser page loads/sessions/CWV venter på live-evidens fra utrullingen per flate.
  • Topic-/pipelineutfall venter på #212 og deretter konkrete adaptere.
  • Legacy-jobben mangler siste start, siste suksess og forventet-run-evaluering.

Runbooks

For vedlikeholdere

Builderen ligger i .vitepress/grafana/control-room.ts, mens inventarscope og generert operatørtekst ligger i .vitepress/grafana/control-room-scope.ts. Den reviewbare Grafana-ressursen genereres deterministisk.

Kjør fra docs/:

bash
pnpm control-room:test
pnpm control-room:export
pnpm control-room:check
pnpm grafana-dashboard:smoke
pnpm build

grafana-dashboard:smoke krever Docker og eksponerer Grafana kun på 127.0.0.1. Den starter en midlertidig Grafana med samme versjon som dashboardbyggeren, importerer den eksakte Kontrollrom- og Feiloversikt-artefakten gjennom v2-API-et og sammenligner både lagret ressurs og UI-ens DTO semantisk. Containeren og engangspassordet fjernes etter testen. Smoken kjører ikke datasource-queryene og rendrer ikke panelene; dette må fortsatt verifiseres i Grafana som beskrevet under. Kommandoen kjører også som et eget steg i dokumentasjonsbygget i CI.

Før publisering skal artefakten importeres med UID team-esyfo-kontrollrom i Team eSyfo-mappen K-1b-N_4k. Velg Team Esyfo eksplisitt også ved overwrite. Verifiser minst:

  • hele flåten og ett kuratert operativt område,
  • en valgt backend, frontend og worker,
  • påvist runtimefeil uten OTel-feil,
  • nulltrafikk, STALE, MANGLER og datasourcefeil,
  • de tre pagerpanelene og alle runbook-/drilldownlenker,
  • at browser, pipeline, SLO og deploy fortsatt står ukjent når kontrakten mangler.

Standardvisningen er én time med to minutters refresh. Bruk Grafana Query Inspector før overwrite til å kontrollere queryfeil, svartid og skannede bytes. Flåte-Loki leser bare et fast femminuttersvindu; øk tidsrom eller refreshfrekvens bevisst under drilldown, ikke som permanent default.

Referanser

Laget av Team eSyfo ❤️