Is monitoring dood? — Lang leve het toezicht

Sinds 2008 houdt ons bedrijf zich voornamelijk bezig met infrastructuurbeheer en 400-uurs technische ondersteuning voor webprojecten: we hebben meer dan 15 klanten, wat ongeveer 15% van de Russische e-commerce is. Dienovereenkomstig wordt een zeer diverse architectuur ondersteund. Mocht er iets vallen, dan zijn wij verplicht dit binnen XNUMX minuten te repareren. Maar om te begrijpen dat er een ongeval heeft plaatsgevonden, moet u het project monitoren en op incidenten reageren. Hoe doe je dit?

Ik ben van mening dat er een probleem is bij het organiseren van een goed monitoringsysteem. Als er geen problemen waren geweest, zou mijn toespraak uit één stelling bestaan: “Installeer alstublieft Prometheus + Grafana en plug-ins 1, 2, 3.” Helaas werkt het niet meer zo. En het grootste probleem is dat iedereen blijft geloven in iets dat in 2008 bestond, in termen van softwarecomponenten.

Wat de organisatie van het monitoringsysteem betreft, durf ik te zeggen dat... projecten met competente monitoring niet bestaan. En de situatie is zo slecht dat als er iets valt, het risico bestaat dat het onopgemerkt blijft - iedereen is er immers zeker van dat “alles wordt gecontroleerd.”
Misschien wordt alles in de gaten gehouden. Maar hoe?

We zijn allemaal een verhaal als het volgende tegengekomen: een bepaalde devops, een bepaalde beheerder is aan het werk, een ontwikkelingsteam komt naar hen toe en zegt: "we zijn vrijgelaten, nu monitoren." Wat monitoren? Hoe het werkt?

OK. Wij monitoren op de ouderwetse manier. En het is al aan het veranderen, en het blijkt dat je service A hebt gemonitord, die service B is geworden, die samenwerkt met service C. Maar het ontwikkelingsteam vertelt je: "Installeer de software, deze zou alles moeten monitoren!"

Dus wat is er veranderd? - Alles is veranderd!

2008 Alles is in orde

Er zijn een paar ontwikkelaars, één server, één databaseserver. Het gaat allemaal vanaf hier. We hebben wat informatie, we installeren zabbix, Nagios, cactussen. En vervolgens hebben we duidelijke waarschuwingen ingesteld voor de CPU, voor de werking van de schijf en voor de schijfruimte. We voeren ook een aantal handmatige controles uit om ervoor te zorgen dat de site reageert en dat bestellingen in de database aankomen. En dat is het: we zijn min of meer beschermd.

Als we de hoeveelheid werk vergelijken die de beheerder destijds deed om monitoring te verzorgen, dan was 98% daarvan automatisch: de persoon die de monitoring doet, moet begrijpen hoe Zabbix moet worden geïnstalleerd, hoe hij het moet configureren en hoe hij waarschuwingen kan configureren. En 2% - voor externe controles: dat de site reageert en een verzoek indient bij de database, dat er nieuwe bestellingen zijn binnengekomen.

2010 De last groeit

We beginnen het internet te schalen door een zoekmachine toe te voegen. We willen ervoor zorgen dat de productcatalogus alle producten bevat. En dat zoeken naar producten werkt. Dat de database werkt, dat er bestellingen worden gedaan, dat de site extern reageert en reageert vanaf twee servers en dat de gebruiker niet uit de site wordt gezet terwijl deze opnieuw wordt gebalanceerd naar een andere server, etc. Er zijn meer entiteiten.

Bovendien blijft de entiteit geassocieerd met infrastructuur nog steeds de grootste in het hoofd van de manager. Er zit nog steeds een idee in mijn hoofd dat de persoon die de monitoring uitvoert, de persoon is die zabbix zal installeren en kan configureren.

Maar tegelijkertijd wordt er gewerkt aan het uitvoeren van externe controles, aan het creëren van een set scripts voor zoekindexeringsquery's, een set scripts om te controleren of de zoekopdracht verandert tijdens het indexeringsproces, een set scripts die controleren of goederen worden overgedragen aan de bezorgservice, enz. enzovoort.

Opmerking: ik heb “een set scripts” 3 keer geschreven. Dat wil zeggen dat de persoon die verantwoordelijk is voor de monitoring niet langer degene is die eenvoudigweg zabbix installeert. Dit is een persoon die begint met coderen. Maar er is nog niets veranderd in de hoofden van het team.

