Buon venerdì a tutti! Amici, continuiamo oggi la serie di pubblicazioni dedicate al corso , perché le lezioni del nuovo gruppo del corso inizieranno alla fine della prossima settimana. Allora, cominciamo!
Il monitoraggio lo è solo. Questo è un fatto noto. Apri Nagios, esegui NRPE sul sistema remoto, configura Nagios sulla porta TCP NRPE 5666 e avrai il monitoraggio.
È così facile che non è interessante. Ora disponi di parametri di base per il tempo della CPU, il sottosistema del disco, la RAM, forniti per impostazione predefinita a Nagios e NRPE. Ma non si tratta in realtà di “monitoraggio” in quanto tale. Questo è solo l'inizio.
(Di solito installano PNP4Nagios, RRDtool e Thruk, impostano le notifiche in Slack e vanno direttamente a nagiosexchange, ma per ora lasciamo perdere questo).
Buon monitoraggio è in realtà piuttosto complesso, devi davvero conoscere i meccanismi interni dell'applicazione che stai monitorando.
Il monitoraggio è difficile?
Qualsiasi server, sia esso Linux o Windows, per definizione servirà a qualche scopo. Apache, Samba, Tomcat, archiviazione di file, LDAP: tutti questi servizi sono più o meno unici sotto uno o più aspetti. Ognuno ha la propria funzione, le proprie caratteristiche. Esistono diversi modi per ottenere metriche, KPI (indicatori chiave di prestazione), che ti interessano quando il server è sotto carico.
fotografato da su
(Vorrei che i miei cruscotti fossero blu neon - sospirando sognante -... hmm...)
Qualsiasi software che fornisce servizi deve disporre di un meccanismo per raccogliere parametri. Apache ha un modulo mod-status, visualizzando la pagina di stato del server. Nginx ha - stub_status. Tomcat dispone di JMX o applicazioni Web personalizzate che mostrano le metriche chiave. MySQL ha un comando "mostra stato globale" ecc.
Allora perché gli sviluppatori non inseriscono meccanismi simili nelle applicazioni che creano?
Lo fanno solo gli sviluppatori?
Un certo livello di indifferenza verso l’incorporamento delle metriche non è limitato agli sviluppatori. Ho lavorato in aziende in cui sviluppavano applicazioni utilizzando Tomcat e non fornivano nessuna delle loro metriche, nessun registro delle attività del servizio, ad eccezione dei registri generali degli errori Tomcat. Alcuni sviluppatori generano moltissimi log che non significano nulla per l'amministratore di sistema che ha la sfortuna di leggerli alle 3:15 del mattino.
fotografato da su
Anche gli ingegneri di sistema che consentono il rilascio di tali prodotti devono assumersi una certa responsabilità per la situazione. Pochi ingegneri di sistema hanno il tempo o la cura per provare a estrarre parametri significativi dai log, senza il contesto di tali parametri e la capacità di interpretarli alla luce dell'attività dell'applicazione. Alcuni non capiscono come trarne beneficio, a parte gli indicatori “qualcosa è attualmente (o sarà presto) sbagliato”.
Un cambiamento nel modo di pensare riguardo alla necessità di metriche deve avvenire non solo tra gli sviluppatori, ma anche tra gli ingegneri di sistema.
Per qualsiasi ingegnere di sistema che abbia bisogno non solo di rispondere a eventi critici, ma anche di garantire che non si verifichino, la mancanza di parametri rappresenta solitamente un ostacolo nel farlo.
Tuttavia, gli ingegneri di sistema in genere non armeggiano con il codice per guadagnare denaro per la propria azienda. Hanno bisogno di sviluppatori leader che comprendano l'importanza della responsabilità dell'ingegnere di sistema nell'identificazione dei problemi, nella sensibilizzazione sui problemi di prestazione e simili.
Questa cosa distrugge
La mentalità devops descrive la sinergia tra il pensiero di sviluppo (dev) e quello operativo (ops). Qualsiasi azienda che pretenda di “fare devops” deve:
- dire cose che probabilmente non dicono (riferendosi al meme La sposa principessa - "Non penso che significhi quello che pensi che significhi!")
- Incoraggiare un atteggiamento di miglioramento continuo del prodotto.
Non puoi migliorare un prodotto e sapere che è stato migliorato se non sai come funziona attualmente. Non puoi sapere come funziona un prodotto se non capisci come funzionano i suoi componenti, i servizi da cui dipende, i suoi principali punti critici e i colli di bottiglia.
Se non fai attenzione ai potenziali colli di bottiglia, non sarai in grado di seguire la tecnica dei cinque perché quando scrivi un'autopsia. Non sarai in grado di mettere tutto su uno schermo per vedere come funziona un prodotto o sapere come appare "normale e felice".
Spostati a sinistra, SINISTRA, HO DETTO LEEEE—
Per me, uno dei principi chiave del Devops è “shift left”. Spostarsi a sinistra in questo contesto significa spostare la possibilità (nessuna responsabilità, ma solo capacità) per eseguire operazioni che in genere interessano agli ingegneri di sistema, ad esempio creare parametri di prestazione, utilizzare i log in modo più efficiente, ecc., a sinistra nel Ciclo di vita della distribuzione del software.
fotografato da su
Gli sviluppatori di software devono essere in grado di utilizzare e conoscere gli strumenti di monitoraggio che l'azienda utilizza per effettuare il monitoraggio in tutte le sue forme, metriche, logging, interfacce di monitoraggio e, soprattutto, guarda come funziona il loro prodotto nella produzione. Non è possibile convincere gli sviluppatori a investire impegno e tempo nel monitoraggio finché non riescono a vedere le metriche e influenzare il loro aspetto, il modo in cui il proprietario del prodotto le presenta al CTO al briefing successivo, ecc.
In breve
- Conduci il tuo cavallo all'acqua. Mostra agli sviluppatori quanti problemi possono evitare per se stessi, aiutali a identificare i KPI e le metriche giusti per le loro applicazioni in modo che ci siano meno urla da parte del proprietario del prodotto che viene sgridato dal CTO. Portateli alla luce, dolcemente e con calma. Se ciò non funziona, corrompete, minacciate e convincete loro o il proprietario del prodotto a implementare l'acquisizione di queste metriche dalle applicazioni il più rapidamente possibile, quindi disegnate i diagrammi. Ciò sarà difficile in quanto non sarà visto come una priorità e la tabella di marcia del prodotto avrà molti progetti generatori di entrate in sospeso. Pertanto, sarà necessario un business case per giustificare il tempo e i costi spesi per implementare il monitoraggio nel prodotto.
- Aiuta gli ingegneri di sistema a dormire bene la notte. Mostra loro che utilizzare una lista di controllo "rilasciamo" per qualsiasi prodotto rilasciato è una buona cosa. Inoltre, assicurarti che tutte le applicazioni in produzione siano coperte da metriche ti aiuterà a dormire meglio la notte consentendo agli sviluppatori di vedere cosa c'è che non va e dove. Tuttavia, il modo giusto per irritare e frustrare qualsiasi sviluppatore, proprietario di prodotto o CTO è persistere e resistere. Questo comportamento avrà un impatto sulla data di rilascio di qualsiasi prodotto se aspetti di nuovo fino all'ultimo minuto, quindi spostati di nuovo a sinistra e inserisci questi problemi nel tuo piano di progetto il prima possibile. Se necessario, partecipa alle riunioni sui prodotti. Indossa baffi finti e feltro o qualcosa del genere, non fallirà mai. Comunica le tue preoccupazioni, dimostra chiari vantaggi ed evangelizza.
- Assicurarsi che sia lo sviluppo (dev) che le operazioni (ops) comprendano il significato e le conseguenze del passaggio delle metriche del prodotto alla zona rossa. Non lasciare Ops come unico guardiano della salute del prodotto, assicurati che anche gli sviluppatori siano coinvolti (#productsquads).
- I log sono un'ottima cosa, ma lo sono anche le metriche. Combinali e non lasciare che i tuoi tronchi diventino spazzatura in un'enorme palla fiammeggiante di inutilità. Spiega e mostra agli sviluppatori perché nessun altro capirà i loro log, mostra loro cosa vuol dire guardare log inutili alle 3:15 del mattino.
fotografato da su
È tutto. La prossima settimana uscirà il nuovo materiale. Se desideri saperne di più sul corso, ti invitiamo a farlo , che avrà luogo lunedì. E ora stiamo tradizionalmente aspettando i tuoi commenti.
Fonte: habr.com