Je li praćenje mrtvo? — Živjelo praćenje

Od 2008. godine naša se tvrtka primarno bavi upravljanjem infrastrukturom i 400-satnom tehničkom podrškom za web projekte: imamo više od 15 klijenata, što je oko 15% ruske e-trgovine. Sukladno tome, 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 se dogodila nezgoda, morate pratiti projekt i reagirati na incidente. Kako to učiniti?

Smatram da postoji problem u organizaciji odgovarajućeg sustava nadzora. 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 ide 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 sustava nadzora, usudio bih se reći da... projekti s kompetentnim nadzorom ne postoje. A situacija je toliko loša da ako nešto padne, postoji rizik da će proći nezapaženo - uostalom, svi su sigurni da se "sve prati".
Možda se sve prati. Ali kako?

Svi smo se susreli s pričom poput ove: određeni devops, određeni admin radi, dolazi im razvojni tim i kaže - “oslobođeni smo, sad nadgledaj”. Monitor što? Kako radi?

U REDU. Pratimo na starinski način. I već se mijenja, i ispada da ste nadzirali uslugu A, koja je postala usluga B, koja je u interakciji sa uslugom C. Ali razvojni tim vam kaže: "Instalirajte softver, trebao bi nadzirati sve!"

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

2008. godine Sve je u redu

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

Ako usporedimo količinu posla koji je administrator tada obavio kako bi osigurao nadzor, onda je 98% toga bilo automatski: osoba koja vrši nadzor mora razumjeti kako instalirati Zabbix, kako ga konfigurirati i konfigurirati upozorenja. I 2% - za vanjske 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 radi. Da baza podataka radi, da se narudžbe rade, da stranica odgovara eksterno i odgovara sa dva servera i da korisnik nije izbačen sa stranice dok se rebalansira na drugi server itd. Ima više entiteta.

Štoviše, entitet povezan s infrastrukturom i dalje ostaje najveći u glavi upravitelja. U mojoj glavi još uvijek postoji ideja da je osoba koja vrši nadzor osoba koja će instalirati zabbix i moći ga konfigurirati.

Ali u isto vrijeme, pojavljuje se rad na provođenju vanjskih provjera, na stvaranju skupa skripti upita za indeksiranje pretraživanja, skupa skripti za provjeru mijenja li se pretraživanje tijekom procesa indeksiranja, skupa skripti koje provjeravaju je li roba prebačena u dostavna služba itd. i tako dalje.

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

Ali svijet se mijenja, postaje sve složeniji. Dodan je virtualizacijski sloj i nekoliko novih sustava. Oni počinju djelovati jedni s drugima. Tko je rekao "smrdi na mikroservise?" Ali svaka usluga i dalje izgleda zasebno kao web stranica. Možemo mu se obratiti i razumjeti da daje potrebne informacije i radi samostalno. A ako ste administrator koji je stalno uključen u projekt koji se razvija 5-7-10 godina, to se znanje akumulira: pojavi se nova razina - shvatili ste, pojavi se druga razina - shvatili ste...

Ali rijetko tko prati projekt 10 godina.

Životopis nadzornika

Pretpostavimo da ste došli u novi startup koji je odmah zaposlio 20 programera, napisao 15 mikroservisa, a vi ste administrator kojem je rečeno: “Izgradite CI/CD. Molim." Izgradili ste CI/CD i odjednom čujete: „Teško nam je raditi s proizvodnjom u „kocki“, a da ne razumijemo kako će aplikacija raditi u njoj. Napravite nam pješčanik u istoj "kocki".
U ovoj kocki napravite pješčanik. Oni vam odmah kažu: "Želimo bazu podataka pozornice koja se ažurira svaki dan od produkcije, tako da razumijemo da radi na bazi podataka, ali u isto vrijeme ne kvarimo bazu podataka produkcije."

Ti živiš u svemu ovome. Ostalo je 2 tjedna do izlaska, oni vam kažu: "A sada pratimo sve ovo..." Tj. praćenje infrastrukture klastera, praćenje arhitekture mikroservisa, praćenje rada s vanjskim servisima...

A moji kolege iz glave izbiju uobičajenu shemu i kažu: “Pa, ovdje je sve jasno! Instalirajte program koji će sve to pratiti.” Da, da: Prometheus + Grafana + dodaci.
I dodaju: “Imate dva tjedna, pobrinite se da sve bude sigurno.”

U dosta projekata koje vidimo jedna osoba je dodijeljena za praćenje. Zamislimo da želimo zaposliti osobu da radi monitoring na 2 tjedna, a mi joj napišemo životopis. Koje bi vještine ta osoba trebala imati, s obzirom na sve što smo do sada rekli?

