🥇 Monitorizarea este moartă? — Trăiască monitorizare

Din 2008, compania noastră s-a angajat în principal în gestionarea infrastructurii și suport tehnic non-stop pentru proiecte web: avem peste 400 de clienți, ceea ce reprezintă aproximativ 15% din comerțul electronic rusesc. În consecință, este acceptată o arhitectură foarte diversă. Dacă ceva cade, suntem obligați să-l reparăm în 15 minute. Dar pentru a înțelege că a avut loc un accident, trebuie să monitorizați proiectul și să răspundeți la incidente. Cum să facă acest lucru?

Cred că există o problemă în organizarea unui sistem de monitorizare adecvat. Dacă nu ar fi fost probleme, atunci discursul meu ar consta într-o singură teză: „Vă rugăm să instalați Prometheus + Grafana și pluginurile 1, 2, 3”. Din păcate, nu mai funcționează așa. Iar principala problemă este că toată lumea continuă să creadă în ceva care exista în 2008, în ceea ce privește componentele software.

În ceea ce privește organizarea sistemului de monitorizare, m-aș aventura să spun că... proiecte cu monitorizare competentă nu există. Și situația este atât de rea încât, dacă ceva cade, există riscul ca acesta să treacă neobservat - la urma urmei, toată lumea este sigură că „totul este monitorizat”.
Poate că totul este monitorizat. Dar cum?

Cu toții am întâlnit o poveste ca următoarea: un anumit devop, un anumit administrator lucrează, o echipă de dezvoltare vine la ei și le spune - „suntem eliberați, acum monitorizează”. Monitorizează ce? Cum functioneaza?

BINE. Monitorizăm la modă veche. Și deja se schimbă și se dovedește că ați monitorizat serviciul A, care a devenit serviciul B, care interacționează cu serviciul C. Dar echipa de dezvoltare vă spune: „Instalați software-ul, ar trebui să monitorizeze totul!”

Deci ce s-a schimbat? - Totul s-a schimbat!

2008 Totul e bine

Există câțiva dezvoltatori, un server, un server de baze de date. Totul pleacă de aici. Avem câteva informații, instalăm zabbix, Nagios, cacti. Și apoi setăm alerte clare pe CPU, pe funcționarea discului și pe spațiul pe disc. De asemenea, facem câteva verificări manuale pentru a ne asigura că site-ul răspunde și că comenzile ajung în baza de date. Și gata – suntem mai mult sau mai puțin protejați.

Dacă comparăm cantitatea de muncă pe care administratorul a făcut-o atunci pentru a asigura monitorizarea, atunci 98% din aceasta a fost automată: persoana care face monitorizarea trebuie să înțeleagă cum să instaleze Zabbix, cum să-l configureze și să configureze alertele. Și 2% - pentru verificări externe: că site-ul răspunde și face o solicitare la baza de date, că au sosit comenzi noi.

2010 Încărcarea crește

Începem să extindem web-ul, adăugând un motor de căutare. Dorim să ne asigurăm că catalogul de produse conține toate produsele. Și căutarea de produse funcționează. Că baza de date funcționează, că se fac comenzi, că site-ul răspunde extern și răspunde de pe două servere și utilizatorul nu este dat afară din site în timp ce acesta este reechilibrat pe un alt server etc. Există mai multe entități.

Mai mult, entitatea asociată cu infrastructura rămâne în continuare cea mai mare în capul managerului. Mai am o idee în mintea mea că persoana care face monitorizarea este persoana care va instala zabbix și îl va putea configura.

Dar, în același timp, se lucrează la efectuarea de verificări externe, la crearea unui set de scripturi de interogare de indexare de căutare, un set de scripturi pentru a verifica dacă căutarea se modifică în timpul procesului de indexare, un set de scripturi care verifică dacă mărfurile sunt transferate în serviciu de livrare etc. și așa mai departe.

Notă: am scris „un set de scripturi” de 3 ori. Adică responsabilul cu monitorizarea nu mai este cel care instalează pur și simplu zabbix. Aceasta este o persoană care începe să codifice. Dar nimic nu s-a schimbat încă în mintea echipei.