Maar de wereld verandert en wordt steeds complexer. Er wordt een virtualisatielaag toegevoegd en er worden verschillende nieuwe systemen toegevoegd. Ze beginnen met elkaar te communiceren. Wie zei "ruikt naar microservices?" Maar elke dienst ziet er nog steeds afzonderlijk uit als een website. We kunnen er gebruik van maken en begrijpen dat het de nodige informatie verschaft en op zichzelf werkt. En als je als beheerder voortdurend betrokken bent bij een project dat al 5-7-10 jaar in ontwikkeling is, stapelt deze kennis zich op: er verschijnt een nieuw niveau - je realiseerde het je, een ander niveau verschijnt - je realiseerde het...

Maar zelden begeleidt iemand een project tien jaar lang.

CV van Monitoringman

Stel dat je bij een nieuwe startup komt die onmiddellijk twintig ontwikkelaars inhuurt, vijftien microservices schrijft, en je bent een beheerder die te horen krijgt: “Build CI/CD. Alsjeblieft." Je hebt CI/CD gebouwd en ineens hoor je: “Het is voor ons lastig om met productie in een ‘kubus’ te werken, zonder te begrijpen hoe de applicatie daarin gaat werken. Maak van ons een zandbak in dezelfde “kubus”.
In deze kubus maak je een zandbak. Ze vertellen je meteen: “We willen een podiumdatabase die elke dag vanaf de productie wordt bijgewerkt, zodat we begrijpen dat deze op de database werkt, maar tegelijkertijd de productiedatabase niet bederft.”

Jij leeft in dit alles. Er zijn nog 2 weken voor de release, ze vertellen je: "Laten we dit nu allemaal in de gaten houden..." Dat wil zeggen. monitor de clusterinfrastructuur, monitor de microservice-architectuur, monitor het werk met externe services...

En mijn collega's halen het gebruikelijke schema uit hun hoofd en zeggen: “Nou, alles is hier duidelijk! Installeer een programma dat dit allemaal monitort.” Ja, ja: Prometheus + Grafana + plug-ins.
En ze voegen eraan toe: “Je hebt twee weken, zorg ervoor dat alles veilig is.”

Bij veel projecten die we zien, wordt één persoon toegewezen voor monitoring. Stel je voor dat we iemand willen inhuren om gedurende 2 weken monitoring te doen, en we schrijven een CV voor hem. Welke vaardigheden moet deze persoon hebben, gezien alles wat we tot nu toe hebben gezegd?

• Hij moet de monitoring en details van de werking van de ijzeren infrastructuur begrijpen.
• Hij moet de details van het monitoren van Kubernetes begrijpen (en iedereen wil naar de "kubus", omdat je van alles kunt abstraheren, verbergen, omdat de beheerder de rest afhandelt) - zichzelf, de infrastructuur ervan, en begrijpen hoe applicaties moeten worden gemonitord binnen.
• Hij moet begrijpen dat diensten op speciale manieren met elkaar communiceren, en de specifieke kenmerken kennen van hoe diensten met elkaar omgaan. Het is heel goed mogelijk om een ​​project te zien waarbij sommige diensten synchroon communiceren, omdat er geen andere manier is. De backend gaat bijvoorbeeld via REST, via gRPC naar de catalogusdienst, ontvangt een lijst met producten en stuurt deze terug. Je kunt hier niet wachten. En bij andere diensten werkt het asynchroon. Geef de bestelling door aan de bezorgdienst, stuur een brief etc.
  Je hebt waarschijnlijk al gezwommen van dit alles? En de beheerder, die dit moet monitoren, raakte nog meer in de war.
• Hij moet kunnen plannen en correct plannen - naarmate het werk steeds meer wordt.
• Hij moet daarom een ​​strategie creëren op basis van de gecreëerde dienst om te begrijpen hoe hij deze specifiek kan monitoren. Hij heeft inzicht nodig in de architectuur van het project en de ontwikkeling ervan + inzicht in de technologieën die bij de ontwikkeling worden gebruikt.

