Observer tjenesten og brukerne

Start med spørsmålet

Overvåking kontrollerer kjente forhold. Observability hjelper dere å undersøke systemoppførsel, også feil dere ikke forutså. Flere dashbord gir ikke automatisk bedre svar.

For en fiktiv eksporttjeneste starter dere med et brukerspørsmål: Kan en autorisert bruker få riktig eksport innen avtalt tid? Velg deretter signaler som støtter dette spørsmålet og bidrar til å forklare feil.

OpenTelemetry tilbyr instrumentering og standarder for telemetri. Det kan sende signaler til kompatible backender. Dere trenger fortsatt lagring, spørringer, tilgangskontroller, oppbevaring og folk som handler på grunnlag av bevisene. Innføring i observability.

Koble sammen ulike former for bevis

Et måltall måler en størrelse over tid. En logg registrerer en hendelse. Et spor knytter sammen relaterte operasjoner mens en forespørsel beveger seg gjennom et system. Et spenn representerer én operasjon i et spor.

For asynkront arbeid må dere bevare en trygg kobling mellom den innsendte jobben og kjøringen hos arbeideren. Et HTTP 202-svar kan bety at arbeidet ble mottatt. Det beviser ikke at eksporten ble ferdig.

Varsle når handling er nødvendig

Definer SLI og nevneren før dere setter SLO. I eksemplet teller dere gyldige eksporter som fullføres riktig innen avtalt varighet. Definer hvordan langvarige og avbrutte jobber tas med i målingen.

Et feilbudsjett beskriver tillatte feil innenfor SLO-perioden. En forbruksrate beskriver hvor raskt feil bruker opp budsjettet. Googles veiledning bruker flere tidsvinduer for å balansere rask oppdagelse og varslingsstøy. Varsling basert på SLO-er.

Tilkall noen når tilstanden krever handling innen kort tid. Send mindre hastende arbeid til en kø. Hvert varsel trenger en eier, beskrivelse av innvirkning, lenke til undersøkelsen og instruksjon for respons. Gjennomgå varsler som gjentatte ganger ikke fører til handling.

Ikke bruk én generell terskel for alle tjenester. Brukerinnvirkning, trafikk, åpningstider og responskapasitet påvirker beslutningen.

Beskytt telemetripipelinen

Telemetri kan inneholde personopplysninger, tokens, forespørselsparametere og konfidensielle dokumenter. Definer tillatte felt før innsamling. Begrens tilgang og oppbevaring. Fjern hemmeligheter før eksport til en ekstern backend. Sensitiv telemetri.

Ikke bruk en kundes e-postadresse eller en unik jobb-ID som etikett i et måltall. Ubegrensede etiketter øker antallet tidsserier og kan eksponere identifikatorer. Bruk kontrollerte dimensjoner for måltall. Legg godkjente korrelasjonsidentifikatorer i tilgangsstyrte logger eller spor.

Mål selve pipelinen. Kontroller innlesingsfeil, forkastede data og alderen på den siste observasjonen. Et flatt feildiagram kan bety ingen feil eller ingen innkommende telemetri. Vis denne forskjellen.

Undersøk en konkret feil

Den fiktive tjenesten rapporterer HTTP 202 for hver forespørsel. Alderen på elementene i køen øker fra sekunder til 15 minutter. Arbeiderloggene viser gjentatte tidsavbrudd mot databasen. Utvalgte spor plasserer mesteparten av arbeidertiden i databasekall.

Disse bevisene støtter en målrettet undersøkelse. De fastslår ikke om årsaken er en endret spørring, oppbrukte forbindelser eller databasekapasitet. Sammenlign hypotesene med feilsøkingsmetoden.

Taiga Monitoring gir en visning av produktets tilstand med signaler for tilgjengelighet og nettleseropplevelse. Det utfyller observability for infrastruktur og applikasjon; det erstatter ikke disse systemene. Monitoring.