Dar lumea se schimbă, devenind din ce în ce mai complexă. Se adaugă un strat de virtualizare și mai multe sisteme noi. Încep să interacționeze între ei. Cine a spus „miroase a microservicii?” Dar fiecare serviciu arată în continuare ca un site web individual. Putem apela la el și înțelege că oferă informațiile necesare și funcționează de la sine. Și dacă ești un administrator implicat constant într-un proiect care se dezvoltă de 5-7-10 ani, aceste cunoștințe se acumulează: apare un nou nivel - ti-ai dat seama, apare un alt nivel - ti-ai dat seama...

Dar rareori însoțește cineva un proiect timp de 10 ani.

CV-ul monitoringmanului

Să presupunem că ați venit la un nou startup care a angajat imediat 20 de dezvoltatori, a scris 15 microservicii și că sunteți un administrator căruia i se spune: „Build CI/CD. Vă rog." Ai construit CI/CD și dintr-o dată auzi: „Este dificil pentru noi să lucrăm cu producția într-un „cub”, fără să înțelegem cum va funcționa aplicația în el. Faceți-ne o cutie de nisip în același „cub”.
Faci o cutie de nisip în acest cub. Îți spun imediat: „Vrem o bază de date pe etape care să fie actualizată în fiecare zi din producție, astfel încât să înțelegem că funcționează pe baza de date, dar în același timp să nu strice baza de date de producție.”

Trăiești în toate acestea. Au mai rămas 2 săptămâni până la lansare, îți spun: „Acum hai să monitorizăm toate astea...” Adică. monitorizați infrastructura clusterului, monitorizați arhitectura microserviciilor, monitorizați lucrul cu servicii externe...

Iar colegii mei scot schema obișnuită din cap și spun: „Ei bine, aici totul este clar! Instalați un program care va monitoriza toate acestea.” Da, da: Prometheus + Grafana + pluginuri.
Și adaugă: „Ai două săptămâni, asigură-te că totul este în siguranță.”

În multe proiecte pe care le vedem, o persoană este alocată pentru monitorizare. Imaginați-vă că vrem să angajăm o persoană care să facă monitorizare timp de 2 săptămâni și îi scriem un CV. Ce aptitudini ar trebui să aibă această persoană, având în vedere tot ce am spus până acum?

El trebuie să înțeleagă monitorizarea și specificul funcționării infrastructurii fierului.
El trebuie să înțeleagă specificul monitorizării Kubernetes (și toată lumea vrea să meargă la „cub”, pentru că puteți abstra de la toate, vă puteți ascunde, pentru că administratorul se va ocupa de restul) - însuși, infrastructura sa și să înțeleagă cum să monitorizați aplicațiile interior.
El trebuie să înțeleagă că serviciile comunică între ele în moduri speciale și să cunoască particularitățile modului în care serviciile interacționează între ele. Este foarte posibil să vezi un proiect în care unele servicii comunică sincron, pentru că nu există altă cale. De exemplu, backend-ul merge prin REST, prin gRPC la serviciul de catalog, primește o listă de produse și o returnează înapoi. Abia așteptați aici. Și cu alte servicii funcționează asincron. Transferați comanda către serviciul de livrare, trimiteți o scrisoare etc.
Probabil că ai înotat deja din toate astea? Și administratorul, care trebuie să monitorizeze acest lucru, a devenit și mai confuz.
El trebuie să fie capabil să planifice și să planifice corect - pe măsură ce munca devine din ce în ce mai mare.
Prin urmare, el trebuie să creeze o strategie din serviciul creat pentru a înțelege cum să-l monitorizeze în mod specific. Are nevoie de o înțelegere a arhitecturii proiectului și a dezvoltării acestuia + o înțelegere a tehnologiilor utilizate în dezvoltare.