Laten we een volkomen normaal geval onthouden: sommige services zijn in PHP, sommige services zijn in Go, sommige services zijn in JS. Ze werken op de een of andere manier met elkaar samen. Dit is waar de term ‘microservice’ vandaan komt: er zijn zoveel individuele systemen dat ontwikkelaars het project als geheel niet kunnen begrijpen. Een deel van het team schrijft services in JS die op zichzelf werken en niet weten hoe de rest van het systeem werkt. Het andere deel schrijft services in Python en bemoeit zich niet met de manier waarop andere services werken; ze zijn geïsoleerd in hun eigen gebied. De derde is het schrijven van services in PHP of iets anders.
Al deze 20 mensen zijn onderverdeeld in 15 diensten, en er is maar één beheerder die dit allemaal moet begrijpen. Stop! we hebben het systeem zojuist opgesplitst in 15 microservices omdat 20 mensen het hele systeem niet kunnen begrijpen.

Maar het moet op de een of andere manier gecontroleerd worden...

Wat is het resultaat? Het resultaat is dat er één persoon is die alles bedenkt wat het hele team van ontwikkelaars niet kan begrijpen, en tegelijkertijd moet hij ook weten en kunnen doen wat we hierboven hebben aangegeven: hardware-infrastructuur, Kubernetes-infrastructuur, enz.

Wat kan ik zeggen... Houston, we hebben problemen.

Het monitoren van een modern softwareproject is een softwareproject op zich

Vanuit de valse overtuiging dat monitoring software is, ontwikkelen we een geloof in wonderen. Maar wonderen gebeuren helaas niet. Je kunt zabbix niet installeren en verwachten dat alles werkt. Het heeft geen zin om Grafana te installeren en te hopen dat alles goed komt. Het grootste deel van de tijd zal worden besteed aan het organiseren van controles op de werking van diensten en hun interactie met elkaar, waarbij wordt gecontroleerd hoe externe systemen werken. In feite zal 90% van de tijd niet worden besteed aan het schrijven van scripts, maar aan het ontwikkelen van software. En het moet worden afgehandeld door een team dat de werkzaamheden van het project begrijpt.
Als in deze situatie één persoon in de gaten wordt gehouden, zal er een ramp gebeuren. Dat is wat overal gebeurt.

Zo zijn er meerdere diensten die via Kafka met elkaar communiceren. De bestelling is aangekomen, we hebben een bericht over de bestelling naar Kafka gestuurd. Er is een dienst die luistert naar informatie over de bestelling en de goederen verzendt. Er is een dienst die naar informatie over de bestelling luistert en een brief naar de gebruiker stuurt. En dan verschijnen er nog een heleboel diensten, en we raken in de war.

En als je dit ook aan de beheerder en ontwikkelaars geeft in de fase dat er nog een korte tijd over is voor de release, zal die persoon dit hele protocol moeten begrijpen. Die. Een project van deze omvang vergt een aanzienlijke hoeveelheid tijd, en hiermee moet rekening worden gehouden bij de systeemontwikkeling.
Maar heel vaak, vooral bij startups, zien we hoe monitoring wordt uitgesteld tot later. “Nu gaan we een Proof of Concept maken, we gaan ermee lanceren, laten vallen – we zijn bereid om offers te brengen. En dan gaan we het allemaal monitoren.” Wanneer (of als) het project geld begint op te leveren, wil het bedrijf nog meer functies toevoegen - omdat het begint te werken, dus het moet verder worden uitgerold! En je bent op het punt waarop je eerst alles moet monitoren, wat niet 1% van de tijd kost, maar veel meer. En trouwens, er zullen ontwikkelaars nodig zijn voor monitoring, en het is gemakkelijker om ze aan nieuwe functies te laten werken. Het resultaat is dat er nieuwe features worden geschreven, alles in de war raakt en je in een eindeloze impasse zit.

Dus hoe monitor je een project vanaf het begin, en wat moet je doen als je een project krijgt dat gemonitord moet worden, maar je weet niet waar je moet beginnen?

Eerst moet je plannen.

Lyrische uitweiding: heel vaak beginnen ze met het monitoren van de infrastructuur. We hebben bijvoorbeeld Kubernetes. Laten we beginnen met het installeren van Prometheus met Grafana, door plug-ins te installeren voor het monitoren van de "kubus". Niet alleen ontwikkelaars, maar ook beheerders hebben de ongelukkige praktijk van: “We zullen deze plug-in installeren, maar de plug-in weet waarschijnlijk wel hoe het moet.” Mensen beginnen graag met het simpele en ongecompliceerde, in plaats van met de belangrijke acties. En het monitoren van de infrastructuur is eenvoudig.

