🥇Kuidas me ehitasime jälgimise Prometheuse, Clickhouse'i ja ELK abil

Minu nimi on Anton Baderin. Töötan Kõrgete Tehnoloogiate Keskuses ja tegelen süsteemiadministreerimisega. Kuu aega tagasi lõppes meie ettevõtte konverents, kus jagasime oma teadmisi linna IT-kogukonnaga. Rääkisin veebirakenduste jälgimisest. Materjal oli suunatud junior või middle tasemele, kellel ei ole seda protsessi nullist üles ehitatud.

Iga jälgimissüsteemi nurgakivi on äriülesannete lahendamine. Jälgimine iseenesest ei huvita kedagi. Aga mida soovib äri? Et kõik töötaks kiiresti ja ilma vigadeta. Äri soovib proaktiivsust, et me ise tuvastaks probleemid teenuse toimimises ja lahendaks need maksimaalselt kiiresti. Just need olidki ülesanded, millega eelmisel aastal ühe meie kliendi projektis tegelesin.

Projektist

Projekt on üks suurimaid lojaalsusprogramme riigis. Aitame jaemüügiketidel suurendada müügifrekventsi erinevate turundusinstrumentide, näiteks boonuskardid, kaudu. Projekti kuulub kokku 14 rakendust, mis töötavad kümnel serveril.

Vestluste käigus olen korduvalt märganud, et administraatorid ei lähenenud veebirakenduste jälgimisele alati õigesti: paljud piirdusid endiselt operatsioonisüsteemi mõõdikute jälgimisega ja harva jälgisid teenuseid.

Minu puhul põhines kliendi jälgimissüsteem varem Icingal. See ei lahendanud ülaltoodud ülesandeid. Klient teatas sageli ise meile probleemidest ja meil jäi tihti andmetest puudu, et süvitsi kaevata põhjuse leidmiseks.

Lisaks oli selge arusaam, et selle edasine arendamine ei ole perspektiivikas. Mulle tundub, et need, kes tunnevad Icinga, saavad mind hästi aru. Nii otsustasime täielikult ümber kujundada veebirakenduste jälgimissüsteemi projektis.

Prometheus

Valisime Prometheuse, lähtudes kolmest põhinäitajast:

Suur hulk saadaval mõõdikuid. Meie puhul on neid 60 000. Loomulikult tuleb märkida, et enamikku neist me ei kasuta (ilmselt umbes 95%). Teisest küljest on need kõik suhteliselt odavad. Meie jaoks on see teine äärmuses võrreldes varasemalt kasutatud Icingaga. Seal oli mõõdikute lisamine eriti keeruline: olemasolevad olid kallid (piisab, kui vaadata mistahes plugina lähtekoodi). Iga plugin oli kas Bash või Python skript, mille käitamine on ressursikulu mõttes kallis.
See süsteem tarbib suhteliselt vähe ressursse. Kõikide meie mõõdikute jaoks piisab 600 MB RAM-ist, 15% ühest tuumast ja paarikümnest IOPS-ist. Loomulikult tuleb käitada mõõdikute eksportijaid, kuid kõik need on kirjutatud Go keeles ja ei ole ka liiga näljased. Ei arva, et see oleks praegustes oludes probleem.
Pakub võimalust üleminekuks Kubernetesesse. Arvestades kliendi plaane — valik on ilmne.

ELK

Varasemalt me logisid ei kogunud ega töötlenud. Puudused on kõigile selged. Valisime ELK, kuna meil oli selle süsteemiga juba varasem kogemus. Säilitame seal ainult rakenduste logisid. Peamisteks valikukriteeriumiteks olid täisteksti otsing ja selle kiirus.

Clickhouse

Alguses langes valik InfluxDB-le. Tunnustasime vajadust koguda Nginx logisid, statistikat pg_stat_statements-st ja säilitada ajaloolisi andmeid Prometheuse kohta. Influx ei meeldinud meile, kuna see hakkas perioodiliselt tarbima suures koguses mälu ja lakkas töötamast. Lisaks soovisime rühmitada päringud remote_addr järgi, kuid selle SÜSISD-s sai rühmitada ainult siltide järgi. Sildid on kallid (mälu), nende arv on tinglikult piiratud.

