Sretan petak svima! Prijatelji, danas nastavljamo seriju publikacija posvećenih kursu , jer nastava u novoj grupi za kurs počinje krajem sljedeće sedmice. Dakle, počnimo!
Monitoring je samo. Ovo je poznata činjenica. Pokrenite Nagios, pokrenite NRPE na udaljenom sistemu, konfigurišite Nagios na NRPE TCP portu 5666 i imate nadzor.
Toliko je lako da nije zanimljivo. Sada imate osnovne metrike za CPU vrijeme, diskovni podsistem, RAM, koje se po defaultu isporučuju za Nagios i NRPE. Ali ovo zapravo nije „nadgledanje“ kao takvo. Ovo je samo početak.
(Obično instaliraju PNP4Nagios, RRDtool i Thruk, postavljaju obavijesti u Slack-u i idu direktno na nagiosexchange, ali ostavimo to za sada).
Dobar monitoring je zapravo prilično složena, zaista morate znati unutrašnjost aplikacije koju nadgledate.
Da li je praćenje teško?
Svaki server, bilo da je to Linux ili Windows, po definiciji će služiti nekoj svrsi. Apache, Samba, Tomcat, skladištenje datoteka, LDAP - sve ove usluge su manje-više jedinstvene u jednom ili više aspekata. Svaki ima svoju funkciju, svoje karakteristike. Postoje različiti načini da dobijete metriku, KPI-je (ključne indikatore učinka), koji su vam zanimljivi kada je server pod opterećenjem.
Autor fotografije na
(Voleo bih da su moje komandne table neonsko plave - sanjivo uzdišući -... hmm...)
Svaki softver koji pruža usluge mora imati mehanizam za prikupljanje metrike. Apache ima modul mod-status, prikazuje stranicu statusa servera. Nginx ima - stub_status. Tomcat ima JMX ili prilagođene web aplikacije koje prikazuju ključne metrike. MySQL ima naredbu "prikaži globalni status" itd.
Pa zašto programeri ne ugrade slične mehanizme u aplikacije koje kreiraju?
Da li to rade samo programeri?
Određeni nivo ravnodušnosti prema ugrađivanju metrike nije ograničen samo na programere. Radio sam u kompanijama u kojima su razvijali aplikacije koristeći Tomcat i nisam davao nikakve svoje metrike, nikakve evidencije servisnih aktivnosti, osim općih Tomcat dnevnika grešaka. Neki programeri generišu mnogo dnevnika koji ništa ne znače administratoru sistema koji nema sreće da ih pročita u 3:15 ujutro.
Autor fotografije na
Sistemski inženjeri koji omogućavaju da se takvi proizvodi puštaju u prodaju također moraju snositi određenu odgovornost za situaciju. Nekoliko sistemskih inženjera ima vremena ili brige da pokuša izvući značajne metrike iz dnevnika, bez konteksta tih metrika i mogućnosti da ih interpretira u svjetlu aktivnosti aplikacije. Neki ne razumiju kako mogu imati koristi od toga, osim pokazatelja "nešto trenutno (ili će uskoro biti) nije u redu".
Promjena u razmišljanju o potrebi za metrikom mora se dogoditi ne samo među programerima, već i među sistemskim inženjerima.
Za svakog sistemskog inženjera koji ne samo da treba da reaguje na kritične događaje, već i da obezbedi da se oni ne dogode, nedostatak metrike je obično prepreka za to.
Međutim, sistemski inženjeri se obično ne petljaju sa kodom kako bi zaradili novac za svoju kompaniju. Njima su potrebni vodeći programeri koji razumiju važnost odgovornosti sistemskog inženjera u identifikaciji problema, podizanju svijesti o problemima performansi i slično.
Ovo devops stvar
Devops mentalitet opisuje sinergiju između razvojnog (dev) i operativnog (ops) razmišljanja. Svaka kompanija koja tvrdi da "radi devops" mora:
- govore stvari koje verovatno ne znaju (pozivajući se na mem princeze neveste - "Mislim da to ne znači ono što vi mislite da znači!")
- Ohrabrite stav o stalnom poboljšanju proizvoda.
Ne možete poboljšati proizvod i znati da je poboljšan ako ne znate kako trenutno funkcionira. Ne možete znati kako proizvod funkcionira ako ne razumijete kako funkcioniraju njegove komponente, usluge o kojima ovisi, njegove glavne bolne točke i uska grla.
Ako ne pazite na potencijalna uska grla, nećete moći slijediti tehniku Pet Zašto kada pišete Postmortem. Nećete moći sve staviti na jedan ekran da vidite kako proizvod radi ili da znate kako izgleda "normalno i sretno".
Pomaknite lijevo, LIJEVO, REKAO sam LEEEE—
Za mene je jedan od ključnih principa Devopsa “pomak ulijevo”. Pomak ulijevo u ovom kontekstu znači pomicanje mogućnosti (nema odgovornosti, ali samo sposobnosti) za obavljanje stvari do kojih sistemski inženjeri obično vode računa, kao što je kreiranje metrika performansi, efikasnije korištenje dnevnika, itd., lijevo u životnom ciklusu isporuke softvera.
Autor fotografije na
Programeri softvera moraju biti u stanju da koriste i poznaju alate za praćenje koje kompanija koristi kako bi izvršila nadzor u svim njegovim oblicima, metriku, evidentiranje, sučelja za praćenje i, što je najvažnije, gledati kako njihov proizvod funkcionira u proizvodnji. Ne možete natjerati programere da ulože trud i vrijeme u praćenje dok ne vide metriku i utiču na to kako izgledaju, kako ih vlasnik proizvoda predstavlja CTO-u na sljedećem brifingu itd.
Ukratko
- Vodi svog konja do vode. Pokažite programerima koliko problema mogu izbjeći za sebe, pomozite im da identifikuju prave KPI-je i metrike za svoje aplikacije kako bi bilo manje vikanja vlasnika proizvoda na kojeg viče CTO. Iznesite ih na svjetlo, nježno i mirno. Ako to ne uspije, onda podmitite, prijetite i nagovarajte njih ili vlasnika proizvoda da implementiraju dobijanje ovih metrika iz aplikacija što je brže moguće, a zatim nacrtajte dijagrame. Ovo će biti teško jer se neće smatrati prioritetom, a mapa puta će sadržavati mnoge projekte koji generiraju prihod. Stoga će vam trebati poslovni slučaj da opravdate vrijeme i trošak utrošene na implementaciju nadzora u proizvod.
- Pomozite sistemskim inženjerima da se dobro naspaju. Pokažite im da je korištenje kontrolne liste "hajde da pustimo" za bilo koji proizvod koji se izdaje dobra stvar. A osiguravanje da su sve aplikacije u produkciji pokrivene metrikom pomoći će vam da bolje spavate noću omogućavajući programerima da vide šta ide po zlu i gdje. Međutim, pravi način da iznervirate i frustrirate bilo kojeg programera, vlasnika proizvoda ili tehničkog direktora je da ustrajete i oduprete se. Ovo ponašanje će utjecati na datum objavljivanja bilo kojeg proizvoda ako ponovo čekate do posljednjeg trenutka, stoga ponovo pomaknite lijevo i unesite ove probleme u svoj plan projekta što je prije moguće. Ako je potrebno, idite na sastanke proizvoda. Nosite lažne brkove i filc ili tako nešto, nikada neće propasti. Iznesite svoje brige, pokažite jasne prednosti i evangelizirajte.
- Uvjerite se da i razvoj (dev) i operacije (ops) razumiju značenje i posljedice kretanja metrike proizvoda u crvenu zonu. Ne ostavljajte Ops kao jedinog čuvara zdravlja proizvoda, pobrinite se da su i programeri uključeni (#productsquads).
- Dnevnici su odlična stvar, ali i metrika. Kombinirajte ih i ne dozvolite da vam trupci postanu smeće u ogromnoj plamenoj kugli beskorisnosti. Objasnite i pokažite programerima zašto niko drugi neće razumjeti njihove dnevnike, pokažite im kako je gledati beskorisne dnevnike u 3:15 ujutro.
Autor fotografije na
To je sve. Novi materijal će biti objavljen sljedeće sedmice. Ukoliko želite da saznate više o kursu, pozivamo vas na , koji će se održati u ponedjeljak. A sada već tradicionalno čekamo vaše komentare.
izvor: www.habr.com