Bepaal eerst wat en hoe je wilt monitoren en selecteer vervolgens een tool, want andere mensen kunnen niet voor je denken. En moeten ze? Andere mensen dachten bij zichzelf aan een universeel systeem - of dachten helemaal niet na toen deze plug-in werd geschreven. En het feit dat deze plug-in vijfduizend gebruikers heeft, betekent niet dat deze van enig nut is. Misschien word jij wel de 5ste, simpelweg omdat er voorheen al 5001 mensen aanwezig waren.

Als u de infrastructuur gaat monitoren en de backend van uw applicatie reageert niet meer, verliezen alle gebruikers de verbinding met de mobiele applicatie. Er verschijnt een fout. Ze komen naar je toe en zeggen: "De applicatie werkt niet, wat doe je hier?" - “Wij houden toezicht.” — “Hoe controleer je of je niet ziet dat de applicatie niet werkt?!”

1. Ik ben van mening dat je precies vanaf het toegangspunt van de gebruiker moet beginnen met monitoren. Als de gebruiker niet ziet dat de applicatie werkt, is dat het, het is een mislukking. En het monitoringsysteem zou hier als eerste voor moeten waarschuwen.
2. En alleen dan kunnen we de infrastructuur monitoren. Of doe het parallel. Het is gemakkelijker met infrastructuur - hier kunnen we eindelijk gewoon zabbix installeren.
3. En nu moet je naar de wortels van de applicatie gaan om te begrijpen waar dingen niet werken.

Mijn hoofdidee is dat monitoring parallel moet lopen met het ontwikkelingsproces. Als u het monitoringteam afleidt voor andere taken (CI/CD creëren, sandboxen, reorganisatie van de infrastructuur), zal de monitoring achterblijven en zult u de ontwikkeling wellicht nooit meer kunnen inhalen (of vroeg of laat zult u deze moeten stoppen).

Alles per niveau

Dit is hoe ik de organisatie van een monitoringsysteem zie.

1) Toepassingsniveau:

• monitoring van de bedrijfslogica van applicaties;
• het monitoren van gezondheidsstatistieken van diensten;
• integratiemonitoring.

2) Infrastructuurniveau:

• monitoring op orkestratieniveau;
• monitoring van systeemsoftware;
• bewaking van het ijzerniveau.

3) Opnieuw het toepassingsniveau - maar als technisch product:

• het verzamelen en monitoren van applicatielogboeken;
• APM;
• traceren.

4) Alarmering:

• organisatie van een waarschuwingssysteem;
• organisatie van een plichtsysteem;
• organisatie van een “kennisbank” en workflow voor incidentverwerking.

Het is belangrijk: we krijgen de waarschuwing niet achteraf, maar meteen! Het is niet nodig om monitoring te starten en “op de een of andere manier later” uit te zoeken wie waarschuwingen zal ontvangen. Wat is immers de taak van monitoren: begrijpen waar in het systeem iets niet goed werkt, en dat aan de juiste mensen doorgeven. Als je dit tot het einde laat, zullen de juiste mensen alleen weten dat er iets misgaat door te roepen: “Niets werkt voor ons.”

Applicatielaag - Bedrijfslogica-monitoring

Hier hebben we het over het controleren van het feit dat de applicatie voor de gebruiker werkt.

Dit niveau moet tijdens de ontwikkelingsfase worden uitgevoerd. We hebben bijvoorbeeld een voorwaardelijke Prometheus: deze gaat naar de server die de controles uitvoert, haalt het eindpunt op en het eindpunt gaat de API controleren.

Wanneer programmeurs vaak worden gevraagd om de startpagina te monitoren om er zeker van te zijn dat de site werkt, geven programmeurs een handvat waar ze elke keer aan kunnen trekken om er zeker van te zijn dat de API werkt. En programmeurs gebruiken en schrijven op dit moment nog steeds /api/test/helloworld
De enige manier om ervoor te zorgen dat alles werkt? - Nee!