Să ne amintim un caz absolut normal: unele servicii sunt în PHP, unele servicii sunt în Go, unele servicii sunt în JS. Ei lucrează cumva unul cu celălalt. De aici provine termenul „microserviciu”: există atât de multe sisteme individuale încât dezvoltatorii nu pot înțelege proiectul ca întreg. O parte a echipei scrie servicii în JS care funcționează pe cont propriu și nu știu cum funcționează restul sistemului. Cealaltă parte scrie servicii în Python și nu interferează cu modul în care funcționează alte servicii; acestea sunt izolate în propria lor zonă. Al treilea este scrierea de servicii în PHP sau altceva.
Toate aceste 20 de persoane sunt împărțite în 15 servicii și există un singur admin care trebuie să înțeleagă toate acestea. Stop! Am împărțit sistemul în 15 microservicii, deoarece 20 de persoane nu pot înțelege întregul sistem.

Dar trebuie monitorizat cumva...

Care este rezultatul? Ca urmare, există o persoană care vine cu tot ceea ce întreaga echipă de dezvoltatori nu poate înțelege și, în același timp, trebuie să cunoască și să poată face ceea ce am indicat mai sus - infrastructura hardware, infrastructura Kubernetes etc.

Ce pot să spun... Houston, avem probleme.

Monitorizarea unui proiect software modern este un proiect software în sine

Din falsa credință că monitorizarea este software, dezvoltăm credința în miracole. Dar miracolele, vai, nu se întâmplă. Nu puteți instala zabbix și vă așteptați ca totul să funcționeze. Nu are rost sa instalezi Grafana si sa speri ca totul va fi ok. Cea mai mare parte a timpului va fi alocat organizării de verificări ale funcționării serviciilor și interacțiunii acestora între ele, verificând modul în care funcționează sistemele externe. De fapt, 90% din timp va fi cheltuit nu pentru scrierea de scripturi, ci pentru dezvoltarea de software. Și ar trebui să fie gestionat de o echipă care înțelege activitatea proiectului.
Dacă în această situație o persoană este aruncată în monitorizare, atunci se va întâmpla un dezastru. Ceea ce se întâmplă peste tot.

De exemplu, există mai multe servicii care comunică între ele prin Kafka. Comanda a sosit, am trimis un mesaj despre comanda lui Kafka. Există un serviciu care ascultă informații despre comandă și expediază mărfurile. Există un serviciu care ascultă informații despre comandă și trimite o scrisoare utilizatorului. Și apoi mai apar o grămadă de servicii și începem să fim confuzi.

Și dacă oferiți acest lucru și administratorului și dezvoltatorilor în stadiul în care mai este puțin timp înainte de lansare, persoana va trebui să înțeleagă întreg acest protocol. Acestea. Un proiect de această amploare necesită o perioadă semnificativă de timp, iar acest lucru ar trebui luat în considerare în dezvoltarea sistemului.
Dar de foarte multe ori, mai ales la startup-uri, vedem cum monitorizarea este amânată pentru mai târziu. „Acum vom face o Proof of Concept, ne vom lansa cu ea, o lăsăm să cadă - suntem gata să ne sacrificăm. Și apoi vom monitoriza totul.” Când (sau dacă) proiectul începe să facă bani, afacerea dorește să adauge și mai multe funcții - pentru că a început să funcționeze, așa că trebuie să fie lansat în continuare! Și ești în punctul în care trebuie mai întâi să monitorizezi tot ce este anterior, ceea ce ia nu 1% din timp, ci mult mai mult. Și apropo, dezvoltatorii vor fi necesari pentru monitorizare și este mai ușor să-i lași să lucreze la noi funcții. Drept urmare, sunt scrise noi funcții, totul se încurcă și vă aflați într-un impas nesfârșit.

Deci, cum să monitorizezi un proiect de la început și ce să faci dacă primești un proiect care trebuie monitorizat, dar nu știi de unde să începi?

În primul rând, trebuie să planificați.

Digresiune lirică: de foarte multe ori încep cu monitorizarea infrastructurii. De exemplu, avem Kubernetes. Să începem prin a instala Prometheus cu Grafana, instalând plugin-uri pentru monitorizarea „cubului”. Nu numai dezvoltatorii, ci și administratorii au practica nefericită de a: „Vom instala acest plugin, dar pluginul probabil știe cum să o facă.” Oamenilor le place să înceapă cu acțiunile simple și directe, mai degrabă decât cu acțiunile importante. Și monitorizarea infrastructurii este ușoară.