Alustasime otsingut uuesti. Vajasime analüütilise baasi minimaalsete ressursinõuetega, soovitavalt andmete tihendamisega kettal.

Clickhouse vastab kõikidele nendele kriteeriumidele ja me ei ole kordagi oma valikut kahetsenud. Me ei kirjuta sinna mingeid erakordseid andmemahtusid (kandmise arvu on kokku umbes viis tuhat minutis).

NewRelic

NewRelic on ajalooliselt meiega olnud, kuna see oli kliendi valik. Me kasutame seda APM-i jaoks.

Zabbix

Kasutame Zabbixit ainult erinevate API-de Black Box'i monitooringuks.

Monitooringu lähenemise määratlemine

Soovisime dekomponeerida ülesande ja seeläbi süsteematiseerida lähenemise monitooringule.

Selle jaoks jagasin meie süsteemi järgmisteks tasemeteks:

„ra hardware” ja VMS;
operatsioonisüsteem;
süsteemiteenused, tarkvara kiht;
rakendus;
äri_loogika.

Miks on selline lähenemine mugav:

me teame, kes on vastutav iga taseme töö eest ja selle põhjal saame saata häireid;
me saame kasutada struktuuri häirete supresseerimisel — oleks kummaline saata häire andmebaasi kättesaamatuse tõttu, kui kogu virtuaalne masin on kättesaamatu.

Kuna meie eesmärk on tuvastada süsteemi töökatkestusi, peame igas tasemes välja tooma teatud metoodika, millega tuleks häire reeglite kirjutamisel arvestada. Edasi liigume tasemete „VMS”, „Operatsioonisüsteem” ja „Süsteemiteenused, tarkvara kiht” juurde.

Virtuaalsed masinad

Veebimajutus eraldab meile protsessori, ketta, mälu ja võrgu. Ja esimesega oli meil probleeme. Seega, mõõdud:

CPU varastatud aeg — kui ostate virtuaalmasina Amazonis (nt t2.micro), siis tuleb mõista, et teile eraldatakse mitte täiskern, vaid vaid osa selle ajast. Kui saavutate selle piiri, hakkavad nad teie protsessorit ära võtma.

See mõõde võimaldab jälgida selliseid hetki ja teha otsuseid. Näiteks, kas on vajalik kõrgem hinnapakett või tuleks taustülesannete töötlemine ja API päringud eraldi jagada serverilt.

IOPS + CPU iowait aeg — kummalisel kombel paljud pilvehostingute pakkujad ei paku piisavalt IOPS-i. Veelgi enam, madalate IOPS-idega graafik ei ole neile argument. Seetõttu tasub koguda ka CPU iowait. Selle kahe graafiku — madalate IOPS-ide ja kõrge sisend-väljundi ootega — abil saab juba rääkida hostingsüsteemiga ja lahendada probleemi.

Operatsioonisüsteem

Operatsioonisüsteemi mõõdud:

kasutatava mäluhulga protsent;
swap kasutamise aktiivsus: vmstat swapin, swapout;
olemasolevate inode'ide arv ja vaba koht failisüsteemis protsentides;
keskmine koormus;
ühenduste arv, mis on olekus tw;
conntrack tabeli täituvus;
võrgu töö kvaliteeti saab jälgida utiliidi ss abil, iproute2 pakett — saada selle väljundist RTT-ühenduste näit ja grupeerida siht-portide järgi.

Samuti ilmub operatsioonisüsteemi tasemel meil selline üksus nagu protsessid. Oluline on tuvastada süsteemis protsesside kogum, mis mängib olulist rolli selle töös. Kui teil on näiteks mitu pgpooli, siis tuleb üles ehitada informatsioon igaühe kohta.

Mõõtmete kogum on järgmine:

CPU;
mälu — eelkõige resideeruv;
IO — soovitavalt IOPS-is;
FileFd — avatud ja limiit;
olulised lehevead — nii saate aru, milline protsess vahetub.

Kogu jälgimine on meil seadistatud Dockeris, andmemõõdikute kogumise jaoks kasutame Сadvisor. Teistes masinates rakendame process-exporter'i.

Süsteemiteenused, tarkvarariba