• Mora razumjeti praćenje i specifičnosti rada željezne infrastrukture.
• Mora razumjeti specifičnosti nadzora Kubernetesa (a svi žele ići u "kocku", jer možete apstrahirati od svega, sakriti se, jer će se administrator baviti ostalim) - njega samog, njegovu infrastrukturu i razumjeti kako nadzirati aplikacije iznutra.
• Mora razumjeti da usluge međusobno komuniciraju na posebne načine i znati specifičnosti načina na koji usluge međusobno komuniciraju. Sasvim je moguće vidjeti projekt u kojem neki servisi komuniciraju sinkronizirano, jer drugog načina nema. Na primjer, backend ide putem REST-a, preko gRPC-a do kataloške usluge, prima popis proizvoda i vraća ga natrag. Ne možete čekati ovdje. I s drugim uslugama radi asinkrono. Prenesite narudžbu dostavnoj službi, pošaljite pismo itd.
  Vjerojatno ste već isplivali iz svega ovoga? A admin, koji to treba pratiti, postao je još više zbunjen.
• Mora biti sposoban planirati i ispravno planirati - kako posla postaje sve više i više.
• Stoga mora kreirati strategiju iz stvorene usluge kako bi razumio kako je konkretno nadzirati. Potrebno mu je razumijevanje arhitekture projekta i njegovog razvoja + razumijevanje tehnologija korištenih u razvoju.

Sjetimo se 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 jedni s drugima. Odatle dolazi izraz "mikroservis": postoji toliko mnogo pojedinačnih sustava da programeri ne mogu razumjeti projekt u cjelini. Jedan dio ekipe piše servise u JS-u koji rade sami i ne znaju kako radi ostatak sustava. Drugi dio piše usluge u Pythonu i ne miješa se u rad drugih usluga; oni su izolirani u svom području. Treći je pisanje usluga u PHP-u ili nečem drugom.
Svih tih 20 ljudi podijeljeno je u 15 službi, a samo je jedan admin koji sve to mora razumjeti. Stop! samo smo podijelili sustav na 15 mikroservisa jer 20 ljudi ne može razumjeti cijeli sustav.

Ali to treba nekako pratiti...

Kakav je rezultat? Kao rezultat toga, postoji jedna osoba koja dolazi sa svime što cijeli tim programera ne može razumjeti, a istovremeno mora znati i moći raditi ono što smo gore naveli - hardversku infrastrukturu, Kubernetes infrastrukturu itd.

Što da kažem... Houstone, imamo problema.

Praćenje suvremenog softverskog projekta softverski je projekt sam po sebi

Iz lažnog uvjerenja da je nadzor softver, razvijamo vjeru u čuda. Ali čuda se, nažalost, ne događaju. Ne možete instalirati zabbix i očekivati ​​da sve radi. Nema smisla instalirati Grafana i nadati se da će sve biti ok. Najviše vremena potrošit ćemo na organiziranje provjera rada servisa i njihove međusobne interakcije, provjeru rada vanjskih sustava. Zapravo, 90% vremena neće biti potrošeno na pisanje skripti, već na razvoj softvera. I time bi se trebao baviti tim koji razumije rad projekta.
Ako u ovoj situaciji jedna osoba bude bačena u nadzor, dogodit će se katastrofa. Što se posvuda događa.

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

A ako ovo također date administratoru i programerima u fazi kada je preostalo malo vremena do objave, osoba će morati razumjeti cijeli ovaj protokol. Oni. Za projekt ove veličine potrebno je dosta vremena i to treba uzeti u obzir pri razvoju sustava.
Ali vrlo često, posebno u startupima, vidimo kako se praćenje odgađa za kasnije. “Sada ćemo napraviti dokaz koncepta, lansirat ćemo s njim, pustiti ga da padne - spremni smo se žrtvovati. A onda ćemo sve to pratiti.” Kada (ili ako) projekt počne zarađivati, tvrtka želi dodati još više značajki - jer je počeo raditi, pa ga treba dalje razvijati! I tu ste na mjestu gdje 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 je pustiti ih da rade na novim značajkama. Kao rezultat toga, napisane su nove značajke, sve se zeznu, a vi ste u beskrajnom ćorsokaku.

Dakle, kako pratiti projekt od početka i što učiniti ako dobijete projekt koji treba pratiti, ali ne znate odakle početi?

Prvo, morate planirati.

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

