Je li monitoring mrtav? — Živjelo praćenje

Od 2008. godine naša kompanija se prvenstveno bavi upravljanjem infrastrukturom i tehničkom podrškom za web projekte 400 sata dnevno: imamo više od 15 klijenata, što je oko 15% ruske e-trgovine. U skladu s tim, podržana je vrlo raznolika arhitektura. Ako nešto padne, dužni smo to popraviti u roku od XNUMX minuta. Ali da biste shvatili da je došlo do nesreće, morate pratiti projekat i reagovati na incidente. Kako to učiniti?

Smatram da postoji problem u organizovanju odgovarajućeg sistema monitoringa. Da nije bilo problema, moj govor bi se sastojao od jedne teze: “Molim vas instalirajte Prometheus + Grafana i dodatke 1, 2, 3.” Nažalost, to više ne funkcioniše tako. A glavni problem je što svi i dalje vjeruju u nešto što je postojalo 2008. godine, u smislu softverskih komponenti.

Što se tiče organizacije sistema monitoringa, usudio bih se reći da... projekti sa kompetentnim monitoringom ne postoje. A situacija je toliko loša da ako nešto padne, postoji rizik da to prođe nezapaženo - uostalom, svi su sigurni da se "sve prati".
Možda se sve prati. Ali kako?

Svi smo se susreli sa ovakvom pričom: određeni devops, određeni admin radi, dođe im razvojni tim i kaže – „pušteni smo, sada prati“. Pratiti šta? Kako radi?

UREDU. Pratimo starinski način. I to se već mijenja, i ispostavilo se da ste nadgledali servis A, koji je postao servis B, koji je u interakciji sa uslugom C. Ali razvojni tim vam kaže: „Instalirajte softver, on bi trebao sve pratiti!“

Dakle, šta se promijenilo? - Sve se promijenilo!

2008 Sve je uredu

Postoji nekoliko programera, jedan server, jedan server baze podataka. Sve ide odavde. Imamo neke informacije, instaliramo zabbix, Nagios, cacti. Zatim postavljamo jasna upozorenja na CPU, na rad diska i na prostor na disku. Također radimo nekoliko ručnih provjera kako bismo bili sigurni da stranica odgovara i da narudžbe stižu u bazu podataka. I to je to - manje-više smo zaštićeni.

Ako uporedimo količinu posla koji je administrator tada uradio da obezbedi nadgledanje, onda je 98% toga bilo automatski: osoba koja vrši nadzor mora da razume kako da instalira Zabbix, kako da ga konfiguriše i konfiguriše upozorenja. I 2% - za eksterne provjere: da stranica odgovara i postavlja zahtjev bazi podataka, da su stigle nove narudžbe.

2010 Opterećenje raste

Počinjemo širiti web, dodajući tražilicu. Želimo biti sigurni da katalog proizvoda sadrži sve proizvode. I ta pretraga proizvoda funkcionira. Da baza podataka radi, da se prave nalozi, da sajt odgovara eksterno i odgovara sa dva servera i da korisnik nije izbačen sa sajta dok je rebalansiran na drugi server itd. Postoji više entiteta.

Štaviše, entitet povezan sa infrastrukturom i dalje ostaje najveći u glavi menadžera. Još uvijek imam ideju u glavi da je osoba koja vrši nadzor osoba koja će instalirati zabbix i moći ga konfigurirati.

Ali istovremeno se pojavljuje rad na provođenju eksternih provjera, na kreiranju skupa skripti upita za indeksiranje pretraživanja, skupa skripti za provjeru da li se pretraga mijenja tokom procesa indeksiranja, skupa skripti koje provjeravaju da li se roba prenosi na usluga dostave itd. i tako dalje.

Napomena: Napisao sam "skup skripti" 3 puta. Odnosno, osoba odgovorna za praćenje više nije ona koja jednostavno instalira zabbix. Ovo je osoba koja počinje kodirati. Ali ništa se još nije promijenilo u glavama tima.