Igal rakendusel on oma spetsiifika ning on keeruline välja tuua teatud mõõdikute komplekti.

Universaalne komplekt on:

päringute määr;
vea arv;
latentsus;
saturatsioon.

Kõige silmapaistvamad näited selle taseme jälgimisest meie juures on — Nginx ja PostgreSQL.

Meie süsteemis on kõige koormatud teenus andmebaas. Varem oli meil sageli probleeme välja selgitada, millega andmebaas tegeleb.

Oleme näinud kõrget koormust kettale, kuid aeglasi logisid ei näidanud suurt midagi. Selle probleemi lahendasime pg_stat_statements abil, vaate abil, kuhu kogutakse päringute statistikat.

See on kõik, mis administraatorile vajalik.

Koonname tegevusgraafikud lugemiseks ja kirjutamiseks:

Kõik on lihtne ja arusaadav, igal päringul — oma värv.

Vähemalt sama silmapaistev näide on Nginx-i logid. Ei ole üllatav, et vähe kellelgi neid analüüsida või kohustuslikena loetleda. Standardvorming pole väga informatiivne ja seda tuleb laiendada.

Isiklikult lisasin request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Koonname vastuse aja ja vea arvu graafikud:

Koonname vastuse aja ja vea arvu graafikud. Kas mäletate? Rääkisin äriülesannetest? Et kiiresti ja ilma vigadeta? Me oleme juba kahe graafiku abil need küsimused lahendanud. Ja nende põhjal saab juba helistada valveadminnidele.

Kuid on veel üks probleem — tagada kiire lahendus juhtumi põhjustele.

Juhtumite lahendamine

Kogu protsessi probleemide tuvastamisest kuni lahendamiseni saab jagada mitmeks sammuks:

probleemi tuvastamine;
valveadministraatori teavitamine;
reaktsioon juhtumile;
põhjuste kõrvaldamine.

Oluline on, et me peaksime seda tegema võimalikult kiiresti. Ja kui probleemide tuvastamise ja teavitamise etappidel me palju aega kokku hoida ei saa — need võtavad igal juhul kaks minutit, siis järgmised — on täiesti avatud valdkond parendamiseks.

Kujutage ette, et valves oleva inimese telefon heliseb. Mida ta teeb? Otsib vastuseid küsimustele - mis katki läks, kus see juhtus, kuidas reageerida? Nii vastame nendele küsimustele:

Me lihtsalt lisame kogu selle teabe teate tekstis, anname seal lingi lehele Vikis, kus on kirjas, kuidas sellele probleemile reageerida, kuidas seda lahendada ja eskaleerida.

Ma pole siiani midagi öelnud rakenduse ja äriloogika tasemest. Kahjuks ei ole meie rakendustes veel mõõdikute kogumine rakendatud. Ainus allikas mingisuguste andmete jaoks nendelt tasemetelt on logid.

Kaks punkti.

Esiteks, kirjutage struktureeritud logisid. Ärge lisage konteksti sõnumi tekstis. See raskendab nende grupeerimist ja analüüsi. Logstashil kulub palju aega, et kõik see normaliseerida.

Teiseks, kasutage õigesti severity-tasemeid. Igal keelel on oma standard. Isiklikult eristan nelja taset:

viga puudub;
viga kliendi poolel;
viga meie poolel, me ei kaota raha, ei kanna riske;
viga meie poolel, me kaotame raha.

Kokkuvõtteks. Tuleb püüda ehitada jälgimine just äriloogikast. Püüda jälgida ise rakendust ja opereerida juba selliste mõõdikutega nagu müük, uute kasutajate registreerimine, aktiivsete kasutajate arv ja nii edasi.

Kui teie kogu äri on üks nupp brauseris, tuleb jälgida, kas see nupp töötab, kas see toimib õigesti. Kõik muu ei ole oluline.

Kui teil seda pole, võite proovida seda tagantjärele leida rakenduse logides, Nginx logides ja nii edasi, nagu meie tegime. Te peate olema võimalikult lähedal rakendusele.

Operatsioonisüsteemi mõõdikud on muidugi olulised, kuid äri jaoks ei ole need huvitavad, me ei saa nende eest maksu.

Allikas: habr.com