Buon venerdì a tutti! Amici, oggi continuiamo la serie di pubblicazioni dedicate al corso , poiché le lezioni nel nuovo gruppo del corso iniziano già alla fine della prossima settimana. Quindi, cominciamo!
Il monitoraggio è solo. È un fatto noto. Avvia Nagios, esegui NRPE sul sistema remoto, configura Nagios sulla porta NRPE TCP 5666 e avrai il monitoraggio.
È così facile che non è nemmeno interessante. Ora hai le metriche di base per l'utilizzo della CPU, il sistema di archiviazione, la memoria RAM, che arrivano per impostazione predefinita in Nagios e NRPE. Ma in realtà, questo non è un vero e proprio "monitoraggio". È solo l'inizio.
(Di solito si installano PNP4Nagios, RRDtool e Thruk, si impostano le notifiche su Slack e si va direttamente su nagiosexchange, ma per ora evitiamo questo).
Un buon monitoraggio è in realtà piuttosto complesso, devi davvero conoscere i dettagli dell'applicazione che stai monitorando.
Il monitoraggio è complicato?
Qualsiasi server, sia esso Linux o Windows, per definizione servirà un certo scopo. Apache, Samba, Tomcat, archiviazione file, LDAP: tutti questi servizi sono più o meno unici in uno o più aspetti. Ognuno ha una propria funzione, delle proprie peculiarità. Ci sono diversi modi per ottenere metriche, KPI (indicatori chiave di prestazione) di tuo interesse quando il server è sotto carico.
Autore della foto in
(mi piacerebbe che i miei cruscotti fossero colorati in blu neon - sospirando sognante -… hmm…)
Qualsiasi software che fornisce servizi deve avere un meccanismo per raccogliere metriche. Apache ha un modulo mod-status, che mostra la pagina di stato del server. Nginx ha stub_status. Tomcat ha JMX o applicazioni web speciali che mostrano metriche chiave. In MySQL c'è il comando "show global status" e così via.
Allora perché gli sviluppatori non integrano meccanismi simili nelle applicazioni che creano?
Solo gli sviluppatori lo fanno?
Un certo livello di indifferenza nell'integrare le metriche non è limitato solo agli sviluppatori. Ho lavorato in aziende che hanno sviluppato applicazioni utilizzando Tomcat e non hanno fornito nessuna delle loro metriche, nessun registro delle attività del servizio, a parte i registri degli errori generali di Tomcat. Alcuni sviluppatori generano una grande abbondanza di log, che non significano nulla per l'amministratore di sistema sfortunato che deve leggerli alle 3:15 del mattino.
Autore della foto in
Gli ingegneri di sistema, che consentono a tali prodotti di essere rilasciati, devono anche assumere una certa responsabilità per la situazione. Pochi ingegneri di sistema hanno tempo e si prendono cura di cercare di ottenere metriche significative dai log, senza il contesto di queste metriche e la possibilità di interpretarle alla luce delle attività dell'applicazione. Alcuni non capiscono quale vantaggio possano trarne, a parte indicatori del tipo "qualcosa attualmente (o presto) non va".
Il cambiamento di mentalità riguardo alla necessità delle metriche deve avvenire non solo tra gli sviluppatori, ma anche tra gli ingegneri di sistema.
Per qualsiasi ingegnere di sistema, che deve non solo rispondere a eventi critici, ma anche garantire la loro assenza, la mancanza di metriche è generalmente un ostacolo a questo.
Tuttavia, gli ingegneri di sistema di solito non si occupano di scrivere codice, guadagnandosi da vivere per la loro azienda. Hanno bisogno di sviluppatori senior che comprendano l'importanza della responsabilità dell'ingegnere di sistema nella scoperta di problemi, aumentando la consapevolezza dei problemi di prestazioni e simili.
Questa cosa del devops
La mentalità devops descrive la sinergia tra il pensiero degli sviluppatori (dev) e delle operazioni (ops). Qualsiasi azienda che afferma di "fare devops" deve:
- dire cose che probabilmente non fanno (riferimento a un meme del film "La principessa sposa" — "Non credo che significhi ciò che pensi che significhi!")
- promuovere una posizione di miglioramento continuo del prodotto.
Non puoi migliorare un prodotto e sapere che è stato migliorato se non sai come funziona attualmente. Non potrai scoprire come funziona il prodotto se non comprendi come funzionano i suoi componenti, i servizi di cui dipende, i suoi principali punti critici e colli di bottiglia.
Se non osservi i potenziali colli di bottiglia, non potrai seguire la tecnica delle "Cinque perché" quando scrivi un Postmortem. Non potrai raccogliere tutto su un unico schermo per vedere come funziona il prodotto o scoprire come appare "normale e felice".
Spostamento a sinistra, A SINISTRA, HO DETTO, SINISTRAAAAA—
Per me, uno dei principi chiave del Devops è "Spostamento a sinistra" (shift left). Lo spostamento a sinistra in questo contesto significa spostare la possibilità (non la responsabilità, e solo le possibilità) di fare ciò di cui si occupano di solito gli ingegneri di sistema, ad esempio, creare metriche di performance, utilizzare i log in modo più efficace, ecc., a sinistra nel ciclo di vita della consegna del software (Software Delivery Life Cycle).
Autore della foto in
Gli sviluppatori di software devono essere in grado di utilizzare e conoscere gli strumenti di monitoraggio usati dall'azienda, per eseguire il monitoraggio in tutte le sue forme, metriche, registrazione, interfacce di monitoraggio e, cosa più importante, osservare come il loro prodotto funziona in produzione.Non puoi costringere gli sviluppatori a investire sforzi e tempo nel monitoraggio finché non possono vedere le metriche e influenzare il modo in cui appaiono, come il proprietario del prodotto le presenterà al CTO nella prossima riunione, ecc.
In breve,
- Porta il cavallo all'acqua. Mostra agli sviluppatori quanti problemi possono evitare per se stessi, aiutali a identificare i KPI e le metriche giuste per le loro applicazioni, in modo che ci sia meno clamore da parte del proprietario del prodotto, che è rimproverato dal direttore tecnico (CTO). Portali alla ribalta, dolcemente e tranquillamente. Se non funziona, allora comprali, minaccia e persuadi sia loro che il proprietario del prodotto, per implementare il più rapidamente possibile il monitoraggio di queste metriche dalle applicazioni, e poi crea dei diagrammi. Sarà difficile, poiché non sarà considerato una priorità, e nel piano del prodotto ci saranno molti progetti in attesa di implementazione che generano reddito. Pertanto, avrai bisogno di giustificazioni economiche per giustificare il tempo e le risorse spese nell'implementazione del monitoraggio nel prodotto.
- Aiuta gli ingegneri di sistema a riposare. Mostra loro che l'uso della checklist "rilasciamo la versione" per ogni prodotto rilasciato è qualcosa di positivo. Verificare che tutte le applicazioni in produzione siano coperte da metriche aiuterà a garantire un sonno sereno, consentendo agli sviluppatori di vedere cosa e dove non funziona correttamente. Tuttavia, il modo migliore per far innervosire e frustrate un qualsiasi sviluppatore, proprietario di prodotto o CTO è insistere nel mettere i bastoni tra le ruote e opporsi. Comportamenti di questo tipo influenzeranno la data di rilascio di qualsiasi prodotto, se si aspetta fino all'ultimo minuto, quindi effettuare nuovamente uno spostamento a sinistra e includere il prima possibile queste questioni nel piano di progetto. Se necessario, intrufolati alle riunioni dedicate al prodotto. Indossa baffi finti e feltro o qualcosa del genere, non ti deluderà mai. Riferisci i tuoi problemi, mostra i vantaggi evidenti e fai evangelizzazione.
- Assicurati che sia gli sviluppatori (dev) che le operazioni (ops) comprendano il significato e la conseguenza del passaggio delle metriche del prodotto in "zona rossa". Non lasciare che le operazioni siano l'unico guardiano della funzionalità del prodotto, assicurati che anche gli sviluppatori partecipino a questo (#productsquads).
- I log sono ottimi, ma anche le metriche. Uniscili e non permettere che i tuoi log diventino spazzatura in una grande palla infuocata di inutilità. Spiega e mostra agli sviluppatori perché nessuno a parte loro sarà in grado di comprendere i loro log, e fai vedere loro com'è guardare log inutili alle 3:15 di mattina.
Autore della foto in
Questo è tutto. Nuovo materiale uscirà la prossima settimana. Se desideri saperne di più sul corso, ti invitiamo a , che si terrà già lunedì. E ora aspettiamo tradizionalmente i tuoi commenti.
Fonte: habr.com