Ali svijet se mijenja, postaje sve složeniji. Dodan je sloj virtuelizacije i nekoliko novih sistema. Počinju da komuniciraju jedni s drugima. Ko je rekao "miriše na mikroservise?" Ali svaka usluga i dalje izgleda kao web stranica zasebno. Možemo mu se obratiti i shvatiti da pruža potrebne informacije i radi samostalno. A ako ste administrator stalno uključen u projekat koji se razvija 5-7-10 godina, ovo znanje se akumulira: pojavljuje se novi nivo - shvatili ste, pojavljuje se drugi nivo - shvatili ste...

Ali rijetko ko prati projekat 10 godina.

Životopis nadzornika

Pretpostavimo da ste došli u novi startup koji je odmah unajmio 20 programera, napisao 15 mikroservisa, a vi ste administrator kojem je rečeno: “Napravi CI/CD. Molim te." Napravili ste CI/CD i odjednom čujete: „Teško nam je raditi s produkcijom u „kocki“, a da ne razumijemo kako će aplikacija raditi u njoj. Napravite od nas sandbox u istoj "kocki".
U ovoj kocki napravite sandbox. Oni vam odmah kažu: „Želimo scensku bazu podataka koja se ažurira svaki dan iz produkcije, kako bismo shvatili da radi na bazi podataka, ali da u isto vrijeme ne kvarimo produkcijsku bazu podataka."

Živiš u svemu ovome. Ostalo je još 2 sedmice do izlaska, kažu vam: “Ajde sad sve ovo pratimo...” tj. prati infrastrukturu klastera, prati mikroservisnu arhitekturu, prati rad sa eksternim servisima...

A moje kolege izbiju iz glave uobičajenu šemu i kažu: „E, tu je sve jasno! Instalirajte program koji će sve ovo pratiti.” Da, da: Prometheus + Grafana + dodaci.
I dodaju: "Imate dvije sedmice, provjerite je li sve sigurno."

U dosta projekata koje vidimo, jedna osoba je određena za praćenje. Zamislite da želimo da zaposlimo osobu koja će vršiti monitoring na 2 nedelje, i da za nju napišemo životopis. Koje vještine bi ova osoba trebala imati, s obzirom na sve što smo do sada rekli?

• On mora razumjeti praćenje i specifičnosti rada željezne infrastrukture.
• On mora razumjeti specifičnosti nadgledanja Kubernetesa (a svi žele ići na „kocku“, jer možete apstrahirati od svega, sakriti se, jer će se administrator pozabaviti ostalim) - sebe, njegovu infrastrukturu i razumjeti kako pratiti aplikacije unutra.
• On mora razumjeti da službe međusobno komuniciraju na posebne načine i znati specifičnosti načina na koji usluge međusobno komuniciraju. Sasvim je moguće vidjeti projekat u kojem neki servisi komuniciraju sinhrono, jer drugog načina nema. Na primjer, backend ide preko REST-a, preko gRPC-a do servisa kataloga, prima listu proizvoda i vraća je nazad. Ne možete čekati ovdje. A sa ostalim servisima radi asinhrono. Prenesite narudžbu u dostavu, pošaljite pismo itd.
  Verovatno ste već plivali od svega ovoga? A administrator, koji to treba da prati, postao je još više zbunjen.
• Mora biti sposoban da planira i planira ispravno – kako posla postaje sve više i više.
• Stoga mora kreirati strategiju od kreirane usluge kako bi razumio kako da je posebno prati. Potrebno mu je razumijevanje arhitekture projekta i njegovog razvoja + razumijevanje tehnologija koje se koriste u razvoju.