• Het creëren van dergelijke controles is in wezen de taak van ontwikkelaars. Unit-tests moeten worden geschreven door de programmeurs die de code schrijven. Want als je het naar de beheerder lekt: “Kerel, hier is een lijst met API-protocollen voor alle 25 functies, houd alles in de gaten!” - niets zal lukken.
• Als je ‘Hallo wereld’ afdrukt, zal niemand ooit weten dat de API zou moeten en zal werken. Elke API-wijziging moet leiden tot een wijziging in de controles.
• Als je al zo'n probleem hebt, stop dan met de functies en wijs ontwikkelaars toe die deze cheques zullen uitschrijven, of accepteer de verliezen, accepteer dat niets wordt gecontroleerd en zal mislukken.

Technische tips:

• Zorg ervoor dat u een externe server organiseert om controles te organiseren - u moet er zeker van zijn dat uw project toegankelijk is voor de buitenwereld.
• Organiseer controles voor het gehele API-protocol, niet alleen voor individuele eindpunten.
• Maak een prometheus-eindpunt met de testresultaten.

Applicatielaag - monitoring van gezondheidsstatistieken

Nu hebben we het over externe gezondheidsstatistieken van diensten.

We hebben besloten dat we alle ‘handvatten’ van de applicatie gaan monitoren met behulp van externe controles, die we oproepen vanuit een extern monitoringsysteem. Maar dit zijn de ‘handvatten’ die de gebruiker ‘ziet’. Wij willen er zeker van zijn dat onze diensten zelf werken. Er is hier een beter verhaal: K8s heeft gezondheidscontroles, zodat in ieder geval de ‘kubus’ zelf ervan overtuigd kan worden dat de service werkt. Maar de helft van de cheques die ik heb gezien, hebben dezelfde opdruk “Hallo wereld”. Die. Dus hij trekt een keer na de inzet, hij antwoordde dat alles in orde is - dat is alles. En de dienst, als deze een eigen API levert, heeft een enorm aantal toegangspunten voor diezelfde API, die ook gemonitord moet worden, omdat we willen weten of deze werkt. En we houden het binnen al in de gaten.

Hoe dit technisch correct te implementeren: elke service geeft een eindpunt weer over de huidige prestaties, en in de grafieken van Grafana (of een andere applicatie) zien we de status van alle services.

• Elke API-wijziging moet leiden tot een wijziging in de controles.
• Creëer meteen een nieuwe service met gezondheidsstatistieken.
• Een beheerder kan naar de ontwikkelaars komen en vragen: “Voeg mij een paar functies toe zodat ik alles begrijp en voeg informatie hierover toe aan mijn monitoringsysteem.” Maar ontwikkelaars antwoorden meestal: “Twee weken voor de release voegen we niets toe.”
  Laat de ontwikkelingsmanagers weten dat er zulke verliezen zullen zijn, laat het management van de ontwikkelingsmanagers dat ook weten. Want als alles mislukt, zal er nog steeds iemand bellen en eisen om toezicht te houden op de “constant dalende dienst” (c)
• Wijs ontwikkelaars trouwens toe om plug-ins voor Grafana te schrijven - dit zal een goede hulp zijn voor beheerders.

Applicatielaag - Integratiebewaking

Integratiemonitoring richt zich op het monitoren van de communicatie tussen bedrijfskritische systemen.

Er zijn bijvoorbeeld 15 diensten die met elkaar communiceren. Dit zijn niet langer afzonderlijke sites. Die. we kunnen de service niet zelf ophalen, /helloworld downloaden en begrijpen dat de service actief is. Omdat de bestellende webservice informatie over de bestelling naar de bus – vanuit de bus – moet sturen, moet de magazijndienst dit bericht ontvangen en er verder mee werken. En de e-maildistributiedienst moet dit op de een of andere manier verder verwerken, enz.

Dienovereenkomstig kunnen we niet begrijpen dat het allemaal werkt, terwijl we op elke individuele dienst hameren. Omdat we een bepaalde bus hebben waardoor alles communiceert en op elkaar inwerkt.
Daarom zou deze fase de fase moeten markeren van het testen van diensten op interactie met andere diensten. Het is onmogelijk om communicatiemonitoring te organiseren door de berichtenmakelaar te monitoren. Als er een dienst is die gegevens uitgeeft en een dienst die deze ontvangt, zien we bij het monitoren van de makelaar alleen gegevens die heen en weer vliegen. Zelfs als we er op de een of andere manier in slagen om de interactie van deze gegevens intern te monitoren - dat een bepaalde producent de gegevens plaatst, iemand ze leest, deze stroom blijft naar Kafka gaan - zal dit ons nog steeds geen informatie opleveren als één dienst het bericht in één versie verzendt , maar de andere service had deze versie niet verwacht en heeft deze overgeslagen. We zullen dit niet weten, omdat de services ons zullen vertellen dat alles werkt.

