Mijn naam is Anton Baderin. Ik werk bij het High Technology Center en doe systeembeheer. Een maand geleden eindigde onze bedrijfsconferentie, waar we onze opgebouwde ervaring deelden met de IT-gemeenschap van onze stad. Ik had het over het monitoren van webapplicaties. Het materiaal was bedoeld voor junior- of middenniveau, die dit proces niet helemaal opnieuw hebben opgebouwd.
De hoeksteen van elk monitoringsysteem is het oplossen van bedrijfsproblemen. Toezicht om het toezicht is voor niemand interessant. Wat wil het bedrijfsleven? Zodat alles snel en foutloos werkt. Bedrijven willen proactief zijn, zodat wij zelf problemen in de dienstverlening signaleren en zo snel mogelijk oplossen. Dit zijn in feite de problemen die ik het afgelopen jaar heb opgelost bij een project voor een van onze klanten.
Over het project
Het project is een van de grootste loyaliteitsprogramma's van het land. Wij helpen winkelketens de verkoopfrequentie te verhogen door middel van verschillende marketinginstrumenten zoals bonuskaarten. In totaal omvat het project veertien applicaties die op tien servers draaien.
Tijdens het interviewproces merkte ik herhaaldelijk dat beheerders het monitoren van webapplicaties niet altijd op de juiste manier benaderen: velen concentreren zich nog steeds op de statistieken van het besturingssysteem en monitoren af en toe services.
In mijn geval was het monitoringsysteem van de klant voorheen gebaseerd op Icinga. Het heeft de bovenstaande problemen op geen enkele manier opgelost. Vaak informeerde de klant ons zelf over problemen, en vaker wel dan niet beschikten we simpelweg niet over voldoende gegevens om de oorzaak te achterhalen.
Bovendien was er een duidelijk inzicht in de nutteloosheid van de verdere ontwikkeling ervan. Ik denk dat degenen die Icinga kennen mij zullen begrijpen. Daarom hebben we besloten om het monitoringsysteem voor webapplicaties voor dit project volledig opnieuw te ontwerpen.
Prometheus
We kozen voor Prometheus op basis van drie hoofdindicatoren:
- Een groot aantal beschikbare statistieken. In ons geval zijn het er 60 duizend. Het is natuurlijk vermeldenswaard dat we de overgrote meerderheid ervan (waarschijnlijk ongeveer 95%) niet gebruiken. Aan de andere kant zijn ze allemaal relatief goedkoop. Voor ons is dit het andere uiterste vergeleken met de eerder gebruikte Icinga. Daarin was het toevoegen van statistieken een bijzonder gedoe: de bestaande waren duur (kijk maar naar de broncode van een plug-in). Elke plug-in was een script in Bash of Python, waarvan de lancering duur is in termen van verbruikte bronnen.
- Dit systeem verbruikt een relatief kleine hoeveelheid bronnen. 600 MB RAM, 15% van één kern en een paar dozijn IOPS zijn genoeg voor al onze statistieken. Natuurlijk moet je statistische exporteurs draaien, maar die zijn allemaal in Go geschreven en zijn ook niet erg energieverslindend. Ik denk niet dat dit in de moderne realiteit een probleem is.
- Biedt de mogelijkheid om naar Kubernetes te migreren. Gezien de plannen van de klant ligt de keuze voor de hand.
ELK
Voorheen verzamelden of verwerkten we geen logbestanden. De tekortkomingen zijn voor iedereen duidelijk. Wij hebben voor ELK gekozen omdat wij al ervaring hadden met dit systeem. We slaan daar alleen applicatielogboeken op. De belangrijkste selectiecriteria waren zoeken in de volledige tekst en de snelheid ervan.
Сlickhouse
In eerste instantie viel de keuze op InfluxDB. We realiseerden ons de noodzaak om Nginx-logboeken en statistieken van pg_stat_statements te verzamelen en historische gegevens van Prometheus op te slaan. We hielden niet van Influx omdat het af en toe een grote hoeveelheid geheugen begon te verbruiken en crashte. Bovendien wilde ik zoekopdrachten groeperen op remote_addr, maar groeperen in dit DBMS gebeurt alleen op basis van tags. Tags zijn duur (geheugen), hun aantal is voorwaardelijk beperkt.
We zijn opnieuw begonnen met zoeken. Wat nodig was, was een analytische database met een minimaal verbruik van bronnen, bij voorkeur met datacompressie op schijf.
Clickhouse voldoet aan al deze criteria en we hebben nooit spijt gehad van onze keuze. We schrijven er geen buitengewone hoeveelheden gegevens in (het aantal invoegingen bedraagt slechts ongeveer vijfduizend per minuut).
NewRelic
NewRelic is van oudsher bij ons omdat het de keuze van de klant was. Wij gebruiken het als een APM.
Zabbix
Wij gebruiken Zabbix uitsluitend om de Black Box van verschillende API’s te monitoren.
Een monitoringaanpak definiëren
We wilden de taak ontleden en daarmee de aanpak van monitoring systematiseren.
Om dit te doen, heb ik ons systeem in de volgende niveaus verdeeld:
- hardware en VMS;
- besturingssysteem;
- systeemdiensten; software-stack;
- sollicitatie;
- zakelijke logica.
Waarom deze aanpak handig is:
- we weten wie verantwoordelijk is voor het werk van elk niveau en kunnen op basis hiervan waarschuwingen sturen;
- we kunnen de structuur gebruiken bij het onderdrukken van waarschuwingen - het zou vreemd zijn om een waarschuwing te sturen over de onbeschikbaarheid van de database terwijl de virtuele machine als geheel niet beschikbaar is.
Omdat het onze taak is om overtredingen in de werking van het systeem te identificeren, moeten we op elk niveau een bepaalde reeks meetgegevens onder de aandacht brengen die de moeite waard zijn om op te letten bij het schrijven van waarschuwingsregels. Laten we vervolgens de niveaus “VMS”, “Besturingssysteem” en “Systeemservices, softwarestack” doornemen.
Virtuele machines
Hosting wijst ons een processor, schijf, geheugen en netwerk toe. En met de eerste twee hadden we problemen. Dus de statistieken:
CPU-gestolen tijd - wanneer u een virtuele machine op Amazon koopt (bijvoorbeeld t2.micro), moet u begrijpen dat u niet de volledige processorkern toegewezen krijgt, maar slechts een quotum van de tijd. En als je hem uitput, wordt de processor van je afgenomen.
Met deze statistiek kunt u dergelijke momenten volgen en beslissingen nemen. Is het bijvoorbeeld nodig om een hoger tarief te hanteren of de verwerking van achtergrondtaken en API-verzoeken over verschillende servers te verdelen?
IOPS + CPU-wachttijd - om de een of andere reden zondigen veel cloudhosts door niet voldoende IOPS te bieden. Bovendien is een schema met lage IOPS voor hen geen argument. Daarom is het de moeite waard om CPU iowait te verzamelen. Met dit paar grafieken - met lage IOPS en hoge I/O-wachttijd - kunt u al met de hosting praten en het probleem oplossen.
Besturingssysteem
Statistieken van het besturingssysteem:
- hoeveelheid beschikbaar geheugen in %;
- swapgebruiksactiviteit: vmstat swapin, swapout;
- aantal beschikbare inodes en vrije ruimte op het bestandssysteem in %
- gemiddelde belasting;
- aantal verbindingen in twee staat;
- conntrack tafel volheid;
- De kwaliteit van het netwerk kan worden gecontroleerd met behulp van het ss-hulpprogramma, het iproute2-pakket - haal een indicator van RTT-verbindingen op uit de uitvoer en groepeer deze op bestemmingspoort.
Ook op besturingssysteemniveau hebben we zo'n entiteit als processen. Het is belangrijk om in het systeem een reeks processen te identificeren die een belangrijke rol spelen in de werking ervan. Als u bijvoorbeeld meerdere pgpools heeft, moet u voor elk daarvan informatie verzamelen.
De set metrieken is als volgt:
- PROCESSOR;
- het geheugen is primair residentieel;
- IO - bij voorkeur in IOPS;
- FileFd - openen en beperken;
- aanzienlijke paginafouten - op deze manier kunt u begrijpen welk proces wordt verwisseld.
We implementeren alle monitoring in Docker en we gebruiken Advisor om metrische gegevens te verzamelen. Op andere machines gebruiken we process-exporteur.
Systeemservices, softwarestack
Elke toepassing heeft zijn eigen specifieke kenmerken en het is moeilijk om er een specifieke reeks statistieken uit te halen.
De universele set is:
- verzoektarief;
- aantal fouten;
- latentie;
- verzadiging.
Onze meest opvallende voorbeelden van monitoring op dit niveau zijn Nginx en PostgreSQL.
De meest geladen service in ons systeem is de database. In het verleden hadden we vaak moeite om erachter te komen wat de database deed.
We zagen een hoge belasting van de schijven, maar de trage logs lieten niet echt iets zien. We hebben dit probleem opgelost met behulp van pg_stat_statements, een weergave die querystatistieken verzamelt.
Dat is alles wat de beheerder nodig heeft.
We maken grafieken van de activiteit van lees- en schrijfverzoeken:
Alles is eenvoudig en duidelijk, elk verzoek heeft zijn eigen kleur.
Een even treffend voorbeeld zijn Nginx-logs. Het is niet verwonderlijk dat maar weinig mensen ze analyseren of vermelden in de lijst met must-haves. Het standaardformaat is niet erg informatief en moet worden uitgebreid.
Persoonlijk heb ik request_time, upstream_response_time, body_bytes_sent, request_length, request_id toegevoegd. We zetten de responstijd en het aantal fouten in kaart:
We maken grafieken van de responstijd en het aantal fouten. Herinneren? Had ik het over zakelijke doelstellingen? Te snel en foutloos? We hebben deze kwesties al behandeld met twee grafieken. En u kunt er nu al de dienstdoende beheerders mee bellen.
Maar er blijft nog een probleem bestaan: het garanderen van een snelle eliminatie van de oorzaken van het incident.
Incidentoplossing
Het hele proces van het identificeren tot het oplossen van een probleem kan in een aantal stappen worden verdeeld:
- het identificeren van het probleem;
- kennisgeving aan de dienstdoende beheerder;
- reactie op een incident;
- eliminatie van oorzaken.
Het is belangrijk dat we dit zo snel mogelijk doen. En als we in de stadia van het identificeren van een probleem en het verzenden van een melding niet veel tijd kunnen winnen - er zullen in ieder geval twee minuten aan worden besteed, dan zijn de volgende eenvoudigweg een onbewerkt veld voor verbeteringen.
Laten we ons eens voorstellen dat de telefoon van de dienstdoende officier ging. Wat zal hij doen? Zoek naar antwoorden op vragen: wat is er kapot gegaan, waar is het kapot gegaan, hoe te reageren? Zo beantwoorden we deze vragen:
We nemen al deze informatie eenvoudigweg op in de tekst van de melding, geven er een link aan naar een wikipagina die beschrijft hoe we op dit probleem kunnen reageren, hoe we het kunnen oplossen en hoe we het kunnen escaleren.
Ik heb nog steeds niets gezegd over de applicatielaag en bedrijfslogica. Helaas implementeren onze applicaties het verzamelen van statistieken nog niet. De enige bron van informatie uit deze niveaus zijn logboeken.
Een paar punten.
Schrijf eerst gestructureerde logboeken. Het is niet nodig om context in de tekst van het bericht op te nemen. Dit maakt ze moeilijk te groeperen en analyseren. Het duurt lang voordat Logstash dit allemaal normaliseert.
Ten tweede: gebruik de ernstniveaus correct. Elke taal heeft zijn eigen standaard. Persoonlijk onderscheid ik vier niveaus:
- geen fout;
- Fout aan de clientzijde;
- de fout ligt aan onze kant: we verliezen geen geld, we dragen geen risico’s;
- De fout ligt aan onze kant, we verliezen geld.
Laat mij het samenvatten. U moet proberen monitoring op te bouwen op basis van bedrijfslogica. Probeer de applicatie zelf te monitoren en te werken met statistieken als het aantal verkopen, het aantal nieuwe gebruikersregistraties, het aantal momenteel actieve gebruikers, enzovoort.
Als uw hele bedrijf één knop in de browser is, moet u controleren of deze klikt en goed werkt. Al de rest doet er niet toe.
Als je dit niet hebt, kun je proberen het in te halen in applicatielogboeken, Nginx-logboeken, enzovoort, zoals wij deden. U moet zo dicht mogelijk bij de toepassing zijn.
Cijfers over het besturingssysteem zijn natuurlijk belangrijk, maar het bedrijfsleven is er niet in geïnteresseerd, we worden er niet voor betaald.
Bron: www.habr.com