Mi nomiĝas Anton Baderin. Mi laboras en la Alta Teknologia Centro kaj faras sisteman administradon. Antaŭ unu monato finiĝis nia kompania konferenco, kie ni dividis nian akumulitan sperton kun la IT-komunumo de nia urbo. Mi parolis pri monitorado de TTT-aplikoj. La materialo estis destinita por juniora aŭ meza nivelo, kiuj ne konstruis ĉi tiun procezon de nulo.
La bazŝtono sub iu ajn monitora sistemo solvas komercajn problemojn. Monitorado pro monitorado ne interesas neniun. Kion volas komerco? Por ke ĉio funkcias rapide kaj sen eraroj. Komercoj volas esti aktivaj, por ke ni mem identigu problemojn en la servo kaj ripari ilin kiel eble plej rapide. Ĉi tiuj, fakte, estas la problemoj, kiujn mi solvis la tutan pasintjare en projekto por unu el niaj klientoj.
Pri la projekto
La projekto estas unu el la plej grandaj lojalecprogramoj en la lando. Ni helpas podetalaj ĉenoj pliigi la oftecon de vendo per diversaj merkataj iloj kiel bonuskartoj. Entute, la projekto inkluzivas 14 aplikojn, kiuj funkcias per dek serviloj.
Dum la intervjua procezo, mi plurfoje rimarkis, ke administrantoj ne ĉiam proksimiĝas ĝuste al monitorado de TTT-aplikoj: multaj ankoraŭ fokusiĝas al operaciumaj metrikoj kaj foje kontrolas servojn.
En mia kazo, la monitora sistemo de la kliento antaŭe baziĝis sur Icinga. Ĝi neniel solvis la suprajn problemojn. Ofte la kliento mem informis nin pri problemoj, kaj pli ofte, ni simple ne havis sufiĉajn datumojn por atingi la fundon de la kialo.
Krome, estis klara kompreno pri la vaneco de ĝia plua evoluo. Mi pensas, ke tiuj, kiuj konas Icinga, komprenos min. Do, ni decidis tute restrukturi la retan aplikaĵan monitoradsistemon por la projekto.
Prometeo
Ni elektis Prometheus surbaze de tri ĉefaj indikiloj:
- Grandega nombro da disponeblaj metrikoj. En nia kazo estas 60 mil da ili. Kompreneble, indas noti, ke ni ne uzas la vastan plimulton de ili (verŝajne ĉirkaŭ 95%). Aliflanke, ili ĉiuj estas relative malmultekostaj. Por ni, ĉi tiu estas la alia ekstremo kompare kun la antaŭe uzata Icinga. En ĝi, aldoni metrikojn estis aparta doloro: la ekzistantaj estis multekostaj (nur rigardu la fontkodon de iu ajn kromaĵo). Ajna kromaĵo estis skripto en Bash aŭ Python, kies lanĉo estas multekosta laŭ konsumitaj rimedoj.
- Ĉi tiu sistemo konsumas relative malgrandan kvanton da rimedoj. 600 MB da RAM, 15% de unu kerno kaj kelkaj dekduoj da IOPS sufiĉas por ĉiuj niaj metrikoj. Kompreneble, vi devas ruli metrik-eksportantojn, sed ili ĉiuj estas skribitaj en Go kaj ankaŭ ne tre potencas. Mi ne pensas, ke en modernaj realaĵoj tio estas problemo.
- Provizas la kapablon migri al Kubernetes. Konsiderante la planojn de la kliento, la elekto estas evidenta.
ELK
Antaŭe, ni ne kolektis aŭ prilaboris protokolojn. La mankoj estas klaraj al ĉiuj. Ni elektis ELK ĉar ni jam havis sperton pri ĉi tiu sistemo. Ni konservas nur aplikaĵregistrojn tie. La ĉefaj elektkriterioj estis plenteksta serĉo kaj ĝia rapideco.
Сlickhouse
Komence, la elekto falis sur InfluxDB. Ni rimarkis la bezonon kolekti Nginx-protokolojn, statistikojn de pg_stat_statements, kaj stoki Prometheus-historiajn datumojn. Ni ne ŝatis Influx ĉar ĝi periode komencis konsumi grandan kvanton da memoro kaj kraŝis. Krome, mi volis grupigi demandojn per remote_addr, sed grupigo en ĉi tiu DBMS estas nur per etikedoj. Etikedoj estas multekostaj (memoro), ilia nombro estas kondiĉe limigita.
Ni rekomencis nian serĉon. Kio estis bezonata estis analiza datumbazo kun minimuma rimedkonsumo, prefere kun datumkunpremado sur disko.
Clickhouse plenumas ĉiujn ĉi tiujn kriteriojn, kaj ni neniam bedaŭris nian elekton. Ni ne skribas en ĝi eksterordinarajn kvantojn da datumoj (la nombro da enmetoj estas nur ĉirkaŭ kvin mil por minuto).
NewRelic
NewRelic historie estis kun ni ĉar ĝi estis la elekto de la kliento. Ni uzas ĝin kiel APM.
Zabbikh
Ni uzas Zabbix ekskluzive por kontroli la Nigran Skatolo de diversaj API-oj.
Difinante Monitoran Aliron
Ni volis malkomponi la taskon kaj tiel sistemigi la aliron al monitorado.
Por fari tion, mi dividis nian sistemon en la jenajn nivelojn:
- aparataro kaj VMS;
- operaciumo;
- sistemaj servoj, programaro stako;
- aplikaĵo;
- komerca logiko.
Kial ĉi tiu aliro estas oportuna:
- ni scias, kiu respondecas pri la laboro de ĉiu nivelo kaj, surbaze de tio, ni povas sendi atentigojn;
- ni povas uzi la strukturon dum subpremado de atentigoj - estus strange sendi alarmon pri datumbaza malhavebleco kiam la virtuala maŝino entute estas nedisponebla.
Ĉar nia tasko estas identigi malobservojn en la funkciado de la sistemo, ni devas sur ĉiu nivelo reliefigi certan aron da metrikoj, pri kiuj indas atenti kiam vi verkas atentajn regulojn. Tuj poste, ni trairu la nivelojn "VMS", "Mastruma sistemo" kaj "Sistemaj servoj, programaro stako".
Virtualaj maŝinoj
Gastigado asignas al ni procesoron, diskon, memoron kaj reton. Kaj ni havis problemojn kun la unuaj du. Do, la metrikoj:
CPU ŝtelita tempo - kiam vi aĉetas virtualan maŝinon en Amazon (t2.micro, ekzemple), vi devus kompreni, ke vi ne estas asignita tutan procesoran kernon, sed nur kvoton de ĝia tempo. Kaj kiam vi elĉerpas ĝin, la procesoro estos forprenita de vi.
Ĉi tiu metriko permesas vin spuri tiajn momentojn kaj fari decidojn. Ekzemple, ĉu necesas preni pli grasan tarifon aŭ distribui la prilaboradon de fonaj taskoj kaj API-petoj al malsamaj serviloj?
IOPS + CPU iowaittempo - ial multaj nubaj gastigantoj pekas pro ne disponigante sufiĉe da IOPS. Plie, horaro kun malalta IOPS ne estas argumento por ili. Tial indas kolekti CPU iowait. Kun ĉi tiu paro da grafikaĵoj - kun malalta IOPS kaj alta I/O-atendo - vi jam povas paroli kun la gastiganto kaj solvi la problemon.
operaciumo
Mastrumaj sistemaj metrikoj:
- kvanto de disponebla memoro en %;
- interŝanĝa uzado-agado: vmstat swapin, swapout;
- nombro da disponeblaj inodoj kaj libera spaco en la dosiersistemo en %
- meza ŝarĝo;
- nombro da konektoj en tw stato;
- konttrack tablo pleneco;
- La kvalito de la reto povas esti monitorita per la ss-ilaĵo, la pakaĵo iproute2 - akiru indikilon de RTT-konektoj de ĝia eligo kaj grupigu ĝin per dest-haveno.
Ankaŭ ĉe la mastruma sistemo ni havas tian enton kiel procezoj. Gravas identigi en la sistemo aron da procezoj, kiuj ludas gravan rolon en ĝia funkciado. Se, ekzemple, vi havas plurajn pgpools, tiam vi devas kolekti informojn por ĉiu el ili.
La aro de metrikoj estas kiel sekvas:
- CPUoj;
- memoro estas ĉefe loĝanta;
- IO - prefere en IOPS;
- FileFd - malfermi kaj limigi;
- signifaj paĝaj misfunkciadoj - tiel vi povas kompreni kian procezon estas interŝanĝita.
Ni deplojas ĉiun monitoradon en Docker, kaj ni uzas Advisor por kolekti metrikajn datumojn. Sur aliaj maŝinoj ni uzas proces-eksportilon.
Sistemservoj, programaro stako
Ĉiu aplikaĵo havas siajn proprajn specifaĵojn, kaj estas malfacile distingi specifan aron de metrikoj.
La universala aro estas:
- peta indico;
- nombro da eraroj;
- latenteco;
- saturiĝo.
Niaj plej okulfrapaj ekzemploj de monitorado ĉe ĉi tiu nivelo estas Nginx kaj PostgreSQL.
La plej ŝarĝita servo en nia sistemo estas la datumbazo. En la pasinteco, ni ofte havis problemojn eltrovi, kion la datumbazo faras.
Ni vidis altan ŝarĝon sur la diskoj, sed la malrapidaj protokoloj vere montris nenion. Ni solvis ĉi tiun problemon per pg_stat_statements, vido kiu kolektas pridemandajn statistikojn.
Tio estas ĉio, kion la administranto bezonas.
Ni konstruas grafikaĵojn de la aktiveco de legi kaj skribi petojn:
Ĉio estas simpla kaj klara, ĉiu peto havas sian propran koloron.
Same okulfrapa ekzemplo estas Nginx-protokoloj. Ne estas surprize, ke malmultaj homoj analizas ilin aŭ mencias ilin en la listo de necesaĵoj. La norma formato ne estas tre informa kaj devas esti vastigita.
Persone, mi aldonis request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Ni grafikas respondtempon kaj nombron da eraroj:
Ni konstruas grafikaĵojn de responda tempo kaj nombro da eraroj. Ĉu vi memoras? Ĉu mi parolis pri komercaj celoj? Ĉu rapide kaj sen eraroj? Ni jam kovris ĉi tiujn aferojn per du leteroj. Kaj vi jam povas voki la deĵorantajn administrantojn uzante ilin.
Sed ankoraŭ unu problemo restas - certigi la rapidan forigon de la kaŭzoj de la okazaĵo.
Rezolucio de incidentoj
La tuta procezo de identigado ĝis solvado de problemo povas esti dividita en kelkajn paŝojn:
- identigi la problemon;
- sciigo al la devoadministranto;
- respondo al okazaĵo;
- forigo de kaŭzoj.
Gravas, ke ni devas fari tion kiel eble plej rapide. Kaj se en la stadioj de identigo de problemo kaj sendo de sciigo ni ne povas gajni multe da tempo - du minutoj estos elspezitaj por ili ĉiukaze, tiam la postaj estas simple neplugita kampo por plibonigoj.
Ni imagu nur, ke sonoris la telefono de la deĵoranto. Kion li faros? Serĉu respondojn al demandoj - kio rompiĝis, kie ĝi rompiĝis, kiel reagi? Jen kiel ni respondas ĉi tiujn demandojn:
Ni simple inkluzivas ĉiujn ĉi tiujn informojn en la teksto de la sciigo, kaj provizas ligilon al vikipaĝo, kiu priskribas kiel respondi al ĉi tiu problemo, kiel solvi ĝin kaj eskaladi ĝin.
Mi ankoraŭ nenion diris pri la aplika tavolo kaj komerca logiko. Bedaŭrinde, niaj aplikaĵoj ankoraŭ ne efektivigas kalkulkolekton. La sola fonto de ajna informo de ĉi tiuj niveloj estas protokoloj.
Paro da punktoj.
Unue, skribu strukturitajn protokolojn. Ne necesas inkluzivi kuntekston en la tekston de la mesaĝo. Ĉi tio malfaciligas ilin grupigi kaj analizi. Logstash bezonas longan tempon por normaligi ĉion ĉi.
Due, uzu severeco-nivelojn ĝuste. Ĉiu lingvo havas sian propran normon. Persone, mi distingas kvar nivelojn:
- neniu eraro;
- klienta flanko eraro;
- la eraro estas niaflanke, ni ne perdas monon, ni ne portas riskojn;
- La eraro estas niaflanke, ni perdas monon.
Lasu min resumi. Vi devas provi konstrui monitoradon bazitan sur komerca logiko. Provu kontroli la aplikaĵon mem kaj funkcii per tiaj metrikoj kiel la nombro da vendoj, la nombro da novaj uzantregistriĝoj, la nombro da nuntempe aktivaj uzantoj, ktp.
Se via tuta komerco estas unu butono en la retumilo, vi devas kontroli ĉu ĝi klakas kaj funkcias ĝuste. La tuta cetero ne gravas.
Se vi ne havas ĉi tion, vi povas provi atingi ĝin en protokoloj de aplikaĵoj, protokoloj de Nginx kaj tiel plu, kiel ni faris. Vi devus esti kiel eble plej proksime al la aplikaĵo.
La metriko de operaciumo estas kompreneble gravaj, sed komerco ne interesiĝas pri ili, ni ne estas pagataj por ili.
fonto: www.habr.com