Prvo odlučite što i kako želite pratiti, a zatim odaberite alat jer drugi ljudi ne mogu misliti umjesto vas. A trebaju li? Drugi su ljudi razmišljali o univerzalnom sustavu - ili uopće nisu razmišljali kada je ovaj dodatak napisan. I to što ovaj plugin ima 5 tisuća korisnika ne znači da je od njega ikakva korist. Možda ćete postati 5001. jednostavno zato što je već prije bilo 5000 ljudi.

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

1. Vjerujem da morate započeti s praćenjem točno od ulazne točke korisnika. Ako korisnik ne vidi da aplikacija radi, to je to, to je greška. I na to bi sustav za nadzor trebao prvo upozoriti.
2. I tek onda 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 kako biste shvatili gdje stvari ne rade.

Moja glavna ideja je da praćenje treba ići paralelno s procesom razvoja. Ako odvratite tim za praćenje na druge zadatke (stvaranje CI/CD-a, sandboxing, reorganizacija infrastrukture), nadzor će početi kasniti i možda nikada nećete sustići razvoj (ili ćete ga prije ili kasnije morati zaustaviti).

Sve po razinama

Tako ja vidim organizaciju sustava nadzora.

1) Razina primjene:

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

2) Razina infrastrukture:

• praćenje razine orkestracije;
• nadzor softvera sustava;
• praćenje razine željeza.

3) Opet razina primjene - ali kao inženjerski proizvod:

• prikupljanje i praćenje prijavnih zapisa;
• APM;
• traganje.

4) Upozorenje:

• organizacija sustava upozorenja;
• organizacija sustava dežurstva;
• organizacija “baze znanja” i tijek rada za obradu incidenata.

To je važno: dolazimo do upozorenja ne nakon, nego odmah! Nema potrebe pokretati nadzor i “nekako kasnije” shvaćati tko će primati upozorenja. Uostalom, što je zadaća nadzora: shvatiti gdje u sustavu nešto ne radi kako treba i obavijestiti prave ljude o tome. Ako ovo ostavite do kraja, tada će pravi ljudi znati da nešto nije u redu samo po pozivu “ništa nam ne ide”.

Aplikacijski sloj - Praćenje poslovne logike

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

Ovu razinu treba napraviti tijekom faze razvoja. Na primjer, imamo uvjetni Prometheus: ide na poslužitelj koji radi provjere, povlači krajnju točku, a krajnja točka odlazi i provjerava API.

Kada se često traži da prate početnu stranicu kako bi provjerili radi li stranica, programeri daju ručku koju mogu povući svaki put kada trebaju provjeriti radi li API. A programeri u ovom trenutku još uvijek uzimaju i pišu /api/test/helloworld
Jedini način da budemo sigurni da sve radi? - Ne!

• Stvaranje takvih provjera u biti je zadatak programera. Jedinične testove trebaju pisati programeri koji pišu kod. Jer ako to odaslaš administratoru, "Stari, evo popisa API protokola za svih 25 funkcija, molim te, prati sve!" - ništa neće uspjeti.
• Ako ispišete "hello world", nitko 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 značajke i dodijelite programere koji će pisati ove provjere ili prihvatite gubitke, prihvatite da se ništa ne provjerava i neće uspjeti.

Tehnički savjeti:

• Obavezno organizirajte vanjski poslužitelj za organiziranje provjera - morate biti sigurni da je vaš projekt dostupan vanjskom svijetu.
• Organizirajte provjere kroz cijeli API protokol, a ne samo pojedinačne krajnje točke.
• Stvorite krajnju točku prometeja s rezultatima testa.

Aplikacijski sloj - praćenje metrike zdravlja

Sada govorimo o vanjskim pokazateljima zdravlja usluga.

Odlučili smo nadzirati sve "ručke" aplikacije pomoću vanjskih provjera, koje pozivamo iz vanjskog nadzornog sustava. Ali to su "ručke" koje korisnik "vidi". Želimo biti sigurni da same naše usluge rade. Ovdje je bolja priča: K8s ima provjere zdravlja, tako da se barem sama "kocka" može uvjeriti da servis radi. Ali polovica čekova koje sam vidio je isti ispis "zdravo svijetu". Oni. Dakle, povukao je jednom nakon raspoređivanja, odgovorio je da je sve u redu - to je sve. A servis, ako ima svoj API, ima ogroman broj ulaznih točaka za taj isti API, koji također treba pratiti, jer želimo znati da radi. I već ga pratimo unutra.

Kako to tehnički ispravno implementirati: svaka usluga izlaže krajnju točku o svojoj trenutnoj izvedbi, au grafovima Grafane (ili bilo koje druge aplikacije) vidimo status svih usluga.

