Maak de service en gebruikerservaring inzichtelijk

Begin met de vraag

Monitoring controleert bekende omstandigheden. Observability helpt systeemgedrag te onderzoeken, inclusief storingen die u niet had voorspeld. Meer dashboards leveren niet automatisch betere antwoorden.

Begin bij een fictieve exportservice met een gebruikersvraag: kan een geautoriseerde gebruiker de juiste export binnen de afgesproken tijd ontvangen? Kies daarna signalen die deze vraag ondersteunen en storingen helpen verklaren.

OpenTelemetry biedt instrumentatie en standaarden voor telemetrie. Het kan signalen naar compatibele backends sturen. U hebt nog steeds opslag, queries, toegangscontroles, bewaartermijnen en mensen nodig die op het bewijs handelen. Inleiding tot observability.

Verbind verschillende vormen van bewijs

Een metric meet een grootheid over tijd. Een log legt een gebeurtenis vast. Een trace verbindt gerelateerde bewerkingen terwijl een aanvraag door een systeem gaat. Een span vertegenwoordigt één bewerking binnen een trace.

Behoud bij asynchroon werk een veilige koppeling tussen de ingediende job en de uitvoering door de worker. Een HTTP 202-respons kan betekenen dat werk is geaccepteerd. Die bewijst niet dat de export is voltooid.

Meld wanneer actie nodig is

Definieer de SLI en de noemer voordat u de SLO vaststelt. Tel in dit voorbeeld geldige exports die correct binnen de afgesproken duur zijn voltooid. Definieer hoe langlopende en afgebroken jobs in de meting meetellen.

Een error budget beschrijft de toegestane fouten binnen het SLO-venster. Een burn rate beschrijft hoe snel fouten dat budget verbruiken. De richtlijnen van Google gebruiken meerdere tijdvensters om tijdige detectie en onnodige meldingen in balans te houden. Meldingen op basis van SLO’s.

Roep iemand op wanneer de situatie tijdig handelen vereist. Zet minder dringend werk in een wachtrij. Elke melding heeft een verantwoordelijke, een beschrijving van de impact, een onderzoeklink en een responsinstructie nodig. Beoordeel meldingen die herhaaldelijk tot geen actie leiden.

Gebruik niet één algemene drempelwaarde voor elke service. Gevolgen voor gebruikers, verkeer, kantooruren en responscapaciteit beïnvloeden de beslissing.

Bescherm de telemetriepipeline

Telemetrie kan persoonsgegevens, tokens, aanvraagparameters en vertrouwelijke documenten bevatten. Definieer toegestane velden vóór het verzamelen. Beperk toegang en bewaartermijnen. Verwijder secrets voordat u gegevens naar een externe backend exporteert. Gevoelige telemetrie.

Gebruik geen e-mailadres van een klant of unieke job-ID als metriclabel. Onbegrensde labels vergroten het aantal tijdreeksen en kunnen identificaties blootstellen. Gebruik gecontroleerde dimensies voor metrics. Plaats goedgekeurde correlatie-ID’s in logs of traces met toegangscontrole.

Meet ook de pipeline zelf. Controleer fouten bij de inname, weggevallen gegevens en de ouderdom van de laatste waarneming. Een vlakke foutengrafiek kan betekenen dat er geen fouten zijn, of dat geen telemetrie binnenkomt. Maak dat verschil zichtbaar.

Onderzoek een concrete storing

De fictieve service geeft voor elke aanvraag HTTP 202 terug. De wachttijd in de wachtrij stijgt van seconden naar 15 minuten. Workerlogs tonen herhaalde databasetime-outs. Traces uit een steekproef plaatsen het grootste deel van de workertijd in databaseaanroepen.

Dit bewijs ondersteunt gericht onderzoek. Het toont niet aan of de oorzaak een gewijzigde query, uitgeputte verbindingen of databasecapaciteit is. Vergelijk deze hypotheses met de debugmethode.

Taiga Monitoring biedt een overzicht van de productgezondheid met signalen voor beschikbaarheid en browserervaring. Het vult observability voor infrastructuur en applicaties aan; het vervangt die systemen niet. Monitoring.