Bon vennari à tutti ! Amici, oghje cuntinuemu a seria di publicazioni dedicate à u corsu , perchè e classi in u novu gruppu per u corsu accuminciaranu à a fine di a settimana prossima. Allora, cuminciamu !
U monitoraghju hè solu. Questu hè un fattu cunnisciutu. Portate Nagios, eseguite NRPE nantu à u sistema remotu, cunfigurate Nagios nantu à u portu NRPE TCP 5666 è avete monitoraghju.
Hè cusì faciule chì ùn hè micca interessante. Avà avete metriche basi per u tempu di CPU, u sottosistema di discu, RAM, furnitu per difettu à Nagios è NRPE. Ma questu ùn hè micca veramente "surveglianza" cum'è tali. Questu hè solu u principiu.
(Di solitu installanu PNP4Nagios, RRDtool è Thruk, stallanu notifiche in Slack è andate direttamente à nagiosexchange, ma lascemu per avà).
Bon surviglianza hè in realtà abbastanza cumplessu, avete bisognu di cunnosce l'internu di l'applicazione chì seguite.
U monitoraghju hè difficiule?
Qualchese servitore, sia Linux o Windows, per definizione serve à qualchì scopu. Apache, Samba, Tomcat, archiviazione di file, LDAP - tutti sti servizii sò più o menu unichi in unu o più rispetti. Ognunu hà a so funzione, e so caratteristiche. Ci hè parechje manere di ottene metriche, KPI (indicatori di rendiment chjave), chì sò interessanti per voi quandu u servitore hè sottu carica.
Autore di a foto nantu
(Vogliu chì i mo dashboards eranu blu neon - suspirendu sognu -... hmm...)
Ogni software chì furnisce servizii deve avè un mecanismu per cullà metriche. Apache hà un modulu mod-status, affissendu a pagina di statutu di u servitore. Nginx hà - stub_status. Tomcat hà JMX o applicazioni web persunalizati chì mostranu metriche chjave. MySQL hà un cumandamentu "mostra u statu globale" etc.
Allora perchè i sviluppatori ùn creanu micca miccanismi simili in l'applicazioni chì creanu?
Sò solu i sviluppatori chì facenu questu?
Un certu livellu di indiferenza à l'incrustazione di metriche ùn hè micca limitatu à i sviluppatori. Aghju travagliatu in cumpagnie induve anu sviluppatu l'applicazioni cù Tomcat è ùn hà micca furnitu nisuna metrica propria, nè logs di attività di serviziu, salvu i logs d'errore generale Tomcat. Certi sviluppatori generanu assai logs chì ùn significanu nunda per l'amministratore di u sistema chì hè sfurtunatu di leghje à 3:15 di a matina.
Autore di a foto nantu
L'ingegneri di u sistema chì permettenu à esse liberati tali prudutti anu ancu avè una certa rispunsabilità per a situazione. Pochi ingegneri di sistemi anu u tempu o a cura di pruvà à caccià metriche significative da i logs, senza u cuntestu di quelli metrichi è a capacità di interpretà à a luce di l'attività di l'applicazione. Qualchidunu ùn capiscenu micca cumu si ponu prufittà di questu, altri chì "qualcosa hè attualmente (o sarà prestu) sbagliatu".
Un cambiamentu in u pensamentu in quantu à a necessità di metrica deve esse micca solu trà i sviluppatori, ma ancu trà ingegneri di sistemi.
Per qualsiasi ingegnere di sistemi chì deve micca solu risponde à l'avvenimenti critichi, ma ancu assicurà chì ùn si verificanu micca, a mancanza di metrica hè di solitu una barriera per fà.
In ogni casu, l'ingegneri di sistemi ùn sò generalmente micca chjappà cù u codice per guadagnà soldi per a so cumpagnia. Hanu bisognu di sviluppatori principali chì capiscenu l'impurtanza di a rispunsabilità di l'ingegnere di sistemi per identificà i prublemi, sensibilizà i prublemi di rendiment, è simili.
Questa cosa devops
A mentalità devops descrive a sinergia trà u sviluppu (dev) è l'operazioni (ops) u pensamentu. Ogni cumpagnia chì dice di "fà devops" deve:
- dicendu e cose chì probabilmente ùn anu micca (in riferimentu à u meme di The Princess Bride - "Ùn pensu micca chì significheghja ciò chì pensate chì significa!")
- Incuragisce una attitudine di migliuramentu cuntinuu di u produttu.
Ùn pudete micca migliurà un pruduttu è sapete chì hè statu migliuratu s'ellu ùn sapete micca cumu funziona attualmente. Ùn pudete micca sapè cumu funziona un pruduttu s'ellu ùn capisce micca cumu funziona i so cumpunenti, i servizii chì dipende, i so punti di dolore principali è i colli di bottiglia.
Se ùn fighjate micca per i putenziali colli di bottiglia, ùn puderete micca seguità a tecnica Five Whys quandu scrive un Postmortem. Ùn puderà micca mette tuttu in una schermu per vede cumu funziona un pruduttu o sapè ciò chì pare "normale è felice".
Shift left, LEFT, I said LEEEE-
Per mè, unu di i principii chjave di Devops hè "shift left". Shift left in stu cuntestu significa spustà a pussibilità (senza rispunsabilità, ma solu capacità) per fà e cose chì l'ingegneri di i sistemi sò tipicamente preoccupati, cum'è a creazione di metriche di rendiment, utilizendu logs più efficaci, etc., à a manca in u Ciclu di Vita di Consegna di Software.
Autore di a foto nantu
I sviluppatori di software devenu esse capaci di utilizà è cunnosce l'arnesi di monitoraghju chì a cumpagnia usa per fà u monitoraghju in tutte e so forme, metriche, logging, interfacce di monitoraghju è, più impurtante, fighjate cumu u so pruduttu funziona in a produzzione. Ùn pudete micca uttene i sviluppatori à investisce u sforzu è u tempu in u monitoraghju finu à ch'elli ponu vede e metriche è influenzà cumu si vedenu, cumu u pruprietariu di u produttu li presenta à u CTO à u prossimu briefing, etc.
In breve
- Cunduce u vostru cavallu à l'acqua. Mostra à i sviluppatori quanti prublemi ponu evità per elli stessi, aiutanu à identificà i KPI è e metriche ghjuste per e so applicazioni in modu chì ci sia menu grida da u pruprietariu di u produttu chì hè chjapputu da u CTO. Purtateli à a luce, dolce è calmu. S'ellu ùn funziona micca, allora corrompe, minacciate, è ingannate o elli o u pruprietariu di u produttu per implementà ottene queste metriche da l'applicazioni u più prestu pussibule, è poi disegnate i diagrammi. Questu serà difficiule postu chì ùn serà micca vistu cum'è una priorità è a strada di u produttu avarà parechji prughjetti chì generanu ingressi pendenti. Dunque, avete bisognu di un casu cummerciale per ghjustificà u tempu è a spesa spesa per implementà a monitorizazione in u pruduttu.
- Aiuta l'ingegneri di u sistema à dorme una bona notte. Dimustralli chì l'utilizazione di una lista di verificazione "liberate" per ogni pruduttu chì hè liberatu hè una bona cosa. È assicuratevi chì tutte l'applicazioni in produzzione sò cuparti di metriche vi aiuterà à dorme megliu a notte, permettendu à i sviluppatori di vede ciò chì andava male è induve. In ogni casu, u modu ghjusta per irrità è frustrate qualsiasi sviluppatore, pruprietariu di produttu o CTO hè di persiste è resiste. Stu cumpurtamentu avarà un impattu nantu à a data di liberazione di qualsiasi pruduttu s'è vo aspettate finu à l'ultimu minutu di novu, cusì turnate a manca di novu è mette questi prublemi in u vostru pianu di prughjettu u più prestu pussibule. Se necessariu, fate u vostru modu à riunioni di produttu. Purtate un mustache fintu è feltru o qualcosa, ùn falla mai. Comunicate e vostre preoccupazioni, dimustrà benefizii chjaru è evangelizà.
- Assicuratevi chì u sviluppu (dev) è l'operazioni (ops) capiscenu u significatu è a cunsiquenza di e metriche di u produttu chì si movenu in a zona rossa. Ùn lasciate micca Ops cum'è l'unicu guardianu di a salute di u produttu, assicuratevi chì i sviluppatori sò ancu implicati (#productsquads).
- I logs sò una grande cosa, ma ancu e metriche. Combinali è ùn lasciate micca chì i vostri logs diventenu basura in una enorme bola fiammeggiante di inutilità. Spiegà è mostra à i sviluppatori per quessa chì nimu hà da capisce i so logs, mostranu ciò chì hè cum'è per fighjà i logs inutili à 3:15 in a matina.
Autore di a foto nantu
Eccu tuttu. U novu materiale serà liberatu a settimana prossima. Sè vo vulete amparà di più nantu à u corsu, vi invitamu , chì si ferà u luni. È avà aspettemu tradiziunale i vostri cumenti.
Source: www.habr.com