Mai întâi, decideți ce și cum doriți să monitorizați, apoi selectați un instrument, deoarece alți oameni nu pot gândi pentru dvs. Și ar trebui? Alți oameni s-au gândit la un sistem universal - sau nu s-au gândit deloc când a fost scris acest plugin. Și doar pentru că acest plugin are 5 mii de utilizatori nu înseamnă că este de vreun folos. Poate vei deveni al 5001-lea pur și simplu pentru că erau deja 5000 de oameni înainte.

Dacă începeți să monitorizați infrastructura și backend-ul aplicației dvs. nu mai răspunde, toți utilizatorii vor pierde conexiunea cu aplicația mobilă. Va apărea o eroare. Vor veni la tine și vor spune „Aplicația nu funcționează, ce cauți aici?” - „Suspectăm.” — „Cum monitorizezi dacă nu vezi că aplicația nu funcționează?!”

Cred că trebuie să începeți monitorizarea exact din punctul de intrare al utilizatorului. Dacă utilizatorul nu vede că aplicația funcționează, asta este, este un eșec. Iar sistemul de monitorizare ar trebui să avertizeze mai întâi despre acest lucru.
Și abia atunci putem monitoriza infrastructura. Sau fă-o în paralel. Este mai ușor cu infrastructura - aici putem instala în sfârșit zabbix.
Și acum trebuie să mergeți la rădăcinile aplicației pentru a înțelege unde lucrurile nu funcționează.

Ideea mea principală este că monitorizarea ar trebui să meargă în paralel cu procesul de dezvoltare. Dacă distrageți atenția echipei de monitorizare pentru alte sarcini (crearea CI/CD, sandboxing, reorganizarea infrastructurii), monitorizarea va începe să întârzie și este posibil să nu ajungeți niciodată din urmă cu dezvoltarea (sau mai devreme sau mai târziu va trebui să o opriți).

Totul pe niveluri

Așa văd eu organizarea unui sistem de monitorizare.

1) Nivel de aplicare:

monitorizarea logicii afacerii aplicației;
monitorizarea parametrilor de sănătate a serviciilor;
monitorizarea integrării.

2) Nivelul infrastructurii:

monitorizarea nivelului de orchestrație;
monitorizare software de sistem;
monitorizarea nivelului de fier.

3) Din nou la nivelul aplicației - dar ca produs de inginerie:

colectarea și monitorizarea jurnalelor aplicațiilor;
APM;
trasarea.

4) Avertizare:

organizarea unui sistem de avertizare;
organizarea unui sistem de taxe;
organizarea unei „baze de cunoștințe” și a fluxului de lucru pentru procesarea incidentelor.

Este important: ajungem in alerta nu dupa, ci imediat! Nu este nevoie să lansați monitorizarea și „cumva mai târziu” să aflați cine va primi alerte. La urma urmei, care este sarcina monitorizării: să înțelegem unde în sistem ceva nu funcționează greșit și să anunți oamenii potriviti despre asta. Dacă lăsați asta până la sfârșit, atunci oamenii potriviți vor ști că ceva nu merge bine doar spunând „nimic nu funcționează pentru noi”.

Strat de aplicație - Monitorizarea logicii de afaceri

Aici vorbim despre verificarea faptului că aplicația funcționează pentru utilizator.

Acest nivel ar trebui făcut în timpul fazei de dezvoltare. De exemplu, avem un Prometheus condiționat: merge la serverul care face verificările, trage punctul final, iar punctul final merge și verifică API-ul.

Când li se cere adesea să monitorizeze pagina de pornire pentru a se asigura că site-ul funcționează, programatorii oferă un mâner care poate fi tras de fiecare dată când au nevoie pentru a se asigura că API-ul funcționează. Și programatorii în acest moment încă iau și scriu /api/test/helloworld
Singura modalitate de a vă asigura că totul funcționează? - Nu!