Prisjetimo se jednog sasvim normalnog slučaja: neki servisi su u PHP-u, neki servisi su u Go-u, neki servisi su u JS-u. Oni nekako rade jedno s drugim. Odatle dolazi pojam „mikroservis”: postoji toliko mnogo pojedinačnih sistema da programeri ne mogu razumjeti projekat u cjelini. Jedan dio tima piše servise na JS-u koji rade sami i ne znaju kako funkcionira ostatak sistema. Drugi dio piše servise na Python-u i ne ometa se u radu drugih servisa; oni su izolirani u svom području. Treći je pisanje servisa u PHP-u ili nečem drugom.
Svih ovih 20 ljudi je podijeljeno u 15 servisa, a postoji samo jedan admin koji sve ovo mora razumjeti. Stani! samo smo podijelili sistem na 15 mikroservisa jer 20 ljudi ne može razumjeti cijeli sistem.

Ali to treba nekako pratiti...

šta je rezultat? Kao rezultat toga, postoji jedna osoba koja smisli sve ono što cijeli tim programera ne može razumjeti, a u isto vrijeme mora znati i biti sposoban da radi ono što smo gore naveli - hardversku infrastrukturu, Kubernetes infrastrukturu itd.

Šta da kažem... Hjuston, imamo problema.

Praćenje modernog softverskog projekta je sam po sebi softverski projekat

Iz lažnog uvjerenja da je nadzor softver, razvijamo vjerovanje u čuda. Ali čuda se, nažalost, ne dešavaju. Ne možete instalirati zabbix i očekivati ​​da sve radi. Nema smisla instalirati Grafanu i nadati se da će sve biti ok. Najviše vremena će biti utrošeno na organizovanje provjera rada servisa i njihove međusobne interakcije, provjeravanje kako eksterni sistemi rade. Zapravo, 90% vremena neće biti utrošeno na pisanje skripti, već na razvoj softvera. I njime bi se trebao baviti tim koji razumije rad projekta.
Ako u ovoj situaciji jedna osoba bude bačena u nadzor, onda će se dogoditi katastrofa. Što se dešava svuda.

Na primjer, postoji nekoliko servisa koji međusobno komuniciraju putem Kafke. Narudžba je stigla, poslali smo poruku o narudžbi Kafki. Postoji servis koji sluša informacije o narudžbi i šalje robu. Postoji servis koji sluša informacije o narudžbi i šalje pismo korisniku. A onda se pojavi još gomila usluga i počinjemo se zbuniti.

A ako i ovo date administratoru i programerima u fazi kada je preostalo malo vremena do objavljivanja, osoba će morati razumjeti cijeli ovaj protokol. One. Projekat ovakvog obima oduzima dosta vremena i to treba uzeti u obzir u razvoju sistema.
Ali vrlo često, posebno u startupima, vidimo kako se praćenje odgađa za kasnije. “Sada ćemo napraviti Proof of Concept, krenut ćemo s njim, neka padne – spremni smo na žrtvu. A onda ćemo sve to pratiti.” Kada (ili ako) projekat počne da zarađuje, preduzeće želi da doda još više funkcija – jer je počelo da radi, pa ga treba dalje razvijati! I nalazite se na tački kada prvo trebate pratiti sve prethodno, što ne oduzima 1% vremena, već mnogo više. Usput, programeri će biti potrebni za praćenje i lakše ih je pustiti da rade na novim funkcijama. Kao rezultat, nove funkcije su napisane, sve se zezne, a vi ste u beskrajnoj mrtvoj tački.

Dakle, kako pratiti projekat počevši od početka i šta učiniti ako dobijete projekat koji treba pratiti, ali ne znate odakle da počnete?

Prvo, morate planirati.

Lirska digresija: vrlo često počinju praćenjem infrastrukture. Na primjer, imamo Kubernetes. Počnimo sa instalacijom Prometheusa sa Grafanom, instaliranjem dodataka za praćenje “kocke”. Ne samo programeri, već i administratori imaju nesretnu praksu: "Instaliraćemo ovaj dodatak, ali dodatak vjerovatno zna kako to učiniti." Ljudi vole da počnu sa jednostavnim i jednostavnim, a ne sa važnim radnjama. A praćenje infrastrukture je jednostavno.

