Winst:
- Vermogen om de drie pijlers van waarneembaarheid (metrisch, log, trace) en de vier gouden signalen te begrijpen en kunstmatige intelligentie PromQL-query's, alarmregels en dashboards te laten genereren
- Mogelijkheid om alarmmoeheid te voorkomen door alarmen actiegericht en met de juiste urgentie te houden en drempels te testen aan de hand van de historische gegevens van uw eigen systeem
- Mogelijkheid om privacy en geheime lekkage te voorkomen door gevoelige gebieden te maskeren voordat de logs aan kunstmatige intelligentie worden doorgegeven
Hoewel een systeem lijkt te werken, kan het van binnen afsterven: het geheugen raakt langzaam vol, de responstijden nemen toe, het foutenpercentage neemt toe. De enige manier om dit op te merken is door het systeem voortdurend te monitoren. Een geavanceerder concept is waarneembaarheid: het vermogen om te begrijpen wat er binnen het systeem gebeurt door naar de externe signalen te kijken. Er zijn drie pijlers van waarneembaarheid, en de DevOps-professional gebruikt ze alle drie:
- Metriek: numerieke waarden gemeten in de loop van de tijd: CPU-gebruik, aantal verzoeken, responstijd, foutenpercentage. "Hoe veel?" beantwoordt de vraag.
- Logboek: tekstgebeurtenisrecords geproduceerd door het systeem: "gebruiker ingelogd", "databaseverbinding verbroken". "Wat is er precies gebeurd?" beantwoordt de vraag.
- Traceren: het pad dat een verzoek volgt terwijl het van service naar service binnen het systeem gaat, en de duur van elke stap. “Waar is de traagheid?” beantwoordt de vraag.
Meest gebruikte tools: Prometheus voor statistieken, Grafana voor visualisatie, Loki/ELK voor log, Jaeger/OpenTelemetry voor trace. AI is zeer bedreven in het schrijven van de querytalen (vooral Prometheus' PromQL), alarmregels en dashboardconfiguraties voor deze tools. Het is ook waar AI op zijn sterkst is: het samenvatten van grote hoeveelheden logboeken en statistieken en het signaleren van afwijkingen.
Laten we het verschil tussen monitoring en waarneembaarheid in één zin verduidelijken: monitoring is het stellen van vragen die je al kent (“Is de CPU voorbij de 90%?”); Waarneembaarheid is het kunnen stellen van vragen die je nog niet kende ("waarom gebeurt deze rare traagheid alleen bij een bepaalde klant op een bepaald tijdstip?"). Moderne systemen zijn zo complex dat je niet alle vormen van falen kunt voorspellen; Daarom wordt de mogelijkheid om rijke statistieken, logboeken en sporen te verzamelen en deze vervolgens diepgaand te bevragen (waarneembaarheid) van cruciaal belang. Dit is waar AI een rol speelt bij het beantwoorden van de ‘voorheen onbekende vraag’: het scant snel de ruwe gegevens die je hebt, suggereert patronen en afwijkingen, en je ontdekt de hoofdoorzaak door deze aanwijzingen te verifiëren.
Stap voor stap: wat en hoe monitoren?
- Kies de juiste statistieken. In de industrie worden ‘vier gouden signalen’ als basis genomen: latentie, verkeer, fouten, verzadiging – hoe vol de bron is. Deze vatten de gezondheid van de meeste diensten samen.
- Verzamel statistieken. Laat de applicatie een eindpunt presenteren dat Prometheus kan lezen.
- Dashboards opzetten. Visualiseer deze statistieken in Grafana.
- Schrijf alarmregels. Wie wordt gewaarschuwd als een drempel wordt overschreden en hoe?
- Centraliseer logboeken. Maak alle servicelogboeken op één plek doorzoekbaar.
- Verminder lawaai. Te veel alarm veroorzaakt ‘alertmoeheid’; Het belangrijke alarm verdwijnt.
Tip: Een goed alarm voldoet aan twee dingen: het is uitvoerbaar en heeft de juiste urgentie. Een alarm dat iemand om drie uur 's nachts wakker maakt, moet iets zijn dat daadwerkelijk nachtelijk ingrijpen vereist. Maak niemand wakker voor iets dat op zichzelf geen actie vereist, zoals "CPU 70%"; laat het op het bord zien.
Hoe schrijf je een alarmregel?
Een waarschuwing bestaat uit drie componenten: voorwaarde (welke statistiek overschrijdt welke drempel en voor hoe lang), duur (‘gedurende 5 minuten’ om te voorkomen dat tijdelijke fluctuaties worden veroorzaakt) en belang/actie (voor wie, via welk kanaal). AI brengt deze drie op meesterlijke wijze in de juiste context. Het vertalen van een regel als ‘kritiek alarm als het foutenpercentage gedurende 5 minuten meer dan 5% bedraagt’ naar PromQL is bijvoorbeeld een taak van een fractie van een seconde voor de AI – maar u beslist of de drempel geschikt is voor uw systeem.
Let op: De door de AI voorgestelde alarmdrempels zijn algemene aannames. De normale belasting, tolerantie en werkimpact van uw systeem zijn anders. Voordat u een drempel rechtstreeks in Prod plaatst, kijkt u naar uw historische gegevens en vraagt u zich af: "Hoe vaak is deze drempel in het verleden geactiveerd, hoeveel daarvan waren echte problemen?" Beantwoord de vraag.
Logprivacy: kritische waarschuwing
Logboeken zijn de meest over het hoofd geziene bron van lekken. Een logregel kan per ongeluk een wachtwoord, een creditcardnummer of persoonlijke gegevens bevatten (volgens KVKK/GDPR). Bij het plakken van logs in een AI voor analyse:
- Masker gevoelige gebieden. Vervang waarden zoals token, wachtwoord, e-mail, ID-nummer door <REDACTED>.
- Geef voorbeelden, niet allemaal. In plaats van een miljoen regels zijn vaak een paar honderd representatieve regels voldoende.
- Kies een door de instelling goedgekeurd voertuig. Gebruik vooral voor productielogboeken een tool waarvan de gegevens niet naar training gaan.
Vier gouden signalen en alarmtafels
signaal
gemeten door
Voorbeeld alarmdrempel
urgentie
latentie
reactietijd
p95 > 800 ms, 5 min
hoog
verkeer
Verzoek/sec
Plotselinge stijging/daling van 300%
middelmatig
Fout
Mislukt verzoekpercentage
> 5%, 5 min
kritisch
Verzadiging
bezetting van hulpbronnen
Schijf > 85%
hoog
drie minikoffers
Geval 1: 400 logregels samengevat in 30 seconden. Er was een dienst vertraagd. De ingenieur gaf de gemaskeerde 400 logregels aan de AI en zei: "vat de terugkerende foutpatronen en tijdsintensiteit samen." AI liet zien dat bij een bepaalde externe API-oproep elke 30 seconden een time-out optreedt. Oorzaak gevonden in 30 seconden; Het handmatig scannen van logboeken zou een half uur duren.
Geval 2: alarmmoeheid opgelost. Eén team ontving 200 alarmen per dag en negeerde ze allemaal – totdat ook een echt storingsalarm over het hoofd werd gezien. Geef de AI alle waarschuwingsregels en vraag "welke zijn niet uitvoerbaar en welke kunnen worden gecombineerd?" vroegen ze. Het aantal alarmen daalde naar 12 per dag; Elk alarm werd nu serieus genomen.
Geval 3 – verkeerde drempel vroeg opgemerkt. YZ stelde "Waarschuwen wanneer 95% vol" voor de schijf voor. De ingenieur keek naar historische gegevens: zodra de schijf 95% bereikte, was er weinig tijd voor interventie. Het verlaagde de drempel tot 80% en voegde een tweede alarm toe op basis van ‘groeisnelheid’. Verificatie verhinderde een daadwerkelijke middernachtstoring.
Vier kopieerbare sjablonen
1) Logsamenvatting (gemaskeerd):
Analyseer het logvoorbeeld hieronder (ik maskeerde gevoelige waarden met <REDACTED>). Geef me: (1) terugkerende foutpatronen, (2) concentratie in de loop van de tijd, (3) meest waarschijnlijke oorzaak, en (4) 3 statistieken die ik zal bekijken om te verifiëren. Logboek: [LIJNEN]
2) Genereren van alarmregels:
Schrijf een alarmregel voor Prometheus/Alertmanager: Genereer een [SEVERITY]-alarm als [THRESHOLD] [METRIC][DURATION] overschrijdt. De regel moet actiegericht zijn en een annotatie- en runbookkoppelingsveld bevatten. Leg PromQL uit en schrijf op waarom deze drempel redelijk is.
3) PromQL-query schrijven/declareren:
Schrijf een PromQL-query die het volgende meet: [EX. 5xxfoutpercentage in de afgelopen 5 minuten]. Leg de vraag stap voor stap uit. Vertel me dan wat het gezonde bereik voor deze waarde zou moeten zijn.
4) Dashboardontwerp:
Ontwerp een Grafana-dashboard voor [SERVICE]: met welke panelen moet ik de vier gouden signalen weergeven (latentie, verkeer, fout, verzadiging)? Stel statistiek, visualisatietype en redelijke drempel voor elk paneel voor. Doel: in 10 seconden de gezondheidsstatus van een bewaker zien.
Zwakke prompt/sterke prompt
Zwak: "Wat staat er in dat logboek?" (gevolgd door 5000 regels onbewerkt logboek, tokens erin)
Resultaat: je lekt geheimen en de AI geeft een ongerichte, oppervlakkige samenvatting.
Strong: "Vind terugkerende foutpatronen en tijdsintensiteit in het gemaskeerde logvoorbeeld van 300 regels hieronder; vertel me de meest waarschijnlijke oorzaak en de statistieken die ik zal bekijken om te verifiëren. Ik heb de tokens <REDACTED> gemaakt."
Verschil: de tweede prompt geeft een gemaskeerd en gericht voorbeeld en vraagt om een duidelijke analyse-uitvoer; Het is zowel veilig als nuttig.
Veel voorkomende fouten
- Het logbestand in AI plakken zonder het te maskeren. Het meest voorkomende lek van geheime/persoonlijke gegevens.
- Alarmen instellen voor alles. Alarmvermoeidheid begraaft het echte alarm.
- Niet-bruikbaar alarm. Het is een waarschuwingsgeluid waar niemand iets aan kan doen.
- Zonder twijfel de drempel van AI accepteren. De drempelwaarde moet worden ingesteld op basis van de geschiedenis van uw systeem.
- Gewoon naar de statistiek kijken. Zonder log en trace kan de oorzaak meestal niet worden gevonden.
- Geen alarmtijd instellen (voor). Kortstondige schommelingen veroorzaken vals alarm.
Samengevat
Waarneembaarheid; Het is het vermogen om de binnenkant van het systeem van buitenaf te begrijpen met behulp van statistieken, logs en sporen. De vier gouden signalen (latency, traffic, error, saturation) vatten de gezondheid van de meeste services samen. AI is zeer krachtig in het schrijven van PromQL-query's, alarmregels en dashboards, en in het samenvatten van grote stukken logboeken en het vinden van afwijkingen. Maar het is uw verantwoordelijkheid om alarmdrempels te verifiëren aan de hand van de geschiedenis van uw eigen systeem, alarmen actiegericht te houden en nooit logboeken te delen zonder ze te maskeren.
Applicatie taak
Voor een dienst (of een voorbeelddienst): (1) Laat een alarmregel genereren voor het foutenpercentage met de sjabloon "Alarmregel genereren" en stel de voorgestelde drempel in op "Hoe vaak is deze in het verleden geactiveerd?" Test het met de vraag; (2) maskeer een logvoorbeeld dat u heeft en laat het analyseren met de sjabloon "Logboeksamenvatting"; (3) noteer naar welke maatstaf u gaat kijken om de meest waarschijnlijke hoofdoorzaak te bevestigen.
controlelijst
- [ ] Ik heb de meetgegevens gekozen die ik wil volgen op basis van vier gouden signalen.
- [ ] Ik maskeerde alle logs die ik aan de AI gaf op het gebied van gevoelige gebieden.
- [ ] Ik controleerde of elk alarm actiegericht was en de juiste urgentie had.
- [ ] Ik heb de alarmdrempels getest aan de hand van de historische gegevens van mijn systeem.
- [ ] Ik heb onmiddellijke fluctuaties gefilterd door een (duur) aan de alarmen toe te voegen.
- [ ] Ik heb metrisch + log + trace samen gebruikt als hoofdoorzaak.