SRE (Site Reliability Engineering) is een benadering om webprojecten toegankelijk te maken. Het wordt beschouwd als een raamwerk voor DevOps en vertelt hoe u kunt slagen in de toepassing van DevOps-praktijken. Dit artikel vertaalt boeken van Google. Ik heb deze vertaling zelf voorbereid en vertrouwde op mijn eigen ervaring met het begrijpen van monitoringprocessen. In het telegramkanaal и Ik plaatste ook een link naar een vertaling van Hoofdstuk 4 van hetzelfde boek over Service Level Objectives.
Vertaling door kat. Veel plezier met lezen!
De SRE-teams van Google hebben basisprincipes en best practices voor het bouwen van succesvolle monitoring- en meldingssystemen. Dit hoofdstuk geeft aanbevelingen over de problemen die een bezoeker van een webpagina kan tegenkomen en hoe problemen kunnen worden opgelost die het weergeven van webpagina's bemoeilijken.
definiëren
Er wordt niet één vocabulaire gebruikt om onderwerpen met betrekking tot monitoring te bespreken. Zelfs op Google worden de onderstaande termen niet vaak gebruikt, maar we zullen de meest voorkomende interpretaties opsommen.
controle
Verzameling, verwerking, aggregatie en weergave van realtime kwantitatieve gegevens over het systeem: aantal verzoeken en soorten verzoeken, aantal fouten en soorten fouten, verwerkingstijd van verzoeken en uptime van de server.
Whitebox-bewaking
Bewaking op basis van statistieken die worden weergegeven door interne systeemonderdelen, inclusief logboeken, JVM- of HTTP-handlerprofileringsstatistieken die interne statistieken genereren.
Blackbox-bewaking
Testen van het gedrag van de applicatie vanuit het oogpunt van de gebruiker.
Dashboard (dashboards)
Een interface (meestal een webinterface) die een overzicht geeft van de belangrijkste gezondheidsindicatoren van de services. Het dashboard kan filters hebben, de mogelijkheid om te selecteren welke statistieken moeten worden weergegeven, enz. De interface is ontworpen om de belangrijkste statistieken voor gebruikers te identificeren. Het dashboard kan ook informatie weergeven voor technisch ondersteunend personeel: een wachtrij met verzoeken, een lijst met fouten met hoge prioriteit, een toegewezen technicus voor een bepaald verantwoordelijkheidsgebied.
Alert (melding)
Meldingen die bedoeld zijn om door een persoon per e-mail of anderszins te worden ontvangen en die kunnen worden geactiveerd als gevolg van fouten of een toename van de wachtrij met verzoeken. Meldingen zijn gecategoriseerd als: tickets, e-mailwaarschuwingen en Messenger-berichten.
Grondoorzaak (grondoorzaak)
Een softwarefout of menselijke fout die, wanneer gecorrigeerd, niet meer mag voorkomen. Het probleem kan verschillende hoofdredenen hebben: onvoldoende procesautomatisering, softwaredefect, onvoldoende studie van de applicatielogica. Elk van deze factoren kan de oorzaak zijn en elk van hen moet worden geëlimineerd.
Knooppunt en machine (knooppunt en machine)
Verwisselbare termen om te verwijzen naar een enkel exemplaar van een actieve applicatie op een fysieke server, virtuele machine of container. Er kunnen meerdere services op één machine staan. Diensten kunnen zijn:
- gerelateerd aan elkaar: bijvoorbeeld een cacheserver en een webserver;
- niet-gerelateerde services op dezelfde hardware: bijvoorbeeld een coderepository en een wizard voor een configuratiesysteem, zoals of .
Duwen
Elke wijziging in de softwareconfiguratie.
Waarom toezicht nodig is
Er zijn verschillende redenen waarom toepassingen moeten worden gecontroleerd:
Analyse van langetermijntrends
Hoe groot is de database en hoe snel groeit deze? Hoe verandert het dagelijkse aantal gebruikers?
Prestatievergelijking
Zijn query's sneller op Acme Bucket of Bytes 2.72 dan Ajax DB 3.14? Hoeveel beter worden verzoeken in de cache opgeslagen na het verschijnen van een extra knooppunt? Is de site trager geworden dan vorige week?
Alarmering (meldingen)
Er is iets kapot en iemand moet het repareren. Of er gaat binnenkort iets kapot en iemand moet er snel naar kijken.
Dashboards maken
Dashboards moeten basisvragen beantwoorden en iets bevatten van - vertragingen (latency), verkeer (verkeer), fouten (fouten) en laadwaarde (verzadiging).
Uitvoeren van retrospectieve analyses (debugging)
Verzoek verwerkingslatentie toegenomen, wat gebeurde er nog meer rond dezelfde tijd?
Monitoringsystemen zijn nuttig als gegevensbron voor business intelligence-systemen en om de analyse van beveiligingsincidenten te vergemakkelijken. Omdat dit boek zich richt op technische gebieden waarin SRE's expertise hebben, zullen we monitoringtechnieken hier niet bespreken.
Met bewaking en waarschuwingen kan het systeem aangeven wanneer het kapot is of op het punt staat kapot te gaan. Wanneer een systeem zichzelf niet automatisch kan herstellen, willen we dat een mens de waarschuwing analyseert, bepaalt of het probleem nog steeds aanwezig is, het oplost en de oorzaak vaststelt. Als u systeemcomponenten niet controleert, krijgt u nooit een waarschuwing alleen maar omdat "iets een beetje vreemd lijkt".
Het laden van menselijke waarschuwingen is een vrij dure besteding van de tijd van een werknemer. Als de werknemer aan het werk is, onderbreekt de waarschuwing de workflow. Als de werknemer thuis is, onderbreekt de waarschuwing de persoonlijke tijd en mogelijk de slaap. Wanneer waarschuwingen te vaak voorkomen, skippen, vertragen of negeren werknemers binnenkomende waarschuwingen. Van tijd tot tijd negeren ze de echte waarschuwing, die wordt gemaskeerd door geluidsgebeurtenissen. Serviceonderbrekingen kunnen lang duren, omdat ruisgebeurtenissen een snelle probleemdiagnose en -oplossing verhinderen. Effectieve omroepsystemen hebben een goede signaal-ruisverhouding.
Vaststellen van redelijke verwachtingen van het monitoringsysteem
Het opzetten van monitoring voor een complexe applicatie is een complexe engineeringklus op zich. Zelfs met een aanzienlijke infrastructuur van verzamelings-, weergave- en waarschuwingstools, bestaat een Google SRE-team van 10-12 leden doorgaans uit een of twee mensen wiens hoofddoel het bouwen en onderhouden van monitoringsystemen is. Dit aantal is in de loop van de tijd afgenomen naarmate we de monitoringinfrastructuur veralgemenen en centraliseren, maar elk SRE-team heeft doorgaans ten minste één alleen-monitoring-medewerker. Het moet gezegd worden dat hoewel het heel interessant is om de dashboards van het monitoringsysteem te bekijken, SRE-teams zorgvuldig situaties vermijden waarbij iemand naar het scherm moet kijken om problemen te monitoren.
Over het algemeen is Google overgestapt op eenvoudige en snelle monitoringsystemen met optimale analysetools achteraf. We vermijden "magische" systemen die drempels proberen te voorspellen of automatisch de oorzaak ontdekken. Sensoren die onbedoelde inhoud in verzoeken van eindgebruikers detecteren, zijn het enige tegenvoorbeeld; zolang deze sensoren eenvoudig blijven, kunnen ze snel de oorzaken van ernstige afwijkingen opsporen. Andere formaten voor het gebruik van monitoringgegevens, zoals capaciteitsplanning of verkeersprognoses, zijn uitdagender. Een waarneming over een zeer lange tijd (maanden of jaren) bij een lage bemonsteringsfrequentie (uren of dagen) zal een langetermijntrend onthullen.
Het Google SRE-team heeft met wisselend succes gewerkt met complexe afhankelijkheidshiërarchieën. We gebruiken zelden regels zoals "als ik erachter kom dat de database traag is geworden, krijg ik een databasevertragingswaarschuwing, anders krijg ik een trage site-waarschuwing." Op afhankelijkheid gebaseerde regels verwijzen meestal naar de onveranderlijke delen van ons systeem, zoals het systeem voor het filteren van gebruikersverkeer naar het datacenter. Bijvoorbeeld: "Als datacentrumverkeersfiltering is geconfigureerd, waarschuw mij dan niet voor vertragingen bij het verwerken van gebruikersverzoeken" is een algemene regel voor datacentrumwaarschuwingen. Er zijn maar weinig teams bij Google die complexe afhankelijkheidshiërarchieën ondersteunen omdat onze infrastructuur een constante snelheid van continue refactoring heeft.
Sommige van de ideeën die in dit hoofdstuk zijn geschetst, gelden nog steeds: er is altijd een manier om sneller van symptoom naar oorzaak te gaan, vooral in steeds veranderende systemen. Daarom is het, hoewel dit hoofdstuk een aantal doelen schetst voor monitoringsystemen en hoe deze doelen kunnen worden bereikt, belangrijk dat monitoringsystemen eenvoudig en begrijpelijk zijn voor iedereen in het team.
Evenzo, om het geluidsniveau laag en het signaalniveau hoog te houden, moeten benaderingen voor het bewaken van objecten die worden gewaarschuwd zeer eenvoudig en betrouwbaar zijn. Regels die waarschuwingen voor mensen genereren, moeten gemakkelijk te begrijpen zijn en een duidelijk probleem vormen.
Symptomen versus oorzaken
Uw monitoringsysteem moet twee vragen beantwoorden: "wat is er kapot" en "waarom is het kapot".
"Wat brak" verwijst naar het symptoom en "waarom brak" verwijst naar de oorzaak. De onderstaande tabel toont voorbeelden van dergelijke koppelingen.
symptoom
reden
HTTP-fout 500 of 404 ontvangen
Databaseservers weigeren verbindingen
Trage serverreacties
Hoog CPU-gebruik of beschadigde ethernetkabel
Gebruikers op Antarctica krijgen geen katten-GIF's
Je CDN heeft een hekel aan wetenschappers en katachtigen, dus sommige IP's staan op de zwarte lijst
Privé-inhoud is overal beschikbaar
Door een nieuwe softwarerelease uit te rollen, vergat de firewall alle ACL's en liet iedereen binnen
"Wat" en "waarom" zijn een van de belangrijkste bouwstenen voor het creëren van een goed monitoringsysteem met maximaal signaal en minimale ruis.
Zwarte doos versus witte doos
We combineren uitgebreide white-box monitoring met bescheiden black-box monitoring voor kritische metrics. De eenvoudigste manier om Black-box met White-box te vergelijken, is dat Black-box symptoomgericht is en eerder reactief dan proactief bewaakt: "het systeem werkt momenteel niet goed." White-box is afhankelijk van de interne controlemogelijkheden van systemen: gebeurtenislogboeken of webservers. Met White-box kunt u opkomende problemen, storingen die lijken op het opnieuw verzenden van een verzoek, enz.
Merk op dat in een meerlagensysteem een symptoom op het gebied van verantwoordelijkheid van de ene ingenieur een symptoom is op het gebied van verantwoordelijkheid van een andere ingenieur. De databaseprestaties zijn bijvoorbeeld afgenomen. Trage database-lezingen zijn een symptoom van de database-SRE die ze detecteert. Voor een front-end SRE die naar een trage website kijkt, is de reden voor het lezen van dezelfde trage database echter dat de database traag is. Daarom is white-box monitoring soms gericht op symptomen en soms op oorzaken, afhankelijk van hoe uitgebreid het is.
Bij het verzamelen van telemetrie voor fout opsporing is White-Box-bewaking vereist. Als webservers traag reageren op databasequery's, moet u weten hoe snel de webserver communiceert met de database en hoe snel deze reageert. Anders kunt u het verschil niet zien tussen een trage databaseserver en een netwerkprobleem tussen de webserver en de database.
Blackbox-monitoring heeft een belangrijk voordeel bij het verzenden van waarschuwingen: u activeert een melding naar de ontvanger wanneer het probleem al daadwerkelijke symptomen heeft veroorzaakt. Aan de andere kant, voor het Black-box probleem dat zich nog niet heeft voorgedaan, maar het komende is, heeft monitoring geen zin.
Vier gouden signalen
De vier gouden monitoringsignalen zijn latentie, verkeer, fouten en verzadiging. Als u slechts vier gebruikerssysteemstatistieken kunt meten, concentreer u dan op die vier.
Vertraging
De tijd die nodig is om het verzoek te verwerken. Het is belangrijk om onderscheid te maken tussen de latentie van succesvolle en niet-succesvolle verzoeken. Een HTTP 500-fout veroorzaakt door een verbroken verbinding met een database of een andere backend kan bijvoorbeeld zeer snel worden gediagnosticeerd, maar een HTTP 500-fout kan duiden op een mislukt verzoek. Het vinden van de impact van een 500-fout op de algehele latentie kan leiden tot foutieve conclusies. Aan de andere kant is een langzame fout zelfs een snelle fout! Daarom is het belangrijk om foutlatentie bij te houden in plaats van alleen fouten eruit te filteren.
verkeer
Het aantal verzoeken aan uw systeem, gemeten in systeemstatistieken op hoog niveau. Voor een webservice vertegenwoordigt deze meting doorgaans het aantal HTTP-verzoeken per seconde gedeeld door de aard van de verzoeken (bijvoorbeeld statische of dynamische inhoud). Voor een audiostreamingsysteem kan deze meting gericht zijn op de netwerk-I/O-snelheid of het aantal gelijktijdige sessies. Voor een sleutel/waarde-opslagsysteem kan deze meting transacties of zoekopdrachten per seconde zijn.
fouten
Dit is het aantal mislukte verzoeken, hetzij expliciet (bijvoorbeeld HTTP 500), impliciet (bijvoorbeeld HTTP 200 maar gecombineerd met slechte inhoud), of door beleid (bijvoorbeeld: "Als u binnen één seconde een antwoord vastlegt, één seconde is een fout"). Als er niet genoeg HTTP-antwoordcodes zijn om alle foutcondities uit te drukken, kunnen secundaire (interne) protocollen nodig zijn om een gedeeltelijke fout te detecteren. Het monitoren van al dergelijke foutieve verzoeken kan weinig informatief zijn, terwijl end-to-end systeemtests u kunnen helpen ontdekken dat u de verkeerde inhoud verwerkt.
Verzadiging
De statistiek laat zien hoe zwaar uw service wordt gebruikt. Dit is een systeembewakingsmaatregel die bronnen identificeert die het meest beperkt zijn (bijvoorbeeld in een systeem met beperkt geheugen, toont geheugen, in een systeem met beperkte I / O, toont het aantal I / O). Merk op dat veel systemen degraderen voordat ze 100% gebruik bereiken, dus het hebben van een gebruiksdoel is essentieel.
In complexe systemen kan verzadiging worden aangevuld met belastingsmetingen op een hoger niveau: kan uw service dubbel verkeer goed verwerken, slechts 10% meer verkeer aan, of zelfs minder verkeer aan dan momenteel het geval is? Voor eenvoudige services die geen parameters hebben die de complexiteit van het verzoek wijzigen (bijv. "Geef me niets" of "Ik heb een uniek monotoon geheel getal nodig") die zelden van configuratie veranderen, kan een statische belastingstestwaarde voldoende zijn. zoals besproken in de vorige paragraaf, zouden de meeste services indirecte signalen moeten gebruiken, zoals CPU-gebruik of netwerkbandbreedte, die een bekende bovengrens hebben. Stijgende latentie is vaak de belangrijkste indicator van verzadiging. Het meten van de 99e percentiel responstijd in een klein tijdsbestek (bijvoorbeeld één minuut) kan een zeer vroeg verzadigingssignaal geven.
Ten slotte wordt verzadiging ook geassocieerd met voorspellingen van naderende verzadiging, zoals: "Het lijkt erop dat uw database uw harde schijf binnen 4 uur zal vullen."
Als je alle vier de gouden signalen meet en als er een probleem is met een van de metrics (of, in het geval van verzadiging, bijna een probleem), breng je de persoon op de hoogte, dan valt je service min of meer onder monitoring.
Zorgen over de staart (of instrumentatie en uitvoering)
Bij het vanaf nul opbouwen van een monitoringsysteem is het verleidelijk om een systeem te ontwikkelen op basis van gemiddelden: gemiddelde latentie, gemiddeld CPU-gebruik van knooppunten of gemiddelde databasebezetting. Het gevaar van de laatste twee voorbeelden ligt voor de hand: processors en databases worden op een zeer onvoorspelbare manier verwijderd. Hetzelfde geldt voor vertraging. Als u een webservice uitvoert met een gemiddelde latentie van 100 ms bij 1000 verzoeken per seconde, kan 1% van de verzoeken 5 seconden duren. Als gebruikers afhankelijk zijn van meerdere van dergelijke webservices, kan het 99e percentiel van een enkele backend gemakkelijk de mediane responstijd van de interface worden.
De eenvoudigste manier om onderscheid te maken tussen een langzame gemiddelde en een zeer langzame staart van verzoeken is metingen te verzamelen van verzoeken uitgedrukt in statistieken (histogrammen zijn een geschikt hulpmiddel om weer te geven) in plaats van daadwerkelijke vertragingen: hoeveel verzoeken werden afgehandeld door de dienst die tussen 0 ms en 10 ms, tussen 10 ms en 30 ms, tussen 30 ms en 100 ms, tussen 100 ms en 300 ms, enz. Het ongeveer exponentieel uitbreiden van de histogramgrenzen (met een factor van ongeveer 3) is vaak een gemakkelijke manier om de verdeling van verzoeken te visualiseren.
De juiste granulariteit kiezen voor metingen
Verschillende elementen van het systeem moeten met verschillende detailniveaus worden gemeten. Bijvoorbeeld:
- Het bekijken van het CPU-gebruik gedurende een bepaalde periode zal geen lange pieken laten zien die resulteren in hoge latenties.
- Aan de andere kant, voor een webservice die zich richt op niet meer dan 9 uur downtime per jaar (99,9% jaarlijkse uptime), zou het waarschijnlijk onnodig frequent zijn om meer dan een of twee keer per minuut te controleren op een HTTP 200-respons.
- Evenzo is het waarschijnlijk niet nodig om meer dan eens per 99,9-1 minuten te controleren op vrije ruimte op de harde schijf voor 2% beschikbaarheid.
Let goed op hoe u de granulariteit van de dimensies structureert. Een CPU-gebruikssnelheid van 1 per seconde kan interessante gegevens opleveren, maar dergelijke frequente metingen kunnen erg duur zijn om te verzamelen, op te slaan en te analyseren. Als uw bewakingsdoel een hoge granulariteit vereist en geen hoge reactiesnelheid vereist, kunt u deze kosten verlagen door het verzamelen van statistieken op de server in te stellen en vervolgens een extern systeem te configureren om die statistieken te verzamelen en samen te voegen. Kan je:
- Meet CPU-gebruik elke seconde.
- Verklein details tot 5%.
- Verzamel statistieken elke minuut.
Met deze strategie kunt u zeer gedetailleerde gegevens verzamelen zonder hoge overheadkosten voor analyse en opslag.
Zo simpel mogelijk, maar niet makkelijker
Het op elkaar stapelen van verschillende eisen kan leiden tot een zeer complex monitoringsysteem. Uw systeem kan bijvoorbeeld de volgende complicerende elementen hebben:
- Waarschuwingen volgens verschillende drempels voor aanvraaglatentie, in verschillende percentielen, voor allerlei verschillende statistieken.
- Schrijven van aanvullende code om mogelijke oorzaken op te sporen en te identificeren.
- Creëer gerelateerde dashboards voor elk van de mogelijke oorzaken van problemen.
De bronnen van mogelijke complicaties houden nooit op. Zoals alle softwaresystemen kan monitoring zo complex worden dat het kwetsbaar wordt, moeilijk te veranderen en te onderhouden.
Ontwerp uw monitoringsysteem daarom zo eenvoudig mogelijk. Houd rekening met het volgende wanneer u kiest wat u wilt bijhouden:
- De regels die het vaakst echte incidenten opvangen, moeten zo eenvoudig, voorspelbaar en betrouwbaar mogelijk zijn.
- De configuratie voor gegevensverzameling, aggregatie en waarschuwingen die zelden wordt uitgevoerd (bijvoorbeeld minder dan elk kwartaal voor sommige SRE-teams) moet worden verwijderd.
- Statistieken die worden verzameld maar niet worden weergegeven in een voorbeeldvenster of worden gebruikt door een waarschuwing, komen in aanmerking voor verwijdering.
Bij Google werkt de basisverzameling en aggregatie van statistieken, gecombineerd met waarschuwingen en dashboards, goed als een relatief op zichzelf staand systeem (het monitoringsysteem van Google is in feite opgedeeld in verschillende subsystemen, maar meestal zijn mensen op de hoogte van alle aspecten van deze subsystemen). Het kan verleidelijk zijn om monitoring te combineren met andere methoden voor het testen van complexe systemen: gedetailleerde systeemprofilering, procesfoutopsporing, tracking van uitzonderingen of foutdetails, belastingtesten, logboekverzameling en -analyse of verkeersinspectie. Hoewel de meeste van deze dingen overeenkomsten vertonen met basismonitoring, zal het door elkaar halen ervan te veel resultaten opleveren en een complex en broos systeem creëren. Zoals met veel andere aspecten van softwareontwikkeling, is het ondersteunen van verschillende systemen met duidelijke, eenvoudige, losjes gekoppelde integratiepunten de beste strategie (bijvoorbeeld het gebruik van een web-API om samenvattende gegevens op te halen in een indeling die gedurende een lange periode constant kan blijven). ).
Principes aan elkaar koppelen
De principes die in dit hoofdstuk worden besproken, kunnen worden gecombineerd tot een monitoring- en waarschuwingsfilosofie die wordt onderschreven en gevolgd door de SRE-teams van Google. Het is wenselijk om vast te houden aan deze monitoringfilosofie, het is een goed startpunt voor het creëren of herzien van een waarschuwingsmethodiek en kan u helpen de juiste vragen te stellen aan de bedrijfsvoering, ongeacht de grootte van uw organisatie of de complexiteit van de service of het systeem.
Bij het maken van controle- en waarschuwingsregels kan het stellen van de volgende vragen u helpen valse positieven en onnodige waarschuwingen te voorkomen:
- Detecteert deze regel een anderszins niet-detecteerbare systeemstatus die urgent is, oproepen tot actie en onvermijdelijk gevolgen heeft voor de gebruiker?
- Kan ik deze waarschuwing negeren, wetende dat het goedaardig is? Wanneer en waarom kan ik deze waarschuwing negeren en hoe kan ik dit scenario vermijden?
- Betekent deze waarschuwing dat gebruikers nadelig worden beïnvloed? Zijn er situaties waarin gebruikers geen negatieve gevolgen ondervinden, bijvoorbeeld door verkeersfiltering of bij het gebruik van testsystemen, waarop waarschuwingen moeten worden gefilterd?
- Kan ik actie ondernemen naar aanleiding van deze waarschuwing? Zijn deze maatregelen dringend of kunnen ze wachten tot de ochtend? Is het veilig om de actie te automatiseren? Zal deze actie een oplossing op lange termijn zijn of een tijdelijke oplossing?
- Sommige mensen krijgen meerdere waarschuwingen voor dit probleem, dus is het mogelijk om het aantal te verminderen?
Deze vragen weerspiegelen de fundamentele filosofie over waarschuwingen en waarschuwingssystemen:
- Elke keer als er een melding binnenkomt, moet ik met spoed reageren. Ik kan me meerdere keren per dag haasten voordat ik moe word.
- Elke melding moet up-to-date zijn.
- Elke reactie op een waarschuwing vereist menselijke tussenkomst. Als de melding automatisch kan worden verwerkt, mag deze niet komen.
- Waarschuwingen moeten gaan over een nieuw probleem of een gebeurtenis die nog niet eerder heeft plaatsgevonden.
Deze aanpak vervaagt bepaalde verschillen: als een waarschuwing aan de voorgaande vier voorwaarden voldoet, maakt het niet uit of de waarschuwing wordt verzonden vanuit een White-box monitoringsysteem of een Black-Box. Deze benadering versterkt ook enkele verschillen: men kan beter veel meer moeite doen om symptomen te identificeren dan aan oorzaken; als het om oorzaken gaat, hoeft u zich alleen zorgen te maken over de onvermijdelijke oorzaken.
Monitoring op lange termijn
In de huidige productieomgevingen bewaken bewakingssystemen een steeds evoluerend productiesysteem met veranderende softwarearchitectuur, belastingskenmerken en prestatiedoelen. Alerts, die momenteel moeilijk te automatiseren zijn, zouden wel eens gemeengoed kunnen worden en misschien zelfs het verdienen om aangepakt te worden. Op dit punt moet iemand de hoofdoorzaken van het probleem vinden en oplossen; als een dergelijke oplossing niet mogelijk is, vereist de reactie op de waarschuwing volledige automatisering.
Het is belangrijk dat monitoringbeslissingen worden genomen met langetermijndoelen in het achterhoofd. Elke waarschuwing die vandaag wordt uitgevoerd, zorgt ervoor dat iemand het systeem morgen niet kan verbeteren, dus er is vaak een afname in de beschikbaarheid of prestatie van een productief systeem voor de tijd die nodig is om het monitoringsysteem op de lange termijn te verbeteren. Laten we eens kijken naar twee voorbeelden die dit fenomeen illustreren.
Bigtable SRE: Een verhaal over over-alert
De interne infrastructuur van Google wordt meestal geleverd en gemeten in termen van Service Level (SLO). Jaren geleden was de SLO van de Bigtable-service gebaseerd op de gemiddelde prestatie van een synthetische transactie die een lopende client simuleert. Vanwege problemen in Bigtable en lagere niveaus van de opslagstack, werden de gemiddelde prestaties aangedreven door een "grote" staart: de slechtste 5% van de zoekopdrachten was vaak aanzienlijk langzamer dan de rest.
Er werden e-mailmeldingen verzonden toen de SLO-drempel werd bereikt en er werden Messenger-waarschuwingen verzonden wanneer de SLO werd overschreden. Beide soorten waarschuwingen werden vrij vaak verzonden, wat onaanvaardbare hoeveelheden engineeringtijd in beslag nam: het team besteedde veel tijd aan het analyseren van de waarschuwingen om er een paar te vinden die echt relevant waren. We misten vaak een probleem dat gebruikers daadwerkelijk trof, omdat slechts enkele waarschuwingen voor dat specifieke probleem waren. Veel van de meldingen waren niet-urgent vanwege begrijpelijke infrastructuurproblemen en werden op een standaardmanier of helemaal niet afgehandeld.
Om de situatie te verhelpen, gebruikte het team een drieledige aanpak: terwijl we hard werkten om de prestaties van Bigtable te verbeteren, stelden we tijdelijk het 75e percentiel voor vertraging in het beantwoorden van vragen in als ons SLO-doel. We hebben ook e-mailwaarschuwingen uitgeschakeld, omdat er zo veel waren dat het onmogelijk was om tijd te verspillen aan het diagnosticeren ervan.
Deze strategie gaf ons een adempauze om te beginnen met het oplossen van langetermijnproblemen in Bigtable en de lagere lagen van de storagestack, in plaats van constant tactische problemen op te lossen. Ingenieurs zouden de klus echt kunnen klaren als ze niet de hele tijd met waarschuwingen werden gebombardeerd. Uiteindelijk heeft de tijdelijke vertraging bij het verwerken van waarschuwingen ons in staat gesteld de kwaliteit van de dienstverlening te verbeteren.
Gmail: voorspelbare, algoritmische menselijke reacties
Helemaal aan het begin was Gmail gebouwd op een aangepast Workqueue-procesbeheersysteem dat was gemaakt om zoekindexbrokken batchgewijs te verwerken. Workqueue werd aangepast aan langdurige processen en vervolgens toegepast op Gmail, maar sommige bugs in de ondoorzichtige scheduler-code bleken erg moeilijk te repareren.
Destijds was Gmail-monitoring zo gestructureerd dat waarschuwingen werden geactiveerd wanneer individuele taken werden geannuleerd met Workqueue. Deze aanpak was niet ideaal, omdat zelfs in die tijd Gmail vele duizenden taken uitvoerde, die elk aan fracties van een procent van onze gebruikers werden gegeven. We hebben er alles aan gedaan om ervoor te zorgen dat Gmail-gebruikers een goede gebruikerservaring hebben, maar het afhandelen van zoveel waarschuwingen was uitgesloten.
Om dit probleem op te lossen, heeft Gmail SRE een tool gemaakt om de planner zo goed mogelijk te debuggen om de impact op gebruikers te minimaliseren. Het team heeft verschillende discussies gevoerd over het al dan niet automatiseren van de hele cyclus van het vinden van het probleem tot het oplossen ervan totdat er een langetermijnoplossing is gevonden, maar sommigen waren bezorgd dat een dergelijke oplossing de daadwerkelijke oplossing van het probleem zou vertragen.
Dergelijke spanningen waren gebruikelijk binnen het team en weerspiegelden vaak een wantrouwen in zelfdiscipline: terwijl sommige teamleden tijd willen besteden aan een goede oplossing, maken anderen zich zorgen dat de definitieve oplossing zal worden vergeten en dat de tijdelijke oplossing eeuwig zal duren. Dit probleem verdient aandacht, omdat het te gemakkelijk is om problemen tijdelijk op te lossen in plaats van een permanente oplossing te bieden. Managers en technisch personeel spelen een sleutelrol bij de implementatie van langetermijnoplossingen door mogelijke langetermijnoplossingen voor de lange termijn te ondersteunen en prioriteit te geven, zelfs wanneer de aanvankelijke pijn afneemt.
Regelmatig terugkerende waarschuwingen en algoritmische reacties zouden een rode vlag moeten zijn. De onwil van uw team om deze waarschuwingen te automatiseren, betekent dat het team er niet op vertrouwt dat ze de algoritmen kunnen vertrouwen. Dit is een serieus probleem dat moet worden aangepakt.
Langetermijn
Een gemeenschappelijk thema verbindt de Bigtable- en Gmail-voorbeelden: de concurrentie tussen beschikbaarheid op korte en lange termijn. Vaak kan een grote inspanning een kwetsbaar systeem helpen een hoge beschikbaarheid te bereiken, maar dit pad is meestal van korte duur, beladen met burn-out van het team en afhankelijkheid van een klein aantal leden van hetzelfde heroïsche team.
Een gecontroleerde afname van de beschikbaarheid op korte termijn is vaak pijnlijk, maar strategisch belangrijk voor de stabiliteit van het systeem op de lange termijn. Het is belangrijk om niet elke melding afzonderlijk te bekijken, maar na te gaan of het totale aantal meldingen leidt tot een gezond, goed toegankelijk systeem met een levensvatbaar team en een gunstige prognose. We analyseren waarschuwingsstatistieken (meestal uitgedrukt als incidenten per ploeg, waarbij een incident uit meerdere gerelateerde incidenten kan bestaan) in driemaandelijkse rapporten met het management, waardoor besluitvormers continu de belasting van het waarschuwingssysteem en de algehele gezondheid van het team kunnen presenteren.
Conclusie
De weg naar gezonde monitoring en waarschuwingen is eenvoudig en ongecompliceerd. Het richt zich op de symptomen van het probleem waarvoor waarschuwingen worden gegenereerd, en het monitoren van de oorzaak dient als hulpmiddel bij het opsporen van problemen. Symptoombewaking is gemakkelijker naarmate u hoger in de stapel zit die u beheert, hoewel het laden van de database en het bewaken van de prestaties rechtstreeks op de database zelf moeten worden gedaan. E-mailmeldingen zijn van zeer beperkt nut en hebben de neiging gemakkelijk te escaleren tot ruis; in plaats daarvan moet u een dashboard gebruiken dat alle actuele problemen bewaakt die per e-mail worden gemeld. Het dashboard kan ook worden gekoppeld aan een gebeurtenislogboek om historische correlaties te analyseren.
Op de lange termijn moet een succesvolle afwisseling worden bereikt tussen symptoomwaarschuwingen en dreigende echte problemen, en moeten doelen worden aangepast om ervoor te zorgen dat monitoring een snelle diagnose ondersteunt.
Bedankt voor het lezen van de vertaling tot het einde. Abonneer je op mijn telegramkanaal over monitoring и .
Bron: www.habr.com