Prvo odlučite šta i kako želite pratiti, a zatim odaberite alat, jer drugi ljudi ne mogu razmišljati umjesto vas. A da li bi trebali? Drugi ljudi su mislili u sebi, o univerzalnom sistemu - ili uopšte nisu razmišljali kada je ovaj dodatak napisan. A to što ovaj dodatak ima 5 hiljada korisnika ne znači da je od koristi. Možda ćete postati 5001. jednostavno zato što je tamo prije bilo 5000 ljudi.

Ako počnete nadgledati infrastrukturu, a pozadina vaše aplikacije prestane reagirati, svi korisnici će izgubiti vezu s mobilnom aplikacijom. Pojavit će se greška. Doći će do vas i reći “Aplikacija ne radi, šta radiš ovdje?” - "Pratimo." — „Kako pratiti ako ne vidite da aplikacija ne radi?!“

1. Vjerujem da morate početi s praćenjem tačno od korisnikove ulazne tačke. Ako korisnik ne vidi da aplikacija radi, to je to, greška je. A sistem za praćenje bi trebao prvo upozoriti na to.
2. I tek tada možemo pratiti infrastrukturu. Ili to radite paralelno. Lakše je s infrastrukturom - ovdje konačno možemo samo instalirati zabbix.
3. A sada morate ići do korijena aplikacije da biste razumjeli gdje stvari ne rade.

Moja glavna ideja je da praćenje treba da ide paralelno sa razvojnim procesom. Ako odvratite tim za nadgledanje za druge zadatke (kreiranje CI/CD-a, sandboxing, reorganizacija infrastrukture), praćenje će početi da zaostaje i možda nikada nećete sustići razvoj (ili ćete ga prije ili kasnije morati zaustaviti).

Sve po nivoima

Ovako ja vidim organizaciju sistema monitoringa.

1) Nivo aplikacije:

• praćenje poslovne logike aplikacije;
• praćenje zdravstvenih metrika usluga;
• praćenje integracije.

2) Nivo infrastrukture:

• praćenje nivoa orkestracije;
• nadzor sistemskog softvera;
• praćenje nivoa gvožđa.

3) Opet nivo aplikacije - ali kao inženjerski proizvod:

• prikupljanje i praćenje dnevnika aplikacija;
• APM;
• praćenje.

4) Upozorenje:

• organizacija sistema upozorenja;
• organizacija dežurnog sistema;
• organizacija “baze znanja” i toka rada za obradu incidenata.

važno: do upozorenja dolazimo ne poslije, nego odmah! Nema potrebe pokretati monitoring i "nekako kasnije" shvatiti ko će primati upozorenja. Na kraju krajeva, koji je zadatak nadgledanja: razumjeti gdje u sistemu nešto radi pogrešno i obavijestiti prave ljude o tome. Ako ovo ostavite do kraja, onda će pravi ljudi znati da nešto ide po zlu samo po pozivu „ništa nam ne ide“.

Sloj aplikacije - Nadgledanje poslovne logike

Ovdje je riječ o provjeri same činjenice da aplikacija radi za korisnika.

Ovaj nivo treba uraditi tokom faze razvoja. Na primjer, imamo uslovni Prometheus: ide na server koji vrši provjere, povlači krajnju tačku, a krajnja tačka ide i provjerava API.

Kada se često traži da nadgledaju početnu stranicu kako bi bili sigurni da web lokacija radi, programeri daju ručicu koja se može povući svaki put kada je potrebno da se uvjeri da API radi. A programeri u ovom trenutku još uvijek uzimaju i pišu /api/test/helloworld
Jedini način da se uvjerite da sve funkcionira? - Ne!