Crearea unor astfel de verificări este în esență sarcina dezvoltatorilor. Testele unitare ar trebui să fie scrise de programatorii care scriu codul. Pentru că, dacă îl transmiteți administratorului, „Omule, iată o listă de protocoale API pentru toate cele 25 de funcții, vă rugăm să monitorizați totul!” - nimic nu va merge.
Dacă imprimați „hello world”, nimeni nu va ști vreodată că API-ul ar trebui să funcționeze. Fiecare modificare a API-ului trebuie să ducă la o modificare a verificărilor.
Dacă aveți deja o astfel de problemă, opriți funcțiile și alocați dezvoltatori care vor scrie aceste verificări sau accepta pierderile, acceptați că nimic nu este verificat și va eșua.

Sfaturi tehnice:

Asigurați-vă că organizați un server extern pentru a organiza verificările - trebuie să vă asigurați că proiectul dvs. este accesibil lumii exterioare.
Organizați verificări în întregul protocol API, nu doar puncte finale individuale.
Creați un punct final prometheus cu rezultatele testului.

Stratul de aplicație - monitorizarea valorilor de sănătate

Acum vorbim despre valorile externe de sănătate ale serviciilor.

Am decis să monitorizăm toate „mânerele” aplicației folosind verificări externe, pe care le apelăm dintr-un sistem de monitorizare extern. Dar acestea sunt „mânerele” pe care utilizatorul „le vede”. Vrem să fim siguri că serviciile noastre în sine funcționează. Există o poveste mai bună aici: K8s are verificări de sănătate, astfel încât cel puțin „cubul” însuși poate fi convins că serviciul funcționează. Dar jumătate din cecurile pe care le-am văzut sunt aceeași tipărire „bună lume”. Acestea. Așa că trage o dată după desfășurare, a răspuns că totul este în regulă - asta-i tot. Și serviciul, dacă oferă propriul API, are un număr mare de puncte de intrare pentru același API, care trebuie de asemenea monitorizat, pentru că vrem să știm că funcționează. Și deja îl monitorizăm în interior.

Cum să implementați acest lucru corect din punct de vedere tehnic: fiecare serviciu expune un punct final despre performanța sa actuală, iar în graficele Grafana (sau orice altă aplicație) vedem starea tuturor serviciilor.

Fiecare modificare a API-ului trebuie să ducă la o modificare a verificărilor.
Creați imediat un nou serviciu cu valori de sănătate.
Un administrator poate veni la dezvoltatori și poate cere „adăugați-mi câteva funcții, astfel încât să înțeleg totul și să adaug informații despre acest lucru în sistemul meu de monitorizare”. Dar dezvoltatorii răspund de obicei: „Nu vom adăuga nimic cu două săptămâni înainte de lansare”.
Să știe managerii de dezvoltare că vor exista astfel de pierderi, să știe și conducerea managerilor de dezvoltare. Pentru că atunci când totul cade, cineva va suna în continuare și va cere să monitorizeze „serviciul în scădere constantă” (c)
Apropo, alocați dezvoltatorilor să scrie pluginuri pentru Grafana - acesta va fi un bun ajutor pentru administratori.

Strat de aplicație - Monitorizarea integrării

Monitorizarea integrării se concentrează pe monitorizarea comunicațiilor între sistemele critice pentru afaceri.

De exemplu, există 15 servicii care comunică între ele. Acestea nu mai sunt site-uri separate. Acestea. nu putem extrage serviciul pe cont propriu, să obținem /helloworld și să înțelegem că serviciul rulează. Deoarece serviciul web de comandă trebuie să trimită informații despre comandă către autobuz - din autobuz, serviciul de depozit trebuie să primească acest mesaj și să lucreze cu el în continuare. Și serviciul de distribuție de e-mail trebuie să prelucreze acest lucru cumva mai departe etc.

În consecință, nu putem înțelege, analizând fiecare serviciu individual, că totul funcționează. Pentru că avem un anumit autobuz prin care totul comunică și interacționează.
Prin urmare, această etapă ar trebui să marcheze etapa de testare a serviciilor pentru interacțiunea cu alte servicii. Este imposibil să se organizeze monitorizarea comunicării prin monitorizarea brokerului de mesaje. Dacă există un serviciu care emite date și un serviciu care le primește, atunci când monitorizăm brokerul vom vedea doar date care zboară dintr-o parte în alta. Chiar dacă am reușit cumva să monitorizăm interacțiunea acestor date în interior - că un anumit producător postează datele, cineva le citește, acest flux continuă să meargă către Kafka - acest lucru tot nu ne va oferi informații dacă un serviciu a trimis mesajul într-o singură versiune , dar celălalt serviciu nu se aștepta la această versiune și a omis-o. Nu vom ști despre asta, deoarece serviciile ne vor spune că totul funcționează.