Wat ik aanbeveel om te doen:

• Voor synchrone communicatie: het eindpunt doet verzoeken aan gerelateerde services. Die. we nemen dit eindpunt, trekken een script binnen de service, dat naar alle punten gaat en zegt: "Ik kan daarheen trekken, en daarheen trekken, ik kan daarheen trekken..."
• Voor asynchrone communicatie: inkomende berichten - het eindpunt controleert de bus op testberichten en geeft de verwerkingsstatus weer.
• Voor asynchrone communicatie: uitgaande berichten - het eindpunt verzendt testberichten naar de bus.

Zoals meestal gebeurt: we hebben een dienst die data in de bus gooit. Wij komen naar deze dienst en vragen u om ons te vertellen over de gezondheid van de integratie. En als de dienst ergens verderop (WebApp) een bericht moet produceren, dan zal hij dit testbericht produceren. En als we een service aan de OrderProcessing-kant draaien, plaatst deze eerst wat hij onafhankelijk kan posten, en als er een aantal afhankelijke dingen zijn, dan leest hij een reeks testberichten van de bus, begrijpt dat hij deze kan verwerken, rapporteren en , indien nodig, post ze verder, en hierover zegt hij: alles is in orde, ik leef.

Heel vaak horen we de vraag “hoe kunnen we dit testen op gevechtsgegevens?” We hebben het bijvoorbeeld over dezelfde bestelservice. De bestelling stuurt berichten naar het magazijn waar de goederen worden afgeschreven: we kunnen dit niet testen op gevechtsgegevens, omdat “mijn goederen worden afgeschreven!” Oplossing: Plan deze hele test vanaf het begin. Je hebt ook unit-tests die schijnvertoningen maken. Doe het dus op een dieper niveau, waar je een communicatiekanaal hebt dat de werking van het bedrijf niet schaadt.

Infrastructuurlaag

Infrastructuurmonitoring is iets dat lange tijd als monitoring zelf werd beschouwd.

• Het monitoren van de infrastructuur kan en moet als afzonderlijk proces worden gestart.
• U moet niet beginnen met het monitoren van de infrastructuur op een lopend project, ook al zou u dat heel graag willen. Dit is een pijn voor alle devops. “Eerst zal ik het cluster monitoren, ik zal de infrastructuur monitoren” – d.w.z. Ten eerste zal het monitoren wat eronder ligt, maar het zal niet ingaan op de applicatie. Omdat de applicatie voor devops een onbegrijpelijk iets is. Het is naar hem gelekt en hij begrijpt niet hoe het werkt. Maar hij begrijpt de infrastructuur en begint ermee. Maar nee: u moet altijd eerst de applicatie monitoren.
• Overdrijf niet met het aantal waarschuwingen. Gezien de complexiteit van moderne systemen vliegen er voortdurend waarschuwingen rond en moet je op de een of andere manier met deze reeks waarschuwingen leven. En de oproeper zal, na honderd van de volgende waarschuwingen te hebben bekeken, beslissen: "Ik wil er niet over nadenken." Waarschuwingen mogen alleen melding maken van kritieke zaken.

Applicatieniveau als business unit

Belangrijkste punten:

• ELK. Dit is de industriestandaard. Als u om de een of andere reden geen logboeken verzamelt, begin daar dan onmiddellijk mee.
• APM. Externe APM's als manier om applicatiemonitoring snel af te sluiten (NewRelic, BlackFire, Datadog). Je kunt dit ding tijdelijk installeren om op zijn minst op de een of andere manier te begrijpen wat er met je aan de hand is.
• Traceren. Bij tientallen microservices moet je alles traceren, omdat de aanvraag niet meer op zichzelf staat. Het is erg moeilijk om later toe te voegen, dus het is beter om de tracering tijdens de ontwikkeling onmiddellijk te plannen - dit is het werk en het nut van de ontwikkelaars. Als je het nog niet hebt geïmplementeerd, implementeer het dan! Zie Jaeger/Zipkin

Waarschuwing