• Kreiranje takvih provjera je u suštini zadatak programera. Jedinične testove treba da pišu programeri koji pišu kod. Jer ako to procuri administratoru, “Čovječe, evo liste API protokola za svih 25 funkcija, molim te prati sve!” - ništa neće uspjeti.
• Ako odštampate “zdravo svijete”, niko nikada neće znati da API treba i radi. Svaka promjena API-ja mora dovesti do promjene u provjerama.
• Ako već imate takav problem, zaustavite funkcije i dodijelite programere koji će pisati ove provjere, ili prihvatite gubitke, prihvatite da ništa nije provjereno i da neće uspjeti.

Tehnički savjeti:

• Obavezno organizirajte vanjski server za organiziranje provjera - morate biti sigurni da je vaš projekt dostupan vanjskom svijetu.
• Organizirajte provjere za cijeli API protokol, a ne samo za pojedinačne krajnje tačke.
• Kreirajte prometheus-krajnju točku s rezultatima testa.

Sloj aplikacije - praćenje zdravstvenih metrika

Sada govorimo o vanjskim zdravstvenim metrikama usluga.

Odlučili smo da pratimo sve “ručke” aplikacije pomoću eksternih provjera, koje pozivamo iz vanjskog nadzornog sistema. Ali ovo su „ručice“ koje korisnik „vidi“. Želimo biti sigurni da naše usluge rade. Ima bolja priča: K8s ima zdravstvene preglede, tako da se barem sama "kocka" može uvjeriti da servis radi. Ali polovina čekova koje sam vidio je isto ispisano “zdravo svijete”. One. Pa povuče jednom nakon raspoređivanja, odgovorio je da je sve u redu - to je sve. A servis, ako pruža svoj API, ima ogroman broj ulaznih tačaka za taj isti API, koji takođe treba pratiti, jer želimo da znamo da radi. I mi to već pratimo unutra.

Kako to ispravno implementirati tehnički: svaki servis izlaže krajnju tačku o svom trenutnom učinku, a na grafikonima Grafane (ili bilo koje druge aplikacije) vidimo status svih servisa.

• Svaka promjena API-ja mora dovesti do promjene u provjerama.
• Kreirajte novu uslugu odmah sa zdravstvenim pokazateljima.
• Administrator može doći do programera i pitati „dodajte mi nekoliko funkcija kako bih sve razumio i dodajte informacije o ovome u moj sistem za praćenje.“ Ali programeri obično odgovaraju: "Nećemo ništa dodavati dvije sedmice prije objavljivanja."
  Neka znaju menadžeri razvoja da će biti takvih gubitaka, neka znaju i menadžment menadžera razvoja. Jer kad sve padne, neko će ipak zvati i zahtijevati da se prati „usluga koja stalno pada“ (c)
• Usput, dodijelite programere da pišu dodatke za Grafanu - ovo će biti dobra pomoć za administratore.

Sloj aplikacije - Nadgledanje integracije

Monitoring integracije fokusira se na praćenje komunikacija između poslovno kritičnih sistema.

Na primjer, postoji 15 servisa koji međusobno komuniciraju. Ovo više nisu odvojene stranice. One. ne možemo sami povući uslugu, dobiti /helloworld i shvatiti da je usluga pokrenuta. Budući da web servis za naručivanje mora poslati informaciju o narudžbi u sabirnicu - iz sabirnice, servis skladišta mora primiti ovu poruku i dalje raditi s njom. A usluga distribucije e-pošte to mora nekako dalje obraditi itd.

U skladu s tim, ne možemo shvatiti, bockajući svaki pojedinačni servis, da sve funkcionira. Zato što imamo određeni autobus kroz koji sve komunicira i komunicira.
Stoga bi ova faza trebala označiti fazu testiranja servisa za interakciju sa drugim servisima. Nemoguće je organizirati praćenje komunikacije praćenjem brokera poruka. Ako postoji servis koji izdaje podatke i servis koji ih prima, prilikom praćenja brokera vidjet ćemo samo podatke koji lete s jedne strane na drugu. Čak i ako smo nekako uspjeli interno pratiti interakciju ovih podataka - da određeni proizvođač objavi podatke, neko ih pročita, ovaj tok nastavi da ide ka Kafki - to nam ipak neće dati informaciju da li je jedan servis poslao poruku u jednoj verziji , ali drugi servis nije očekivao ovu verziju i preskočio ju je. Za ovo nećemo znati, jer će nam službe reći da sve radi.