• Svaka promjena API-ja mora dovesti do promjene u provjerama.
• Stvorite novu uslugu odmah s metrikom zdravlja.
• Administrator može doći do programera i zatražiti "dodajte mi nekoliko značajki kako bih sve razumio i dodajte informacije o tome u svoj sustav praćenja." Ali programeri obično odgovaraju: "Nećemo ništa dodavati dva tjedna prije izdanja."
  Neka znaju voditelji razvoja da će biti takvih gubitaka, neka znaju i menadžment menadžera razvoja. Jer kad sve padne, netko će i dalje zvati i tražiti da se prati “konstantno pada servis” (c)
• Usput, dodijelite programerima da napišu dodatke za Grafanu - ovo će biti dobra pomoć za administratore.

Aplikacijski sloj - Integracijski nadzor

Nadzor integracije usmjeren je na nadzor komunikacije između poslovno kritičnih sustava.

Na primjer, postoji 15 servisa koji međusobno komuniciraju. Ovo više nisu odvojene stranice. Oni. ne možemo pokrenuti uslugu samostalno, dobiti /helloworld i shvatiti da usluga radi. Budući da web servis za naručivanje mora poslati informacije o narudžbi autobusu - iz autobusa, skladišni servis mora primiti ovu poruku i dalje raditi s njom. A servis za distribuciju e-pošte mora to nekako dalje obraditi, itd.

Sukladno tome, ne možemo razumjeti, bockajući svaku pojedinu uslugu, da sve to radi. Jer imamo određenu sabirnicu preko koje sve komunicira i interaguje.
Stoga bi ova faza trebala označavati fazu testiranja servisa za interakciju s drugim servisima. Nemoguće je organizirati praćenje komunikacije praćenjem brokera poruka. Ako postoji servis koji izdaje podatke i servis koji ih prima, pri praćenju brokera vidjet ćemo samo podatke koji lete s jedne na drugu stranu. Čak i ako smo nekako uspjeli interno nadzirati interakciju ovih podataka - da određeni proizvođač objavi podatke, netko ih pročita, taj tijek nastavi ići do Kafke - to nam i dalje neće dati informaciju je li jedan servis poslao poruku u jednoj verziji , ali drugi servis nije očekivao ovu verziju i preskočio ju je. Nećemo znati za to, jer će nam službe reći da sve radi.

Što preporučujem učiniti:

• Za sinkronu komunikaciju: krajnja točka upućuje zahtjeve povezanim uslugama. Oni. uzmemo ovu krajnju točku, povučemo skriptu unutar usluge, koja ide do svih točaka i kaže "Mogu povući tamo, i povući tamo, mogu povući tamo..."
• Za asinkronu komunikaciju: dolazne poruke - krajnja točka provjerava sabirnicu za testne poruke i prikazuje status obrade.
• Za asinkronu komunikaciju: odlazne poruke - krajnja točka šalje testne poruke sabirnici.

Kao što obično biva: imamo uslugu koja ubacuje podatke u sabirnicu. Dolazimo do ove usluge i tražimo od vas da nam kažete o njenom stanju integracije. A ako usluga treba proizvesti poruku negdje dalje (WebApp), tada će proizvesti ovu testnu poruku. A ako pokrenemo uslugu na strani OrderProcessing, ona prvo objavljuje ono što može objaviti neovisno, a ako postoje neke ovisne stvari, onda čita skup testnih poruka iz 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. Narudžba šalje poruke skladištu gdje je roba otpisana: to ne možemo testirati na borbenim podacima, jer će "moja roba biti otpisana!" Rješenje: Planirajte ovaj cijeli test na početku. Također imate jedinične testove koji se rugaju. Dakle, učinite to na dubljoj razini gdje imate komunikacijski kanal koji ne šteti poslovanju poslovanja.

Razina infrastrukture

Praćenje infrastrukture je nešto što se dugo smatralo samim nadzorom.

• Monitoring infrastrukture se može i treba pokrenuti kao zaseban proces.
• Ne biste trebali započeti s praćenjem infrastrukture na projektu koji je u tijeku, čak i ako to stvarno želite. Ovo je bol za sve devope. "Prvo ću nadzirati klaster, nadzirat ću infrastrukturu" - tj. Prvo će pratiti što se nalazi ispod, ali neće ići u aplikaciju. Jer aplikacija je za devops neshvatljiva stvar. Procurilo mu je, a on ne razumije kako to funkcionira. I on razumije infrastrukturu i počinje s njom. Ali ne - uvijek prvo morate nadzirati aplikaciju.
• Nemojte pretjerivati ​​s brojem upozorenja. S obzirom na kompleksnost modernih sustava, upozorenja stalno lete, a s tom hrpom upozorenja treba nekako živjeti. A dežurna će osoba, pogledavši stotinjak sljedećih dojava, odlučiti "ne želim o tome razmišljati". Upozorenja bi trebala obavještavati samo o kritičnim stvarima.

