Moje ime je Anton Baderin. Delam v Centru visoke tehnologije in se ukvarjam s sistemsko administracijo. Pred mesecem dni se je zaključila naša korporativna konferenca, na kateri smo svoje nabrane izkušnje delili z IT skupnostjo našega mesta. Govoril sem o spremljanju spletnih aplikacij. Gradivo je bilo namenjeno nižji ali srednji ravni, ki tega procesa niso gradili iz nič.
Temelj vsakega nadzornega sistema je reševanje poslovnih problemov. Spremljanje zaradi spremljanja ne zanima nikogar. Kaj hoče posel? Tako, da vse deluje hitro in brez napak. Podjetja želijo biti proaktivna, da sami prepoznamo težave v storitvi in jih čim hitreje odpravimo. To so pravzaprav problemi, ki sem jih celo lansko leto reševal na projektu za eno od naših strank.
O
Projekt je eden največjih programov zvestobe v državi. Trgovskim verigam pomagamo povečati frekvenco prodaje z različnimi marketinškimi orodji, kot so bonus kartice. Skupaj projekt vključuje 14 aplikacij, ki delujejo na desetih strežnikih.
Med postopkom razgovora sem večkrat opazil, da skrbniki ne pristopijo vedno k spremljanju spletnih aplikacij pravilno: mnogi se še vedno osredotočajo na meritve operacijskega sistema in občasno spremljajo storitve.
V mojem primeru je sistem za spremljanje stranke prej temeljil na Icingi. Zgornjih težav nikakor ni rešilo. Pogosto nas je stranka sama obvestila o težavah, velikokrat pa preprosto nismo imeli dovolj podatkov, da bi razlogu prišli do dna.
Poleg tega je obstajalo jasno razumevanje nesmiselnosti njegovega nadaljnjega razvoja. Mislim, da me bodo razumeli tisti, ki poznajo Icingo. Zato smo se odločili, da za projekt popolnoma prenovimo sistem za spremljanje spletnih aplikacij.
Prometej
Prometheus smo izbrali na podlagi treh glavnih kazalnikov:
- Ogromno število razpoložljivih meritev. V našem primeru jih je 60 tisoč. Seveda velja omeniti, da jih v veliki večini (verjetno okoli 95 %) ne uporabljamo. Po drugi strani pa so vsi razmeroma poceni. Za nas je to druga skrajnost v primerjavi s prej uporabljeno Icingo. Pri tem je bilo dodajanje metrik posebna težava: obstoječe so bile drage (samo poglejte izvorno kodo katerega koli vtičnika). Vsak vtičnik je bil skript v Bashu ali Pythonu, katerega zagon je drag glede na porabljene vire.
- Ta sistem porabi relativno malo virov. 600 MB RAM-a, 15% enega jedra in nekaj ducatov IOPS je dovolj za vse naše metrike. Seveda morate zagnati izvoznike metrik, vendar so vsi napisani v Go in tudi niso zelo požrešni. Mislim, da v sodobni realnosti to ni problem.
- Omogoča selitev na Kubernetes. Glede na načrte stranke je izbira očitna.
ELK
Prej nismo zbirali ali obdelovali dnevnikov. Pomanjkljivosti so vsem jasne. Za ELK smo se odločili, ker smo s tem sistemom že imeli izkušnje. Tam shranjujemo samo dnevnike aplikacij. Glavna merila za izbor sta bila iskanje po celotnem besedilu in njegova hitrost.
Slickhouse
Sprva je izbira padla na InfluxDB. Spoznali smo potrebo po zbiranju dnevnikov Nginx, statističnih podatkov iz pg_stat_statements in shranjevanju zgodovinskih podatkov Prometheus. Influx nam ni bil všeč, ker je občasno začel porabljati veliko pomnilnika in se zrušil. Poleg tega sem želel združiti poizvedbe glede na remote_addr, vendar je združevanje v tej DBMS samo po oznakah. Oznake so drage (pomnilnik), njihovo število je pogojno omejeno.
Ponovno smo začeli iskanje. Potrebna je bila analitična zbirka podatkov z minimalno porabo virov, po možnosti s stiskanjem podatkov na disku.
Clickhouse izpolnjuje vse te kriterije in naše izbire še nikoli nismo obžalovali. Vanj ne zapisujemo nobenih izjemnih količin podatkov (število vnosov je le okoli pet tisoč na minuto).
NewRelic
NewRelic je bil zgodovinsko z nami, ker je bila izbira stranke. Uporabljamo ga kot APM.
Zabbix
Zabbix uporabljamo izključno za spremljanje črne skrinjice različnih API-jev.
Opredelitev pristopa spremljanja
Nalogo smo želeli dekomponirati in s tem sistemizirati pristop k spremljanju.
Da bi to naredil, sem naš sistem razdelil na naslednje ravni:
- strojna oprema in VMS;
- operacijski sistem;
- sistemske storitve, sklad programske opreme;
- aplikacija;
- poslovna logika.
Zakaj je ta pristop primeren:
- vemo, kdo je odgovoren za delo posamezne ravni in na podlagi tega lahko pošiljamo opozorila;
- strukturo lahko uporabimo pri zatiranju opozoril - nenavadno bi bilo poslati opozorilo o nerazpoložljivosti baze podatkov, ko virtualni stroj kot celota ni na voljo.
Ker je naša naloga ugotavljanje kršitev v delovanju sistema, moramo na vsaki ravni izpostaviti določen nabor metrik, na katere je vredno biti pozoren pri pisanju pravil opozarjanja. Nato pojdimo skozi ravni »VMS«, »Operacijski sistem« in »Sistemske storitve, sklad programske opreme«.
Virtualni stroji
Gostovanje nam dodeli procesor, disk, pomnilnik in omrežje. In s prvima dvema smo imeli težave. Torej, meritve:
Ukradeni čas procesorja - ko kupite virtualni stroj na Amazonu (t2.micro, na primer), morate razumeti, da vam ni dodeljeno celotno jedro procesorja, ampak le kvota njegovega časa. In ko ga izčrpate, vam bo procesor odvzet.
Ta metrika vam omogoča sledenje takim trenutkom in sprejemanje odločitev. Na primer, ali je treba vzeti višjo tarifo ali porazdeliti obdelavo opravil v ozadju in zahtev API na različne strežnike?
IOPS + CPE iowait time – iz nekega razloga veliko gostovanj v oblaku greši, ker ne zagotavlja dovolj IOPS. Še več, urnik z nizkimi IOPS zanje ni argument. Zato je vredno zbrati CPU iowait. S tem parom grafov - z nizkimi IOPS in visokim I/O čakanjem - se že lahko pogovorite z gostovanjem in rešite težavo.
Operacijski sistem
Meritve operacijskega sistema:
- količina razpoložljivega pomnilnika v %;
- dejavnost uporabe zamenjave: vmstat swapin, swapout;
- število razpoložljivih inodov in prostega prostora v datotečnem sistemu v %
- povprečna obremenitev;
- število povezav v tw stanju;
- conntrack polnost mize;
- Kakovost omrežja lahko spremljate s pripomočkom ss, paketom iproute2 - pridobite indikator RTT povezav iz njegovega izhoda in ga združite po ciljnih vratih.
Tudi na ravni operacijskega sistema imamo tako entiteto, kot so procesi. Pomembno je, da v sistemu prepoznamo niz procesov, ki igrajo pomembno vlogo pri njegovem delovanju. Če imate na primer več pgpoolov, potem morate zbrati informacije za vsakega od njih.
Nabor meritev je naslednji:
- CPE;
- pomnilnik je predvsem rezidenčen;
- IO - po možnosti v IOPS;
- FileFd - odpri in omeji;
- pomembne napake strani - na ta način lahko razumete, kateri proces se zamenja.
Celotno spremljanje uporabljamo v Dockerju, za zbiranje metričnih podatkov pa uporabljamo svetovalca. Na drugih strojih uporabljamo procesni izvoznik.
Sistemske storitve, sklad programske opreme
Vsaka aplikacija ima svoje posebnosti in težko je izpostaviti določen nabor metrik.
Univerzalni komplet je:
- stopnja zahtevka;
- število napak;
- zakasnitev;
- nasičenost.
Naša najbolj osupljiva primera spremljanja na tej ravni sta Nginx in PostgreSQL.
Najbolj obremenjena storitev v našem sistemu je baza podatkov. V preteklosti smo pogosto imeli težave pri ugotavljanju, kaj baza podatkov počne.
Videli smo visoko obremenitev diskov, vendar počasni dnevniki niso pokazali ničesar. To težavo smo rešili s pg_stat_statements, pogledom, ki zbira statistiko poizvedb.
To je vse, kar potrebuje skrbnik.
Gradimo grafe dejavnosti zahtev za branje in pisanje:
Vse je preprosto in jasno, vsaka zahteva ima svojo barvo.
Enako osupljiv primer so dnevniki Nginx. Ni presenetljivo, da jih malokdo razčlenjuje ali omenja na seznamu stvari, ki jih morate imeti. Standardna oblika ni zelo informativna in jo je treba razširiti.
Osebno sem dodal request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Narišemo odzivni čas in število napak:
Gradimo grafe odzivnega časa in števila napak. Se spomniš? Sem govoril o poslovnih ciljih? Hitro in brez napak? Ta vprašanja smo že obravnavali z dvema grafikonoma. In z njimi lahko že pokličete dežurne skrbnike.
Ostaja pa še en problem - zagotoviti hitro odpravo vzrokov incidenta.
Rešitev incidenta
Celoten proces od prepoznavanja do rešitve problema lahko razdelimo na več korakov:
- prepoznavanje problema;
- obvestilo dežurnemu skrbniku;
- odziv na incident;
- odprava vzrokov.
Pomembno je, da to storimo čim hitreje. In če na stopnjah odkrivanja težave in pošiljanja obvestila ne moremo pridobiti veliko časa - v vsakem primeru bosta zanje porabili dve minuti, potem so naslednje preprosto nezoreno polje za izboljšave.
Predstavljajmo si samo, da je dežurnemu zazvonil telefon. Kaj bo naredil? Poiščite odgovore na vprašanja – kaj se je zalomilo, kje se je zalomilo, kako odreagirati? Tako odgovarjamo na ta vprašanja:
Vse te informacije preprosto vključimo v besedilo obvestila, mu damo povezavo do wiki strani, ki opisuje, kako se odzvati na to težavo, kako jo rešiti in stopnjevati.
Še vedno nisem rekel ničesar o aplikacijskem sloju in poslovni logiki. Naše aplikacije žal še ne izvajajo zbiranja metrik. Edini vir kakršnih koli informacij s teh ravni so dnevniki.
Nekaj točk.
Najprej napišite strukturirane dnevnike. V besedilo sporočila ni treba vključiti konteksta. Zaradi tega jih je težko združiti in analizirati. Logstash potrebuje veliko časa, da vse to normalizira.
Drugič, pravilno uporabite stopnje resnosti. Vsak jezik ima svoj standard. Osebno ločim štiri stopnje:
- brez napake;
- napaka na strani odjemalca;
- napaka je na naši strani, ne izgubljamo denarja, ne tvegamo;
- Napaka je na naši strani, izgubljamo denar.
Naj povzamem. Poskusiti morate zgraditi spremljanje, ki temelji na poslovni logiki. Poskusite spremljati samo aplikacijo in upravljajte z metrikami, kot so število prodaj, število registracij novih uporabnikov, število trenutno aktivnih uporabnikov itd.
Če je vaše celotno podjetje en gumb v brskalniku, morate spremljati, ali klikne in deluje pravilno. Vse ostalo ni pomembno.
Če tega nimate, ga lahko poskusite dohiteti v dnevnikih aplikacij, dnevnikih Nginx itd., kot smo storili mi. Morate biti čim bližje aplikaciji.
Meritve operacijskega sistema so seveda pomembne, a posla ne zanimajo, zanje nismo plačani.
Vir: www.habr.com