Šta preporučujem da uradite:

• Za sinhronu komunikaciju: krajnja točka postavlja zahtjeve povezanim uslugama. One. uzmemo ovu krajnju tačku, izvučemo skriptu unutar servisa, koja ide do svih tačaka i kaže "ja mogu povući tamo, i povući tamo, mogu povući tamo..."
• Za asinkronu komunikaciju: dolazne poruke - krajnja tačka provjerava sabirnicu za testne poruke i prikazuje status obrade.
• Za asinkronu komunikaciju: odlazne poruke - krajnja tačka šalje test poruke na sabirnicu.

Kao što obično biva: imamo servis koji ubacuje podatke u sabirnicu. Dolazimo u ovu uslugu i molimo vas da nam kažete o zdravlju njene integracije. A ako usluga treba da proizvede poruku negdje dalje (WebApp), onda će proizvesti ovu probnu poruku. A ako pokrenemo uslugu na strani OrderProcessing, ona prvo objavi ono što može samostalno objaviti, a ako postoje neke zavisne stvari, onda ona čita skup testnih poruka sa sabirnice, razumije da ih može obraditi, prijaviti i , ako treba, objavi ih dalje, a za ovo kaže - sve je ok, živ sam.

Vrlo često čujemo pitanje "kako to možemo testirati na borbenim podacima?" Na primjer, govorimo o istoj usluzi naručivanja. Naredbom se šalju poruke u skladište u kojem je roba otpisana: to ne možemo testirati na borbenim podacima, jer će "moja roba biti otpisana!" Rješenje: Isplanirajte cijeli test na početku. Imate i jedinične testove koji prave sprdnju. Dakle, učinite to na dubljem nivou gdje imate komunikacijski kanal koji ne šteti poslovanju poslovanja.

Infrastrukturni nivo

Monitoring infrastrukture je nešto što se dugo smatralo samim nadzorom.

• Monitoring infrastrukture se može i treba pokrenuti kao poseban proces.
• Ne biste trebali započeti s praćenjem infrastrukture na projektu koji je u toku, čak i ako to zaista želite. Ovo je muka za sve devopove. “Prvo ću nadgledati klaster, pratiću infrastrukturu” – tj. Prvo će pratiti šta se nalazi ispod, ali neće ulaziti u aplikaciju. Jer aplikacija je za devops neshvatljiva stvar. Procurilo mu je, a on ne razumije kako to funkcionira. Ali on razumije infrastrukturu i počinje s njom. Ali ne - uvijek morate prvo pratiti aplikaciju.
• Ne pretjerujte s brojem upozorenja. S obzirom na složenost modernih sistema, upozorenja stalno lete, a sa ovom gomilom upozorenja morate nekako živjeti. A dežurna osoba, nakon što je pogledala stotinu sljedećih upozorenja, odlučit će "Ne želim razmišljati o tome." Upozorenja bi trebala obavještavati samo o kritičnim stvarima.

Nivo aplikacije kao poslovna jedinica

Ključne točke:

• ELK. Ovo je industrijski standard. Ako iz nekog razloga ne objedinjujete dnevnike, počnite to činiti odmah.
• APM. Eksterni APM-ovi kao način za brzo zatvaranje praćenja aplikacija (NewRelic, BlackFire, Datadog). Možete privremeno instalirati ovu stvar da barem nekako shvatite šta se s vama događa.
• Tracing. U desetinama mikroservisa morate pratiti sve, jer zahtjev više ne živi sam od sebe. Kasnije je vrlo teško dodati, pa je bolje odmah zakazati praćenje u razvoju - to je posao i korisnost programera. Ako ga još niste implementirali, implementirajte ga! Vidi Jaeger/Zipkin

Alerting

