Mäin Numm ass Anton Baderin. Ech schaffen am High Technology Center a maachen Systemverwaltung. Virun engem Mount ass eis Firmenkonferenz eriwwer, wou mir eis gesammelt Erfahrung mat der IT Gemeinschaft vun eiser Stad gedeelt hunn. Ech hunn iwwer d'Iwwerwaachung vun Webapplikatiounen geschwat. D'Material war geduecht fir Junior oder Mëttelstuf, déi dëse Prozess net vun Null opgebaut hunn.
Den Ecksteen ënnerierdesch all Iwwerwaachungssystem ass d'Léisung vu Geschäftsproblemer. D'Iwwerwaachung fir d'Iwwerwaachung ass fir jiddereen net interesséiert. Wat wëll d'Geschäft? Sou datt alles séier an ouni Feeler funktionnéiert. D'Betriber wëllen proaktiv sinn, fir datt mir selwer Problemer am Service identifizéieren an esou séier wéi méiglech fixéieren. Dat sinn eigentlech d'Problemer déi ech d'lescht Joer op engem Projet fir ee vun eise Clienten geléist hunn.
Iwwer de Projet
De Projet ass ee vun de gréisste Loyalitéit Programmer am Land. Mir hëllefen Retail Ketten Erhéijung der Frequenz vun Ofsaz duerch verschidde Marketing Handwierksgeschir wéi Bonus Kaarte. Am Ganzen enthält de Projet 14 Uwendungen déi op zéng Server lafen.
Wärend dem Interviewprozess hunn ech ëmmer erëm gemierkt datt d'Administrateuren net ëmmer d'Iwwerwaachung vun Webapplikatiounen korrekt ugoen: vill konzentréieren sech nach ëmmer op Betriebssystem Metriken an iwwerwaachen heiansdo Servicer.
A mengem Fall war d'Iwwerwaachungssystem vum Client virdru baséiert op Icinga. Et huet déi uewe genannte Problemer op kee Fall geléist. Dacks huet de Client eis selwer iwwert d'Problemer informéiert, a méi dacks hu mir einfach net genuch Donnéeën, fir op de Grond ze kommen.
Zousätzlech gouf et e kloert Verständnis vun der Futilitéit vu senger Weiderentwécklung. Ech mengen déi, déi mat Icinga vertraut sinn, wäerte mech verstoen. Also hu mir décidéiert de Webapplikatiouns Iwwerwaachungssystem fir de Projet komplett nei ze designen.
Prometheus
Mir hunn de Prometheus gewielt op Basis vun dräi Haaptindikatoren:
- Eng grouss Zuel vu verfügbare Metriken. An eisem Fall sinn et 60 dausend vun hinnen. Natierlech ass et derwäert ze notéieren datt mir net déi grouss Majoritéit vun hinnen benotzen (wahrscheinlech ongeféier 95%). Op der anerer Säit sinn se all relativ bëlleg. Fir eis ass dëst den aneren Extrem am Verglach zum virdru benotzte Icinga. An et war d'Metriken derbäi e besonnesche Schmerz: déi existent waren deier (kuckt just de Quellcode vun all Plugin). All Plugin war e Skript am Bash oder Python, de Start vun deem ass deier a punkto verbrauchte Ressourcen.
- Dëse System verbraucht eng relativ kleng Quantitéit u Ressourcen. 600 MB RAM, 15% vun engem Kär an e puer Dosen IOPS si genuch fir all eis Metriken. Natierlech musst Dir Metrikexporter lafen, awer si sinn all a Go geschriwwen a sinn och net ganz Kraafthonger. Ech mengen net, datt an modern Realitéiten dëst e Problem ass.
- Bitt d'Fäegkeet fir op Kubernetes ze migréieren. Wann Dir d'Pläng vum Client berücksichtegt, ass d'Wiel evident.
ELK
Virdru hu mir keng Logbicher gesammelt oder veraarbecht. D'Defiziter si fir jiddereen kloer. Mir hunn ELK gewielt well mir scho Erfahrung mat dësem System hunn. Mir späicheren nëmmen Applikatiounsprotokoller do. D'Haaptauswielkriterien waren Volltext Sich a seng Geschwindegkeet.
Klickhaus
Am Ufank ass de Choix op InfluxDB gefall. Mir hunn de Besoin realiséiert fir Nginx Logbicher ze sammelen, Statistike vu pg_stat_statements, a Prometheus historesch Daten ze späicheren. Mir hunn den Influx net gär well et periodesch ugefaang huet eng grouss Quantitéit un Erënnerung ze konsuméieren an erofgefall ass. Zousätzlech wollt ech Ufroe vu remote_addr gruppéieren, awer d'Gruppéierung an dësem DBMS ass nëmme vu Tags. Tags sinn deier (Erënnerung), hir Zuel ass bedingt limitéiert.
Mir hunn eis Sich erëm ugefaang. Wat gebraucht gouf war eng analytesch Datebank mat minimalem Ressourceverbrauch, am léifsten mat Datekompressioun op Disk.
Clickhouse entsprécht all dës Critèren, a mir hunn ni eise Choix bedauert. Mir schreiwen keng aussergewéinlech Quantitéiten un Daten an et (d'Zuel vun den Insertiounen ass nëmmen ongeféier fënnef dausend pro Minutt).
NewRelik
NewRelic war historesch bei eis well et de Client säi Choix war. Mir benotzen et als APM.
Zabbix
Mir benotzen Zabbix exklusiv fir d'Black Box vu verschiddenen APIen ze iwwerwaachen.
Eng Iwwerwaachungs Approche definéieren
Mir wollten d'Aufgab ofbauen an domat d'Approche fir d'Iwwerwaachung systematiséieren.
Fir dëst ze maachen, hunn ech eise System an déi folgend Niveauen opgedeelt:
- Hardware a VMS;
- Betribssystem;
- System Servicer, Software Stack;
- Applikatioun;
- Geschäftslogik.
Firwat dës Approche praktesch ass:
- mir wësse wien fir d'Aarbecht vun all Niveau verantwortlech ass a baséiert op dësem kënne mir Alarm schécken;
- mir kënnen d'Struktur benotzen wann Dir Alarmer ënnerdréckt - et wier komesch eng Alarm iwwer d'Datebankunverfügbarkeet ze schécken wann déi virtuell Maschinn als Ganzt net verfügbar ass.
Well eis Aufgab ass d'Verletzungen an der Operatioun vum System z'identifizéieren, musse mir op all Niveau e bestëmmte Set vu Metriken ervirhiewen, déi et wäert sinn oppassen wann Dir Alarmregelen schreift. Als nächst gi mer duerch d'Niveauen "VMS", "Betriebssystem" an "Systemservicer, Software Stack".
Virtuell Maschinnen
Hosting Allokéiert eis CPU-, Festplatte-, Speicher- a Netzwierkressourcen. Mir haten Problemer mat den éischten zwee. Hei sinn also d'Metriken:
CPU geklaut Zäit - wann Dir eng virtuell Maschinn op Amazon kaaft (t2.micro, zum Beispill), sollt Dir verstoen datt Dir net e ganze Prozessorkär zougewisen hutt, awer nëmmen eng Quote vu senger Zäit. A wann Dir et ausschalt, gëtt de Prozessor vun Iech ewechgeholl.
Dës Metrik erlaabt Iech, sou Problemer ze verfollegen an Entscheedungen ze treffen. Zum Beispill, sollt Dir op en méi héije Plang upgraden oder d'Veraarbechtung vun Hannergrondaufgaben an API-Ufroen op verschidden Aufgaben opdeelen? Server.
IOPS + CPU iowait Zäit - aus irgendege Grënn, vill Wollek Hosting sënnegen andeems se net genuch IOPS ubidden. Ausserdeem ass e Zäitplang mat nidderegen IOPS keen Argument fir si. Dofir ass et derwäert CPU iowait ze sammelen. Mat dësem Pair vu Grafike - mat nidderegen IOPS an héijer I/O Waart - kënnt Dir scho mam Hosting schwätzen an de Problem léisen.
Betribssystem
Betribssystem Metriken:
- Betrag vun verfügbaren Erënnerung an %;
- Tauschen Benotzungsaktivitéit: vmstat swapin, tauschen;
- Zuel vun verfügbaren Inoden a fräi Plaz am Dateiesystem an %
- duerchschnëttlech Belaaschtung;
- Zuel vun Verbindungen an zwee Staat;
- conntrack Dësch voll;
- D'Qualitéit vum Netz kann iwwerwaacht ginn mat dem ss Utility, dem iproute2 Package - kritt en Indikator vun RTT Verbindunge vu sengem Output a gruppéiert se no dest Hafen.
Och um Betribssystemniveau hu mir sou eng Entitéit wéi Prozesser. Et ass wichteg am System eng Rei vu Prozesser z'identifizéieren déi eng wichteg Roll a senger Operatioun spillen. Wann Dir zum Beispill e puer pgpools hutt, da musst Dir Informatiounen fir all eenzel sammelen.
De Set vu Metriken ass wéi follegt:
- CPUs;
- Erënnerung ass virun allem Awunner;
- IO - am léifsten am IOPS;
- FileFd - oppen a limitéieren;
- bedeitend Säitfehler - sou kënnt Dir verstoen wat de Prozess ausgetauscht gëtt.
All Iwwerwaachung gëtt am Docker ofgesat, a mir benotze Advisor fir Metrikdaten ze sammelen. Op anere Maschinnen benotze mir Prozess-Exporter.
System Servicer, Software Stack
All Applikatioun huet seng eege Spezifizitéiten, an et ass schwéier eng spezifesch Rei vu Metriken auszeschléissen.
Den universelle Set ass:
- Ufro Taux;
- Zuel vu Feeler;
- latency;
- Sättigung.
Eis opfällegste Beispiller fir Iwwerwaachung op dësem Niveau sinn Nginx a PostgreSQL.
Dee meescht geluedene Service an eisem System ass d'Datebank. An der Vergaangenheet hu mir dacks Probleemer erauszefannen wat d'Datebank mécht.
Mir hunn eng héich Laascht op den Disken gesinn, awer déi lues Logbicher hunn näischt wierklech gewisen. Mir hunn dëse Problem geléist mat pg_stat_statements, eng Vue déi Ufrostatistike sammelt.
Dat ass alles wat den Admin brauch.
Mir bauen Grafike vun der Aktivitéit vu Lies- a Schreiffuerderungen:
Alles ass einfach a kloer, all Ufro huet seng eege Faarf.
E gläich markant Beispill ass Nginx Logbicher. Et ass net iwwerraschend datt wéineg Leit se parséieren oder se an der Lëscht vu Must-Haves ernimmen. De Standardformat ass net ganz informativ a muss ausgebaut ginn.
Perséinlech hunn ech request_time, upstream_response_time, body_bytes_sent, request_length, request_id bäigefüügt. Mir plotten d'Äntwertzäit an d'Zuel vu Feeler:
Mir bauen Grafike vun der Äntwertzäit an der Zuel vu Feeler. Erënneren? Hunn ech iwwer Geschäftsaufgaben geschwat? Fir séier an ouni Feeler? Mir hunn dës Themen scho mat zwee Charts ofgedeckt. An Dir kënnt schonn d'Administrateuren op Flicht ruffen mat hinnen.
Awer nach ee Problem bleift - fir d'séier Eliminatioun vun den Ursaachen vum Virfall ze garantéieren.
Tëschefall Resolutioun
De ganze Prozess vun der Identifikatioun bis zur Léisung vun engem Problem kann an e puer Schrëtt opgedeelt ginn:
- Identifikatioun vum Problem;
- Notifikatioun un de Flicht Administrateur;
- Äntwert op en Tëschefall;
- Eliminatioun vun Ursaachen.
Et ass wichteg, datt mir dat esou séier wéi méiglech maachen. A wann an de Stadien vun der Identifikatioun vun engem Problem an engem Notifikatioun schécken, kënne mir net vill Zäit gewannen - zwou Minutte wäert op hinnen op all Fall verbruecht ginn, dann déi folgend sinn einfach unplowed Terrain fir Verbesserungen.
Loosst eis emol virstellen, datt den Telefon vum Flichtebeamten geklappt huet. Wat wäert hien maachen? Kuckt no Äntwerten op Froen - wat ass gebrach, wou ass et gebrach, wéi reagéiert? Hei ass wéi mir dës Froen beäntweren:
Mir schloen all dës Informatioun einfach an den Text vun der Notifikatioun, ginn et e Link op eng Wiki-Säit déi beschreift wéi een op dëse Problem reagéiert, wéi een et léist an eskaléiert.
Ech hunn nach ëmmer näischt iwwer d'Applikatiounsschicht a Geschäftslogik gesot. Leider implementéieren eis Uwendungen nach keng Metrik Sammlung. Déi eenzeg Quell vun all Informatioun vun dësen Niveauen ass Logbicher.
E puer Punkten.
Als éischt schreiwen strukturéiert Logbicher. Et ass net néideg Kontext am Text vun der Noriicht ze enthalen. Dëst mécht se schwéier ze gruppéieren an ze analyséieren. Logstash brauch eng laang Zäit fir dëst alles ze normaliséieren.
Zweetens, benotzt d'Gravitéitsniveauen korrekt. All Sprooch huet säin eegene Standard. Perséinlech ënnerscheeden ech véier Niveauen:
- kee Feeler;
- Client Säit Feeler;
- de Feeler ass op eiser Säit, mir verléieren keng Suen, mir droen keng Risiken;
- De Feeler ass op eiser Säit, mir verléieren Suen.
Loosst mech resuméieren. Dir musst probéieren Iwwerwaachung op Basis vu Geschäftslogik ze bauen. Probéiert d'Applikatioun selwer ze iwwerwaachen an operéiere mat esou Metriken wéi d'Zuel vun de Verkaf, d'Zuel vun den neie Benotzerregistrierungen, d'Zuel vun den aktuellen aktive Benotzer, asw.
Wann Äre ganze Geschäft ee Knäppchen am Browser ass, musst Dir iwwerwaachen ob et klickt a richteg funktionnéiert. All de Rescht ass egal.
Wann Dir dëst net hutt, kënnt Dir probéieren et an Applikatioun Logbicher, Nginx Logbicher, a sou weider, wéi mir et gemaach hunn. Dir sollt esou no wéi méiglech un der Applikatioun sinn.
Betribssystem Metriken sinn natierlech wichteg, mä d'Geschäft ass net interesséiert hinnen, mir ginn net fir si bezuelt.
Source: will.com