Aplikacijska razina kao poslovna jedinica

Ključne točke:

• LOS. Ovo je industrijski standard. Ako iz nekog razloga ne skupljate dnevnike, počnite to činiti odmah.
• APM. Vanjski APM-ovi kao način brzog zatvaranja nadzora aplikacija (NewRelic, BlackFire, Datadog). Možete privremeno instalirati ovu stvar da barem nekako shvatite što se s vama događa.
• Trasiranje. U desecima mikroservisa morate pratiti sve, jer zahtjev više ne živi sam za sebe. Vrlo je teško dodati kasnije, pa je bolje odmah zakazati praćenje u razvoju - to je rad i korisnost programera. Ako ga još niste implementirali, implementirajte ga! Vidi Jaeger/Zipkin

Uzbunjivanje

• Organizacija sustava obavješćivanja: u uvjetima praćenja hrpe stvari, trebao bi postojati jedinstveni sustav za slanje obavijesti. Možete u Grafani. Na zapadu svi koriste PagerDuty. Upozorenja trebaju biti jasna (npr. odakle dolaze...). I poželjno je kontrolirati primaju li se obavijesti uopće
• Organizacija sustava dežurstva: uzbune ne treba slati svima (ili će svi reagirati u masi ili nitko neće reagirati). Programeri također moraju biti dežurni: svakako definirajte područja odgovornosti, napravite jasne upute i u njima napišite koga točno zvati u ponedjeljak i srijedu, a koga u utorak i petak (inače nikoga neće zvati ni u u slučaju velikog problema - bojat će vas probuditi ili smetati: ljudi općenito ne vole zvati i buditi druge ljude, osobito noću). I objasnite da traženje pomoći nije pokazatelj nekompetentnosti ("Tražim pomoć, to znači da sam loš radnik"), potaknite zahtjeve za pomoć.
• Organizacija „baze znanja“ i tijek rada za obradu incidenta: za svaki ozbiljni incident treba planirati obdukciju, a kao privremenu mjeru treba zabilježiti radnje koje će riješiti incident. I neka postane praksa da su ponavljana upozorenja grijeh; potrebno ih je popraviti u kodu ili radu na infrastrukturi.

Tehnološki skup

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 razumjeli kako nadzirati sustav i napisali plan, tada počinjete birati alate koji odgovaraju vašim zahtjevima. Pitanje je što ste uopće odlučili pratiti. Jer možda alat koji ste odabrali na početku uopće ne odgovara vašim zahtjevima.

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

Prometej se gura unutar Kubernetesa - tko je ovo smislio?! Ako vam se klaster sruši, što ćete učiniti? Ako imate složeni klaster unutra, onda bi trebao postojati neka vrsta sustava za nadzor unutar klastera, a neki izvan njega, koji će prikupljati podatke unutar klastera.

Unutar klastera skupljamo cjepanice i sve ostalo. Ali sustav nadzora mora biti vani. Vrlo često, u klasteru gdje je interno instaliran Promtheus, postoje i sustavi koji vrše eksterne provjere rada stranice. Što ako su vaše veze s vanjskim svijetom prekinute i aplikacija ne radi? Ispostavilo se da je unutra sve u redu, ali to korisnicima nimalo ne olakšava posao.

Zaključci

• Praćenje razvoja nije instalacija uslužnih programa, već razvoj softverskog proizvoda. 98% današnjeg praćenja je kodiranje. Kodiranje u uslugama, kodiranje vanjskih provjera, provjera vanjskih usluga i to je sve.
• Ne gubite vrijeme programera na nadgledanje: to može oduzeti do 30% njihovog posla, ali se isplati.
• Devops, ne brini da ne možeš nešto pratiti, jer neke stvari su potpuno drugačiji način razmišljanja. Vi niste bili programer, a praćenje rada je upravo njihov posao.
• Ako je projekt već pokrenut i nije nadziran (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 “postavite nadzor” - pokušajte objasniti menadžmentu o čemu sam sve ovo napisao.

Ovo je proširena verzija izvješća na konferenciji Saint Highload++.

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

Izvor: www.habr.com