Ce recomand sa faci:

Pentru comunicarea sincronă: punctul final face cereri către serviciile conexe. Acestea. luăm acest punct final, tragem un script în interiorul serviciului, care merge la toate punctele și spune „Pot trage acolo și trage acolo, pot trage acolo...”
Pentru comunicarea asincronă: mesaje primite - punctul final verifică magistrala pentru mesaje de testare și afișează starea procesării.
Pentru comunicarea asincronă: mesaje de ieșire - punctul final trimite mesaje de testare către magistrală.

După cum se întâmplă de obicei: avem un serviciu care aruncă date în autobuz. Venim la acest serviciu și vă rugăm să ne spuneți despre starea sa de integrare. Și dacă serviciul trebuie să producă un mesaj undeva mai departe (WebApp), atunci va produce acest mesaj de testare. Și dacă rulăm un serviciu pe partea de procesare a comenzilor, mai întâi postează ceea ce poate posta independent, iar dacă există unele lucruri dependente, atunci citește un set de mesaje de testare din autobuz, înțelege că le poate procesa, raporta și , daca e nevoie, posteaza-le mai departe, iar despre asta zice - totul e ok, sunt in viata.

Foarte des auzim întrebarea „cum putem testa asta pe datele de luptă?” De exemplu, vorbim despre același serviciu de comandă. Comanda trimite mesaje către depozitul în care mărfurile sunt anulate: nu putem testa acest lucru pe datele de luptă, deoarece „bunurile mele vor fi anulate!” Soluție: planificați întregul test de la început. Aveți și teste unitare care fac batjocuri. Așadar, fă-o la un nivel mai profund unde ai un canal de comunicare care nu dăunează funcționării afacerii.

Stratul de infrastructură

Monitorizarea infrastructurii este ceva care a fost mult timp considerat monitorizarea în sine.

Monitorizarea infrastructurii poate și ar trebui să fie lansată ca un proces separat.
Nu ar trebui să începeți cu monitorizarea infrastructurii pe un proiect în derulare, chiar dacă doriți cu adevărat. Aceasta este o durere pentru toți devopții. „Mai întâi voi monitoriza clusterul, voi monitoriza infrastructura” – adică. În primul rând, va monitoriza ceea ce se află mai jos, dar nu va intra în aplicație. Pentru că aplicația este un lucru de neînțeles pentru devopi. I s-a scurs și nu înțelege cum funcționează. Dar înțelege infrastructura și începe cu ea. Dar nu - trebuie întotdeauna să monitorizați aplicația mai întâi.
Nu exagerați cu numărul de alerte. Având în vedere complexitatea sistemelor moderne, alertele zboară în mod constant și trebuie să trăiești cumva cu această grămadă de alerte. Iar persoana de gardă, după ce a analizat o sută de alerte următoare, va decide „Nu vreau să mă gândesc la asta”. Alertele ar trebui să notifice numai despre lucruri critice.

Nivel de aplicație ca unitate de afaceri

Puncte cheie:

ELAN. Acesta este standardul industriei. Dacă dintr-un motiv oarecare nu acumulați jurnalele, începeți imediat să faceți acest lucru.
APM. APM-uri externe ca o modalitate de a închide rapid monitorizarea aplicațiilor (NewRelic, BlackFire, Datadog). Puteți instala acest lucru temporar pentru a înțelege cel puțin cumva ce se întâmplă cu dvs.
Urmărirea. În zeci de microservicii, trebuie să urmăriți totul, pentru că cererea nu mai trăiește de la sine. Este foarte dificil să adăugați mai târziu, așa că este mai bine să programați imediat urmărirea în dezvoltare - aceasta este munca și utilitatea dezvoltatorilor. Dacă nu l-ați implementat încă, implementați-l! Vezi Jaeger/Zipkin

Alertarea

