My naam is Anton Baderin. Ek werk by die Hoë Tegnologiesentrum en doen stelseladministrasie. 'n Maand gelede het ons korporatiewe konferensie geëindig, waar ons ons opgehoopte ervaring met die IT-gemeenskap van ons stad gedeel het. Ek het gepraat oor die monitering van webtoepassings. Die materiaal was bedoel vir junior- of middelvlak, wat nie hierdie proses van nuuts af gebou het nie.
Die hoeksteen onderliggend aan enige moniteringstelsel is die oplossing van sakeprobleme. Monitering ter wille van monitering is vir niemand van belang nie. Wat wil besigheid hê? Sodat alles vinnig en sonder foute werk. Besighede wil proaktief wees, sodat ons self probleme in die diens identifiseer en so vinnig moontlik regstel. Dit is om die waarheid te sê die probleme wat ek verlede jaar opgelos het op 'n projek vir een van ons kliënte.
Oor die projek
Die projek is een van die grootste lojaliteitsprogramme in die land. Ons help kleinhandelkettings om die frekwensie van verkope te verhoog deur verskeie bemarkingsinstrumente soos bonuskaarte. In totaal sluit die projek 14 toepassings in wat op tien bedieners loop.
Tydens die onderhoudproses het ek herhaaldelik opgemerk dat admins nie altyd die monitering van webtoepassings korrek benader nie: baie fokus steeds op bedryfstelselstatistieke en monitor dienste soms.
In my geval was die kliënt se moniteringstelsel voorheen op Icinga gebaseer. Dit het bogenoemde probleme op geen manier opgelos nie. Dikwels het die kliënt ons self ingelig oor probleme, en meer dikwels as nie, het ons eenvoudig nie genoeg data gehad om tot die onderkant van die rede te kom nie.
Daarbenewens was daar 'n duidelike begrip van die nutteloosheid van die verdere ontwikkeling daarvan. Ek dink diegene wat vertroud is met Icinga sal my verstaan. Ons het dus besluit om die webtoepassingsmoniteringstelsel vir die projek heeltemal te herontwerp.
Prometheus
Ons het Prometheus gekies op grond van drie hoofaanwysers:
- 'n Groot aantal beskikbare maatstawwe. In ons geval is daar 60 duisend van hulle. Natuurlik is dit opmerklik dat ons nie die oorgrote meerderheid daarvan gebruik nie (waarskynlik ongeveer 95%). Aan die ander kant is hulle almal relatief goedkoop. Vir ons is dit die ander uiterste in vergelyking met die voorheen gebruikte Icinga. Daarin was die byvoeging van statistieke 'n besonderse pyn: die bestaandes was duur (kyk net na die bronkode van enige inprop). Enige inprop was 'n skrif in Bash of Python, waarvan die bekendstelling duur is in terme van hulpbronne wat verbruik word.
- Hierdie stelsel verbruik 'n relatief klein hoeveelheid hulpbronne. 600 MB RAM, 15% van een kern en 'n paar dosyn IOPS is genoeg vir al ons statistieke. Natuurlik moet jy metrieke uitvoerders bestuur, maar hulle is almal in Go geskryf en is ook nie baie kraghonger nie. Ek dink nie dat dit in moderne realiteite 'n probleem is nie.
- Bied die vermoë om na Kubernetes te migreer. As die kliënt se planne in ag geneem word, is die keuse voor die hand liggend.
ELK
Voorheen het ons nie logs versamel of verwerk nie. Die tekortkominge is vir almal duidelik. Ons het ELK gekies omdat ons reeds ondervinding met hierdie stelsel gehad het. Ons stoor slegs toepassingslogboeke daar. Die hoofseleksiekriteria was voltekssoektog en die spoed daarvan.
Klikhuis
Aanvanklik het die keuse op InfluxDB geval. Ons het besef dat dit nodig is om Nginx-logboeke, statistieke van pg_stat_statements in te samel en Prometheus-historiese data te stoor. Ons het nie van Influx gehou nie, want dit het van tyd tot tyd 'n groot hoeveelheid geheue begin verbruik en neergestort het. Daarbenewens wou ek navrae groepeer deur remote_addr, maar groepering in hierdie DBMS is slegs deur etikette. Merkers is duur (geheue), hul aantal is voorwaardelik beperk.
Ons het weer begin soek. Wat nodig was, was 'n analitiese databasis met minimale hulpbronverbruik, verkieslik met datakompressie op skyf.
Clickhouse voldoen aan al hierdie kriteria, en ons was nog nooit spyt oor ons keuse nie. Ons skryf geen buitengewone hoeveelhede data daarin nie (die aantal invoegings is slegs sowat vyfduisend per minuut).
Nuwe Oorblyfsel
NewRelic was histories met ons omdat dit die kliënt se keuse was. Ons gebruik dit as 'n APM.
Zabbix
Ons gebruik Zabbix uitsluitlik om die Black Box van verskeie API's te monitor.
Definieer 'n moniteringsbenadering
Ons wou die taak ontbind en daardeur die benadering tot monitering sistematiseer.
Om dit te doen, het ek ons stelsel in die volgende vlakke verdeel:
- hardeware en VMS;
- bedryfstelsel;
- stelseldienste, sagtewarestapel;
- toepassing;
- besigheid logika.
Waarom hierdie benadering gerieflik is:
- ons weet wie verantwoordelik is vir die werk van elke vlak en op grond hiervan kan ons waarskuwings stuur;
- ons kan die struktuur gebruik wanneer waarskuwings onderdruk word - dit sal vreemd wees om 'n waarskuwing oor databasis-onbeskikbaarheid te stuur wanneer die virtuele masjien as geheel nie beskikbaar is nie.
Aangesien ons taak is om oortredings in die werking van die stelsel te identifiseer, moet ons op elke vlak 'n sekere stel maatstawwe uitlig wat die moeite werd is om aandag aan te gee wanneer waarskuwingsreëls geskryf word. Kom ons gaan dan deur die vlakke "VMS", "Bedryfstelsel" en "Stelseldienste, sagtewarestapel".
Virtuele masjiene
Hosting ken ons 'n verwerker, skyf, geheue en netwerk toe. En ons het probleme met die eerste twee gehad. Dus, die maatstawwe:
SVE gesteelde tyd - wanneer jy 'n virtuele masjien op Amazon koop (byvoorbeeld t2.micro), moet jy verstaan dat jy nie 'n hele verwerkerkern toegeken word nie, maar slegs 'n kwota van sy tyd. En wanneer jy dit uitput, sal die verwerker van jou weggeneem word.
Hierdie maatstaf laat jou toe om sulke oomblikke op te spoor en besluite te neem. Is dit byvoorbeeld nodig om 'n vetter tarief te neem of die verwerking van agtergrondtake en API-versoeke na verskillende bedieners te versprei?
IOPS + CPU-wagtyd - om een of ander rede sondig baie wolkgasheer deur nie genoeg IOPS te verskaf nie. Boonop is 'n skedule met lae IOPS nie 'n argument vir hulle nie. Daarom is dit die moeite werd om CPU iowait te versamel. Met hierdie paar grafieke - met lae IOPS en hoë I/O-wag - kan jy reeds met die gasheer praat en die probleem oplos.
Bedryfstelsel
Bedryfstelsel statistieke:
- hoeveelheid beskikbare geheue in %;
- ruil gebruiksaktiwiteit: vmstat ruil, ruil uit;
- aantal beskikbare inodes en vrye spasie op die lêerstelsel in %
- gemiddelde vrag;
- aantal verbindings in twee toestand;
- volg tafel volheid;
- Die kwaliteit van die netwerk kan gemonitor word met behulp van die ss-hulpprogram, die iproute2-pakket - kry 'n aanduiding van RTT-verbindings vanaf sy uitvoer en groepeer dit volgens bestempoort.
Ook op die bedryfstelselvlak het ons so 'n entiteit soos prosesse. Dit is belangrik om 'n stel prosesse in die stelsel te identifiseer wat 'n belangrike rol speel in die werking daarvan. As jy byvoorbeeld verskeie pgpools het, moet jy inligting vir elkeen van hulle insamel.
Die stel metrieke is soos volg:
- SVE;
- geheue is hoofsaaklik woonagtig;
- IO - verkieslik in IOPS;
- FileFd - oop en beperk;
- beduidende bladsymislukkings - op hierdie manier kan jy verstaan watter proses omgeruil word.
Ons ontplooi alle monitering in Docker, en ons gebruik Advisor om metrieke data in te samel. Op ander masjiene gebruik ons proses-uitvoerder.
Stelseldienste, sagtewarestapel
Elke toepassing het sy eie besonderhede, en dit is moeilik om 'n spesifieke stel metrieke uit te sonder.
Die universele stel is:
- versoek koers;
- aantal foute;
- latensie;
- versadiging.
Ons mees treffende voorbeelde van monitering op hierdie vlak is Nginx en PostgreSQL.
Die mees gelaaide diens in ons stelsel is die databasis. In die verlede het ons dikwels probleme gehad om uit te vind wat die databasis doen.
Ons het 'n hoë las op die skywe gesien, maar die stadige logs het nie regtig iets gewys nie. Ons het hierdie probleem opgelos met behulp van pg_stat_statements, 'n aansig wat navraagstatistieke insamel.
Dit is al wat die admin nodig het.
Ons bou grafieke van die aktiwiteit van lees- en skryfversoeke:
Alles is eenvoudig en duidelik, elke versoek het sy eie kleur.
'n Net so treffende voorbeeld is Nginx-logs. Dit is nie verbasend dat min mense hulle ontleed of in die lys van moet-hês noem nie. Die standaardformaat is nie baie insiggewend nie en moet uitgebrei word.
Persoonlik het ek request_time, upstream_response_time, body_bytes_sent, request_length, request_id bygevoeg. Ons skets reaksietyd en aantal foute:
Ons bou grafieke van reaksietyd en aantal foute. Onthou jy? Het ek oor saketake gepraat? Om vinnig en sonder foute? Ons het reeds hierdie kwessies met twee kaarte gedek. En jy kan reeds die administrateurs aan diens bel deur hulle te gebruik.
Maar nog 'n probleem bly - om die vinnige uitskakeling van die oorsake van die voorval te verseker.
Voorval oplossing
Die hele proses van identifisering tot die oplossing van 'n probleem kan in 'n aantal stappe verdeel word:
- identifisering van die probleem;
- kennisgewing aan die diensadministrateur;
- reaksie op 'n voorval;
- uitskakeling van oorsake.
Dit is belangrik dat ons dit so vinnig as moontlik moet doen. En as ons in die stadiums van die identifisering van 'n probleem en die stuur van 'n kennisgewing nie veel tyd kan wen nie - daar sal in elk geval twee minute daaraan bestee word, dan word die daaropvolgendes eenvoudig ontploeg vir verbeterings.
Kom ons verbeel ons net dat die diensbeampte se foon lui. Wat sal hy doen? Soek antwoorde op vrae - wat het gebreek, waar het dit gebreek, hoe om te reageer? Hier is hoe ons hierdie vrae beantwoord:
Ons sluit eenvoudig al hierdie inligting in die teks van die kennisgewing in, gee dit 'n skakel na 'n wiki-bladsy wat beskryf hoe om op hierdie probleem te reageer, hoe om dit op te los en te eskaleer.
Ek het nog niks gesê oor die toepassingslaag en besigheidslogika nie. Ongelukkig implementeer ons toepassings nog nie metriekeversameling nie. Die enigste bron van enige inligting vanaf hierdie vlakke is logs.
'n Paar punte.
Skryf eers gestruktureerde logs. Dit is nie nodig om konteks in die teks van die boodskap in te sluit nie. Dit maak hulle moeilik om te groepeer en te ontleed. Logstash neem 'n lang tyd om dit alles te normaliseer.
Tweedens, gebruik ernsvlakke korrek. Elke taal het sy eie standaard. Persoonlik onderskei ek vier vlakke:
- geen fout nie;
- kliënt kant fout;
- die fout is aan ons kant, ons verloor nie geld nie, ons dra nie risiko's nie;
- Die fout is aan ons kant, ons verloor geld.
Laat ek opsom. U moet probeer om monitering op grond van besigheidslogika te bou. Probeer om die toepassing self te monitor en werk met sulke maatstawwe soos die aantal verkope, die aantal nuwe gebruikerregistrasies, die aantal tans aktiewe gebruikers, ensovoorts.
As jou hele besigheid een knoppie in die blaaier is, moet jy monitor of dit klik en behoorlik werk. Al die res maak nie saak nie.
As jy dit nie het nie, kan jy probeer om dit in te haal in toepassingslogboeke, Nginx-logboeke, ensovoorts, soos ons gedoen het. Jy moet so na as moontlik aan die aansoek wees.
Bedryfstelselmaatstawwe is natuurlik belangrik, maar besigheid stel nie daarin belang nie, ons word nie daarvoor betaal nie.
Bron: will.com