• Organizacija sistema obaveštavanja: u uslovima praćenja gomile stvari, trebalo bi da postoji jedinstven sistem za slanje obaveštenja. Možete u Grafani. Na Zapadu svi koriste PagerDuty. Upozorenja treba da budu jasna (npr. odakle su došla...). I preporučljivo je kontrolirati da li se obavijesti uopće primaju
• Organizacija dežurnog sistema: upozorenja ne treba slati svima (ili će svi reagovati u gomili, ili niko neće reagovati). Programeri također moraju biti dežurni: obavezno definirajte područja odgovornosti, dajte jasne upute i u njima napišite koga tačno zvati u ponedjeljak i srijedu, a koga zvati u utorak i petak (inače neće nikoga zvati čak ni u u slučaju velikog problema - plašiće se da vas probudi ili uznemiri: ljudi uglavnom ne vole da zovu i bude druge ljude, posebno noću). I objasnite da traženje pomoći nije pokazatelj nekompetentnosti („Tražim pomoć, to znači da sam loš radnik“), ohrabrite molbe za pomoć.
• Organizacija „baze znanja“ i toka rada za obradu incidenta: za svaki ozbiljniji incident treba planirati obdukciju, a kao privremenu mjeru evidentirati radnje koje će riješiti incident. I neka praksa bude da su ponovljena upozorenja grijeh; treba ih popraviti u kodu ili infrastrukturnom radu.

Tehnološki stog

Zamislimo da je naš stog sljedeći:

• prikupljanje podataka - Prometej + Grafana;
• analiza dnevnika - ELK;
• za APM ili Tracing - Jaeger (Zipkin).

Izbor opcija nije kritičan. Jer ako ste na početku shvatili kako da nadgledate sistem i zapisali plan, onda počinjete da birate alate koji odgovaraju vašim zahtevima. Pitanje je šta ste uopće odabrali da nadgledate. Jer možda alat koji ste odabrali na početku uopće ne odgovara vašim zahtjevima.

Nekoliko tehničkih tačaka koje vidim posvuda u posljednje vrijeme:

Prometej se gura u Kubernetes - ko je ovo smislio?! Ako vam se klaster sruši, šta ćete učiniti? Ako imate složen klaster unutra, onda bi trebalo da postoji neka vrsta sistema za praćenje unutar klastera, a neki izvana, koji će prikupljati podatke iz klastera.

Unutar klastera skupljamo trupce i sve ostalo. Ali sistem za nadzor mora biti vani. Vrlo često, u klasteru u kojem je interno instaliran Promtheus, postoje i sistemi koji vrše eksterne provjere rada stranice. Što ako su vaše veze s vanjskim svijetom opaljene i aplikacija ne radi? Ispostavilo se da je unutra sve u redu, ali to ne olakšava stvari korisnicima.

nalazi

• Nadgledanje razvoja nije instalacija uslužnih programa, već razvoj softverskog proizvoda. 98% današnjeg praćenja je kodiranje. Kodiranje u uslugama, kodiranje eksternih provjera, provjera vanjskih servisa, i to je sve.
• Ne gubite vrijeme svojih programera na nadgledanje: to može zauzeti i do 30% njihovog rada, ali isplati se.
• Devops, ne brini da nešto ne možeš da pratiš, jer neke stvari su potpuno drugačiji način razmišljanja. Niste bili programer, a nadgledanje rada je upravo njihov posao.
• Ako je projekat već pokrenut i nije nadgledan (a vi ste menadžer), dodijelite resurse za praćenje.
• Ako je proizvod već u proizvodnji, a vi ste devops kojem je rečeno da “postavi monitoring” - pokušajte objasniti menadžmentu o čemu sam sve ovo napisao.

Ovo je proširena verzija izvještaja sa Saint Highload++ konferencije.

Ako vas zanimaju moje ideje i razmišljanja o tome i srodnim temama, onda možete ovdje čitaj kanal 🙂

izvor: www.habr.com