Organizarea unui sistem de notificare: în condițiile de monitorizare a o grămadă de lucruri, ar trebui să existe un sistem unificat de trimitere a notificărilor. Poți în Grafana. În Occident, toată lumea folosește PagerDuty. Alertele ar trebui să fie clare (de exemplu, de unde provin...). Și este recomandabil să controlați că notificările sunt primite
Organizarea unui sistem de serviciu: alertele nu trebuie trimise tuturor (fie toată lumea va reacționa în mulțime, fie nimeni nu va reacționa). Dezvoltatorii trebuie, de asemenea, să fie on-call: asigurați-vă că definiți zonele de responsabilitate, faceți instrucțiuni clare și scrieți în el pe cine să sune exact luni și miercuri și pe cine să sune marți și vineri (altfel nu vor suna pe nimeni nici măcar în evenimentul unei probleme mari - le va fi frică să te trezească sau să deranjeze: oamenilor, în general, nu le place să sune și să trezească alte persoane, mai ales noaptea). Și explicați că a cere ajutor nu este un indicator al incompetenței („Cer ajutor, asta înseamnă că sunt un lucrător prost”), încurajați cererile de ajutor.
Organizarea unei „baze de cunoștințe” și a fluxului de lucru pentru procesarea incidentului: pentru fiecare incident grav trebuie planificat o autopsie și, ca măsură temporară, trebuie înregistrate acțiunile care vor rezolva incidentul. Și fă o practică că alertele repetate sunt un păcat; acestea trebuie să fie fixate în cod sau lucrări de infrastructură.

Stiva de tehnologie

Să ne imaginăm că stiva noastră este după cum urmează:

colectarea datelor - Prometheus + Grafana;
analiza log - ELK;
pentru APM sau Tracing - Jaeger (Zipkin).

Alegerea opțiunilor nu este critică. Pentru că dacă la început ați înțeles cum să monitorizați sistemul și ați notat un plan, atunci începeți să alegeți instrumentele care să corespundă cerințelor dumneavoastră. Întrebarea este ce ați ales să monitorizați în primul rând. Pentru că poate instrumentul pe care l-ai ales la început nu se potrivește deloc cerințelor tale.

Câteva puncte tehnice pe care le văd peste tot în ultima vreme:

Prometheus este împins în interiorul Kubernetes - cine a venit cu asta?! Dacă clusterul tău se prăbușește, ce vei face? Dacă aveți un cluster complex în interior, atunci ar trebui să existe un fel de sistem de monitorizare în interiorul clusterului și unul în exterior, care va colecta date din interiorul clusterului.

În interiorul clusterului colectăm jurnalele și orice altceva. Dar sistemul de monitorizare trebuie să fie afară. Foarte des, într-un cluster în care există Promtheus instalat intern, există și sisteme care efectuează verificări externe ale funcționării site-ului. Ce se întâmplă dacă conexiunile tale cu lumea exterioară s-au oprit și aplicația nu funcționează? Se dovedește că totul este bine în interior, dar nu ușurează lucrurile pentru utilizatori.

Constatări

Monitorizarea dezvoltării nu este instalarea de utilități, ci dezvoltarea unui produs software. 98% din monitorizarea actuală este codificare. Codarea serviciilor, codarea controalelor externe, verificarea serviciilor externe și atât.
Nu pierde timpul dezvoltatorilor tăi cu monitorizarea: poate dura până la 30% din munca lor, dar merită.
Devops, nu vă faceți griji că nu puteți monitoriza ceva, pentru că unele lucruri sunt un mod complet diferit de a gândi. Nu ai fost programator, iar monitorizarea muncii este exact treaba lor.
Dacă proiectul rulează deja și nu este monitorizat (și sunteți manager), alocați resurse pentru monitorizare.
Dacă produsul este deja în producție și sunteți un devop căruia i s-a spus să „configureze monitorizarea” - încercați să explicați conducerii despre ce am scris toate acestea.

Aceasta este o versiune extinsă a raportului la conferința Saint Highload++.

Dacă sunteți interesat de ideile și gândurile mele despre el și subiectele conexe, atunci puteți aici citeste canalul ????

Sursa: www.habr.com

Monitorizarea este moartă? — Trăiască monitorizare