• Organisatie van een notificatiesysteem: als er een heleboel dingen in de gaten moeten worden gehouden, zou er een uniform systeem moeten zijn voor het verzenden van notificaties. Dat kan in Grafana. In het Westen gebruikt iedereen PagerDuty. Waarschuwingen moeten duidelijk zijn (bijvoorbeeld waar ze vandaan komen...). En het is raadzaam om te controleren of meldingen überhaupt worden ontvangen
• Organisatie van een dienstsysteem: waarschuwingen mogen niet naar iedereen worden gestuurd (iedereen zal reageren in een menigte, of niemand zal reageren). Ontwikkelaars moeten ook bereikbaar zijn: zorg ervoor dat u de verantwoordelijkheidsgebieden definieert, duidelijke instructies geeft en daarin schrijft wie ze precies op maandag en woensdag moeten bellen, en wie ze op dinsdag en vrijdag moeten bellen (anders bellen ze zelfs in de middag niemand). geval van een groot probleem - ze zullen bang zijn om u wakker te maken of te storen: mensen houden er over het algemeen niet van om andere mensen te bellen en wakker te maken, vooral 's nachts). En leg uit dat het vragen om hulp geen indicator is van incompetentie (“Ik vraag om hulp, dat betekent dat ik een slechte werker ben”), moedig verzoeken om hulp aan.
• Organisatie van een “kennisbank” en workflow voor incidentverwerking: voor elk ernstig incident moet een autopsie worden gepland en als tijdelijke maatregel moeten acties worden vastgelegd die het incident zullen oplossen. En maak er een gewoonte van dat herhaalde waarschuwingen een zonde zijn; ze moeten worden opgelost in code of infrastructuurwerkzaamheden.

Technologie stapel

Laten we ons voorstellen dat onze stapel als volgt is:

• gegevensverzameling - Prometheus + Grafana;
• loganalyse - ELK;
• voor APM of Tracing - Jaeger (Zipkin).

De keuze van de opties is niet kritisch. Want als u in het begin begreep hoe u het systeem moest monitoren en een plan opschreef, begint u hulpmiddelen te kiezen die bij uw vereisten passen. De vraag is wat u in de eerste plaats wilt monitoren. Want misschien past de tool die je in het begin hebt gekozen helemaal niet bij jouw wensen.

Een paar technische punten die ik de laatste tijd overal zie:

Prometheus wordt Kubernetes binnengeduwd - wie heeft dit bedacht?! Wat gaat u doen als uw cluster crasht? Als je binnen een complex cluster hebt, moet er een soort monitoringsysteem binnen het cluster zijn, en een aantal daarbuiten, dat gegevens van binnen het cluster verzamelt.

Binnen het cluster verzamelen we logbestanden en al het andere. Maar het monitoringsysteem moet zich buiten bevinden. Heel vaak zijn er in een cluster waar Promtheus intern is geïnstalleerd, ook systemen die externe controles uitvoeren op de werking van de site. Wat als uw verbindingen met de buitenwereld wegvallen en de applicatie niet werkt? Binnen blijkt alles prima te zijn, maar het maakt het er voor de gebruikers niet makkelijker op.

Bevindingen

• Het monitoren van de ontwikkeling is niet het installeren van hulpprogramma's, maar het ontwikkelen van een softwareproduct. 98% van de huidige monitoring bestaat uit coderen. Diensten coderen, externe controles coderen, externe diensten controleren, en dat is alles.
• Verspil de tijd van uw ontwikkelaars niet aan monitoring: het kan tot 30% van hun werk in beslag nemen, maar het is de moeite waard.
• Devops, maak je geen zorgen dat je iets niet kunt monitoren, want sommige dingen zijn een heel andere manier van denken. Je was geen programmeur, en het monitoren van werk is precies hun taak.
• Als het project al loopt en niet wordt gemonitord (en u een manager bent), wijs dan middelen toe voor monitoring.
• Als het product al in productie is en u een ontwikkelaar bent aan wie is verteld dat hij 'monitoring moet opzetten', probeer dan aan het management uit te leggen waar ik dit allemaal over heb geschreven.

Dit is een uitgebreide versie van het rapport van de Saint Highload++ conferentie.

Als je geïnteresseerd bent in mijn ideeën en gedachten hierover en aanverwante onderwerpen, dan kun je dat hier doen lees het kanaal 🙂

Bron: www.habr.com