Minu nimi on Anton Baderin. Töötan kõrgtehnoloogiakeskuses ja tegelen süsteemihaldusega. Kuu aega tagasi lõppes meie ettevõtte konverents, kus jagasime oma kogunenud kogemusi oma linna IT-kogukonnaga. Rääkisin veebirakenduste jälgimisest. Materjal oli mõeldud noorematele või keskastmetele, kes ei ehitanud seda protsessi nullist üles.
Iga seiresüsteemi nurgakivi on äriprobleemide lahendamine. Seire seire pärast ei paku kellelegi huvi. Mida äri tahab? Et kõik toimiks kiiresti ja vigadeta. Ettevõtted tahavad olla ennetavad, et tuvastaksime ise teenuses olevad probleemid ja lahendaksime need võimalikult kiiresti. Need on tegelikult probleemid, mida ma terve eelmisel aastal ühe meie kliendi projekti raames lahendasin.
umbes
Projekt on üks suurimaid lojaalsusprogramme riigis. Aitame jaekettidel suurendada müügisagedust läbi erinevate turundusvahendite nagu boonuskaardid. Kokku hõlmab projekt 14 rakendust, mis töötavad kümnes serveris.
Intervjuu käigus märkasin korduvalt, et administraatorid ei lähene veebirakenduste jälgimisele alati õigesti: paljud keskenduvad siiski operatsioonisüsteemi mõõdikutele ja aeg-ajalt jälgivad teenuseid.
Minu puhul põhines kliendi jälgimissüsteem varem Icingal. See ei lahendanud ülaltoodud probleeme kuidagi. Sageli teavitas meid probleemidest klient ise ja enamasti ei olnud meil lihtsalt piisavalt andmeid, et põhjuse põhjani jõuda.
Lisaks oli selge arusaam selle edasise arendamise mõttetusest. Ma arvan, et need, kes on Icingaga tuttavad, saavad minust aru. Seega otsustasime projekti veebirakenduste jälgimissüsteemi täielikult ümber kujundada.
Prometheus
Valisime Prometheuse kolme põhinäitaja põhjal:
- Suur hulk saadaolevaid mõõdikuid. Meie puhul on neid 60 tuhat. Muidugi väärib märkimist, et me ei kasuta neist valdavat enamust (ilmselt umbes 95%). Teisest küljest on need kõik suhteliselt odavad. Meie jaoks on see teine äärmus võrreldes varem kasutusel olnud Icingaga. Selles oli mõõdikute lisamine eriti valus: olemasolevad olid kallid (vaadake lihtsalt mis tahes pistikprogrammi lähtekoodi). Iga pistikprogramm oli Bashis või Pythonis skript, mille käivitamine on kulutatud ressursside poolest kallis.
- See süsteem tarbib suhteliselt vähe ressursse. Kõigi meie mõõdikute jaoks piisab 600 MB RAM-ist, 15% ühest tuumast ja paarikümnest IOPS-ist. Muidugi peate juhtima mõõdikute eksportijaid, kuid need on kõik Go keeles kirjutatud ja pole ka väga energianäljased. Ma ei usu, et tänapäevases reaalsuses on see probleem.
- Annab võimaluse migreeruda Kubernetesesse. Arvestades kliendi plaane, on valik ilmne.
ELK
Varem me logisid ei kogunud ega töötlenud. Puudused on kõigile selged. Valisime ELK-i, kuna meil oli selle süsteemiga juba kogemusi. Salvestame seal ainult rakenduste logisid. Peamisteks valikukriteeriumideks olid täistekstiotsing ja selle kiirus.
Сlickhouse
Esialgu langes valik InfluxDB-le. Mõistsime, et on vaja koguda Nginxi logisid, pg_stat_statementsi statistikat ja salvestada Prometheuse ajaloolisi andmeid. Meile Influx ei meeldinud, sest see hakkas aeg-ajalt palju mälu tarbima ja jooksis kokku. Lisaks tahtsin päringuid grupeerida kaug-addr järgi, kuid selles DBMS-is rühmitatakse ainult siltide järgi. Sildid on kallid (mälu), nende arv on tinglikult piiratud.
Alustasime otsingutega uuesti. Vaja oli minimaalse ressursikuluga analüütilist andmebaasi, soovitavalt andmete tihendamisega kettal.
Clickhouse vastab kõigile neile kriteeriumidele ja me pole oma valikut kordagi kahetsenud. Me ei kirjuta sinna erakordselt suuri andmeid (sisestusi on vaid umbes viis tuhat minutis).
NewRelic
NewRelic on ajalooliselt olnud meiega, sest see oli kliendi valik. Me kasutame seda APM-ina.
Zabbix
Kasutame Zabbixi ainult erinevate API-de musta kasti jälgimiseks.
Seiremeetodi määratlemine
Tahtsime ülesande lahti võtta ja seeläbi süstematiseerida lähenemist monitooringule.
Selleks jagasin meie süsteemi järgmisteks tasemeteks:
- riistvara ja VMS;
- operatsioonisüsteem;
- süsteemiteenused, tarkvarapinn;
- rakendus;
- äriloogika.
Miks see meetod on mugav:
- teame, kes vastutab iga taseme töö eest ja selle põhjal saame teateid saata;
- saame seda struktuuri kasutada hoiatuste mahasurumisel – oleks imelik saata hoiatust andmebaasi kättesaamatuse kohta, kui virtuaalmasin tervikuna pole saadaval.
Kuna meie ülesanne on tuvastada rikkumisi süsteemi töös, siis peame igal tasandil esile tooma teatud mõõdikute komplekti, millele tasub hoiatusreeglite kirjutamisel tähelepanu pöörata. Järgmisena käime läbi tasemed "VMS", "Operatsioonisüsteem" ja "Süsteemiteenused, tarkvarapinn".
Virtuaalsed masinad
Hosting eraldab meile protsessori, ketta, mälu ja võrgu. Ja kahe esimesega oli meil probleeme. Niisiis, mõõdikud:
CPU varastatud aeg – ostes Amazonist virtuaalmasina (nt t2.micro), peaksite mõistma, et teile ei eraldata tervet protsessorituuma, vaid ainult teatud aja kvoot. Ja kui ammendad, võetakse protsessor sinult ära.
See mõõdik võimaldab teil selliseid hetki jälgida ja otsuseid teha. Kas näiteks on vaja võtta rasvasem tariif või jagada taustaülesannete ja API päringute töötlemine erinevatele serveritele?
IOPS + CPU ooteaeg – millegipärast teevad paljud pilvemajutusteenused pattu, kuna ei paku piisavalt IOPS-i. Pealegi pole madala IOPS-iga ajakava nende jaoks argument. Seetõttu tasub CPU iowait koguda. Selle graafikupaariga – madala IOPS-i ja kõrge I/O-ooteajaga – saate juba hostiga rääkida ja probleemi lahendada.
Operatsioonisüsteem
Operatsioonisüsteemi mõõdikud:
- vaba mälu maht %;
- swap kasutustegevus: vmstat swapin, swapout;
- saadaolevate inoodide arv ja vaba ruumi failisüsteemis %
- keskmine koormus;
- ühenduste arv tw olekus;
- conntrack tabeli täius;
- Võrgu kvaliteeti saab jälgida ss-utiliidi, paketi iproute2 abil - hankige selle väljundist RTT ühenduste indikaator ja rühmitage see sihtpordi järgi.
Ka operatsioonisüsteemi tasemel on meil selline olem nagu protsessid. Oluline on tuvastada süsteemis protsesside kogum, mis mängib selle toimimises olulist rolli. Kui teil on näiteks mitu pgpooli, peate koguma teavet nende kõigi kohta.
Mõõdikute komplekt on järgmine:
- PROTSESSOR;
- mälu on peamiselt püsiv;
- IO - eelistatavalt IOPS-is;
- FileFd - avatud ja piirang;
- olulised lehetõrked – nii saate aru, millist protsessi vahetatakse.
Juurutame kogu jälgimise Dockeris ja kasutame mõõdikute andmete kogumiseks Advisorit. Teistel masinatel kasutame protsessi-eksportijat.
Süsteemiteenused, tarkvarapinn
Igal rakendusel on oma eripärad ja konkreetset mõõdikute komplekti on raske välja tuua.
Universaalne komplekt on:
- taotluse määr;
- vigade arv;
- latentsusaeg;
- küllastus.
Meie kõige silmatorkavamad näited selle taseme jälgimisest on Nginx ja PostgreSQL.
Meie süsteemis on enim koormatud teenus andmebaas. Varem oli meil sageli probleeme andmebaasi tegemiste leidmisega.
Nägime ketaste suurt koormust, kuid aeglased logid ei näidanud tegelikult midagi. Lahendasime selle probleemi, kasutades vaadet pg_stat_statements, mis kogub päringustatistikat.
See on kõik, mida administraator vajab.
Koostame lugemis- ja kirjutamistaotluste aktiivsuse graafikud:
Kõik on lihtne ja selge, igal taotlusel on oma värv.
Sama silmatorkav näide on Nginxi logid. Pole üllatav, et vähesed inimesed analüüsivad neid või mainivad neid kohustuslike asjade loendis. Standardformaat ei ole väga informatiivne ja vajab laiendamist.
Mina isiklikult lisasin request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Joonistame reaktsiooniaja ja vigade arvu:
Koostame reaktsiooniaja ja vigade arvu graafikud. Mäletad? Kas ma rääkisin äriülesannetest? Kas kiiresti ja ilma vigadeta? Oleme neid probleeme juba kahe graafikuga käsitlenud. Ja juba saab neid kasutades helistada valves olevatele administraatoritele.
Kuid veel üks probleem jääb - tagada intsidendi põhjuste kiire kõrvaldamine.
Juhtumi lahendamine
Kogu protsessi probleemi tuvastamisest lahendamiseni võib jagada mitmeks etapiks:
- probleemi tuvastamine;
- teavitamine valvehaldurile;
- reageerimine intsidendile;
- põhjuste kõrvaldamine.
On oluline, et me teeme seda võimalikult kiiresti. Ja kui probleemi tuvastamise ja teatise saatmise etapis ei saa me palju aega võita - kaks minutit kulub neile igal juhul, siis järgmised on lihtsalt parenduste jaoks kündmata põld.
Kujutagem ette, et korrapidaja telefon helises. Mida ta teeb? Otsige vastuseid küsimustele – mis läks katki, kus purunes, kuidas reageerida? Nendele küsimustele vastame järgmiselt.
Lisame kogu selle teabe lihtsalt teatise teksti, anname sellele lingi vikilehele, mis kirjeldab, kuidas sellele probleemile reageerida, kuidas seda lahendada ja eskaleerida.
Ma pole ikka veel midagi öelnud rakenduskihi ja äriloogika kohta. Kahjuks ei rakenda meie rakendused veel mõõdikute kogumist. Nende tasemete teabe ainus allikas on logid.
Paar punkti.
Esiteks kirjutage struktureeritud logid. Sõnumi teksti ei ole vaja konteksti lisada. See muudab nende rühmitamise ja analüüsimise keeruliseks. Logstash võtab selle kõige normaliseerimiseks kaua aega.
Teiseks kasutage raskusastmeid õigesti. Igal keelel on oma standard. Isiklikult eristan nelja taset:
- viga pole;
- kliendipoolne viga;
- viga on meie poolel, me ei kaota raha, me ei võta riske;
- Viga on meie poolel, kaotame raha.
Lubage mul teha kokkuvõte. Peate proovima üles ehitada äriloogikast lähtuva monitooringu. Proovige jälgida rakendust ennast ja opereerida selliste mõõdikutega nagu müükide arv, uute kasutajate registreerimiste arv, hetkel aktiivsete kasutajate arv jne.
Kui kogu teie ettevõte on brauseris üks nupp, peate jälgima, kas see klõpsab ja töötab korralikult. Kõik ülejäänu ei oma tähtsust.
Kui teil seda pole, võite proovida sellele järele jõuda rakenduste logides, Nginxi logides ja nii edasi, nagu meie tegime. Peaksite olema rakendusele võimalikult lähedal.
Operatsioonisüsteemi mõõdikud on muidugi olulised, aga äri ei tunne nende vastu huvi, meile ei maksta nende eest.
Allikas: www.habr.com