🥇Monitoraggio fermo? — Lunga vita al monitoraggio

La nostra azienda si occupa principalmente della gestione delle infrastrutture e del supporto tecnico 24 ore su 24 per progetti web dal 2008: abbiamo oltre 400 clienti, il che rappresenta circa il 15% dell'e-commerce in Russia. Pertanto, il supporto presenta un'architettura molto diversificata. Se qualcosa si arresta, dobbiamo ripararlo entro 15 minuti. Ma per capire che si è verificato un guasto, è necessario monitorare il progetto e reagire agli incidenti. E come si fa?

Ritengo che nella creazione di un sistema di monitoraggio adeguato ci sia un problema. Se non ci fosse, il mio discorso si limiterebbe a un solo punto: «Installate, per favore, Prometheus + Grafana e i plugin 1, 2, 3». Sfortunatamente, ora non funziona più così. E il problema principale è che tutti continuano a credere in qualcosa che esisteva nel 2008, in termini di componenti software.

Per quanto riguarda l'organizzazione di un sistema di monitoraggio, oserei dire che… non esistono progetti con un monitoraggio adeguato. E la situazione è così grave che se qualcosa dovesse crollare, c'è il rischio che resti inosservato — tutti sono convinti che «tutto venga monitorato».
È possibile che tutto venga monitorato. Ma come?

Tutti noi abbiamo affrontato una situazione simile: c'è un devops, c'è un admin, e un team di sviluppatori arriva e dice: «Abbiamo fatto il rilascio, ora monitora». Cosa devo monitorare? Come funziona?

Ok. Monitoriamo alla vecchia maniera. Ma intanto tutto cambia, e si scopre che stavi monitorando il servizio A, che è diventato il servizio B, che interagisce con il servizio C. Ma il team di sviluppatori ti dice: «Installa il software, deve monitorare tutto!»

E quindi, cosa è cambiato? — È cambiato tutto!

2008. Tutto andava bene.

C'erano un paio di sviluppatori, un server, un server DB. Da qui inizia tutto. Abbiamo delle informazioni, installiamo Zabbix, Nagios, Cacti. E poi impostiamo allerte chiare su CPU, sul funzionamento dei dischi e sullo spazio disponibile. Facciamo anche un paio di controlli manuali per assicurarci che il sito risponda e che gli ordini arrivino nel database. E questo è tutto – siamo più o meno al sicuro.

Se confrontiamo il volume di lavoro che l'amministratore svolgeva per garantire il monitoraggio, il 98% era automatico: chi si occupa del monitoraggio deve sapere come installare Zabbix, come configurarlo e impostare gli avvisi. E il 2% riguardava controlli esterni: verificare che il sito risponda e faccia una richiesta al database, che nuovi ordini siano arrivati.

2010. Cresce il carico

Iniziamo a scalare i server web, aggiungiamo un motore di ricerca. Vogliamo essere sicuri che il catalogo dei prodotti contenga tutti gli articoli. E che la ricerca dei prodotti funzioni. Che il database sia operativo, che gli ordini possano essere effettuati, che il sito risponda esternamente e risponda bene. server E l'utente non venga espulso dal sito mentre viene bilanciato su un altro server, ecc. Il numero di entità cresce.

Inoltre, l'entità legata all'infrastruttura rimane ancora la più grande nella testa del manager. Rimane in mente l'idea che una persona che si occupa del monitoraggio sia qualcuno che installerà Zabbix e sarà in grado di configurarlo.

Ma nel contempo si avviano lavori per condurre verifiche esterne, creare un insieme di script per le richieste del motore di ricerca, un insieme di script per verificare che la ricerca cambi durante l'indicizzazione, un insieme di script che controlla che i prodotti vengano consegnati al servizio, ecc. ecc.

Notate: ho scritto «insieme di script» tre volte. Cioè, chi è responsabile del monitoraggio non è più solo colui che installa zabbix. È una persona che inizia a programmare. Ma nella testa del team ancora non cambia nulla.

Tuttavia, il mondo cambia, diventando sempre più complesso. Si aggiungono strati di virtualizzazione e diversi nuovi sistemi. Questi cominciano a interagire tra di loro. Chi ha detto «odora di microservizi?» Ma ogni servizio appare ancora come un sito separato. Possiamo accedervi e comprendere che fornisce le informazioni necessarie e funziona da solo. E se sei un amministratore che si occupa costantemente di un progetto che si sviluppa da 5-7-10 anni, queste conoscenze si accumulano: appare un nuovo livello — lo hai realizzato, se ne presenta un altro — lo hai realizzato...

Ma raramente qualcuno segue un progetto per 10 anni.

Riassunto del monitoring

Immagina di essere arrivato in una startup nuova che ha subito assunto 20 sviluppatori, scritto 15 microservizi, e tu sei l'amministratore che viene interpellato: «Costruisci CI/CD. Per favore». Hai costruito CI/CD e all'improvviso senti: «È difficile lavorare con la produzione nel 'cubo', senza capire come funzionerà l'applicazione al suo interno. Fai per noi un ambiente sandbox in questo stesso 'cubo'.
Crei un ambiente sandbox in questo cubo. Ti dicono subito: «Vogliamo un database di staging che si aggiorni ogni giorno dalla produzione, così da comprendere se funziona con il database, ma senza rovinare il database di produzione».

Vivi tutto ciò. Mancano 2 settimane al rilascio, ti dicono: «Ora dobbiamo monitorare tutto questo...», ovvero monitorare l'infrastruttura cluster, monitorare l'architettura dei microservizi, monitorare i processi con i servizi esterni...

E i colleghi tirano fuori il loro schema abituale e dicono: «Ma qui è tutto chiaro! Installa un programma che monitora tutto questo». Già, esatto: Prometheus + Grafana + plugin.
E aggiungono: «Hai circa due settimane, fai in modo che tutto sia affidabile».

In molti progetti che vediamo, viene assegnata una persona per il monitoraggio. Immaginate di voler assumere una persona per due settimane che si occupi del monitoraggio, e stiamo preparando il suo curriculum. Quali competenze dovrebbe avere questa persona, considerando tutto ciò che abbiamo detto finora?

Deve comprendere il monitoraggio e le specificità del lavoro delle infrastrutture hardware.
Deve comprendere le specificità del monitoraggio di Kubernetes (tutti vogliono il «cubo», perché consente di astrarsi da tutto, nascondersi, dato che l'amministratore si occupa del resto) — della tecnologia stessa, della sua infrastruttura, e sapere come monitorare le applicazioni al suo interno.
Deve capire che i servizi comunicano tra loro in modi particolari e conoscere le specifiche dell'interazione tra i servizi. È molto reale vedere un progetto in cui alcuni servizi comunicano in modo sincrono, perché non ci sono altre possibilità. Ad esempio, il backend utilizza REST, e si connette in gRPC al servizio di catalogo, ricevendo un elenco di prodotti e restituendolo indietro. Qui non è possibile attendere. Con altri servizi, invece, lavora in modo asincrono. Deve inviare un ordine al servizio di consegna, inviare un'email, ecc.
Probabilmente ti sei già perso in tutto questo? E l'amministratore che deve monitorarlo è ancora più confuso.
Deve saper pianificare e farlo correttamente, poiché il lavoro sta aumentando sempre di più.
Deve, quindi, sviluppare una strategia dal servizio creato per capire come monitorarlo specificamente. Ha bisogno di comprendere l'architettura del progetto e il suo sviluppo, oltre a conoscere le tecnologie utilizzate nello sviluppo.

Rivisitiamo un caso assolutamente normale: parte dei servizi è in PHP, parte in Go, parte in JS. Funzionano in qualche modo tra loro. Da qui deriva il termine «microservizio»: sono diventati così tanti i sistemi separati che gli sviluppatori non possono comprendere il progetto nel suo complesso. Una parte del team scrive servizi in JS, che funzionano autonomamente e non sanno come lavora il resto del sistema. Un'altra parte scrive servizi in Python e non interferisce con il funzionamento degli altri servizi, sono isolati nella loro area. La terza parte scrive servizi in PHP o in qualche altro linguaggio.
Queste 20 persone sono suddivise in 15 servizi, e c'è solo un admin che deve comprendere tutto questo. Aspetta! Abbiamo appena diviso il sistema in 15 microservizi, perché 20 persone non possono capire l'intero sistema.

Tuttavia, deve essere monitorato in qualche modo...

E alla fine? C'è una persona che tiene in testa tutto ciò che non riesce a comprendere un'intera squadra di sviluppatori, e allo stesso tempo deve conoscere e saper fare quanto indicato sopra — infrastruttura hardware, infrastruttura Kubernetes, ecc.

Cosa dire… Houston, abbiamo un problema.

Il monitoraggio di un progetto software moderno è esso stesso un progetto software.

Da una falsa certezza che il monitoraggio sia semplice software, nasce la convinzione nei miracoli. Ma, purtroppo, i miracoli non esistono. Non puoi semplicemente installare Zabbix e aspettarti che tutto funzioni. Non ha senso installare Grafana e sperare che tutto vada bene. La maggior parte del tempo verrà spesa nell'organizzare i controlli del funzionamento dei servizi e delle loro interazioni, oltre a verificare il funzionamento dei sistemi esterni. In effetti, il 90% del tempo non sarà dedicato alla scrittura di script, ma allo sviluppo del software. E questa deve essere una squadra che comprenda il funzionamento del progetto.
Se in questa situazione si affida il monitoraggio a una sola persona, si verificherà un disastro. Ed è esattamente ciò che accade ovunque.

Ad esempio, ci sono diversi servizi che comunicano tra loro tramite Kafka. È arrivato un ordine e abbiamo inviato un messaggio dell'ordine a Kafka. C'è un servizio che ascolta le informazioni sull'ordine e gestisce la spedizione del prodotto. C'è un altro servizio che ascolta le informazioni sull'ordine e invia un'email all'utente. Poi si aggiungono altri servizi e cominciamo a confonderci.

E se affiderete tutto questo agli amministratori e agli sviluppatori quando manca poco al rilascio, la persona dovrà comprendere interamente questo protocollo. Quindi, un progetto di tale portata richiede tempo significativo, e nella progettazione del sistema questo deve essere preso in considerazione.
Ma molto spesso, soprattutto nelle fasi iniziali, negli startup, vediamo come il monitoraggio venga rimandato. "Ora faremo un Proof of Concept, lo avvieremo, se fallisce va bene, siamo pronti a sacrificare. E poi faremo tutto il monitoraggio". Quando (o se) il progetto inizia a generare reddito, l'azienda desidera implementare ancora più funzionalità — perché ha iniziato a funzionare, quindi bisogna continuare a potenziare! E voi vi trovate in un punto in cui all'inizio dovete monitorare tutto quello che è stato fatto in precedenza, il che richiede molto più del 1% del tempo. Inoltre, per il monitoraggio sono necessari sviluppatori, ma è più facile dedicarli a nuove funzionalità. Alla fine, vengono scritte nuove funzionalità, tutto si accumula, e voi vi trovate in un loop infinito di deadlock.

Come si può monitorare un progetto partendo dall'inizio, e cosa fare se vi trovate con un progetto da monitorare, ma non sapete da dove cominciare?

In primo luogo, è necessario pianificare.

Un'interruzione lirica: molto spesso si inizia con il monitoraggio delle infrastrutture. Ad esempio, noi utilizziamo Kubernetes. Iniziamo installando Prometheus con Grafana e aggiungendo plugin per il monitoraggio dei «cubetti». Non solo gli sviluppatori, ma anche gli amministratori hanno la sfortunata pratica di dire: «Installeremo questo plugin, e questo plugin saprà come fare». Le persone amano iniziare con cose semplici e comprensibili, piuttosto che con azioni importanti. E il monitoraggio delle infrastrutture è semplice.

Per cominciare, decidete cosa e come volete monitorare, e poi scegliete lo strumento, perché gli altri non possono pensare per voi. E dovrebbero farlo? Altri hanno pensato per se stessi, per un sistema universale — oppure non hanno affatto pensato quando hanno scritto quel plugin. E il fatto che quel plugin abbia 5000 utenti non significa che porti qualche beneficio. È possibile che voi diventiate il 5001° semplicemente perché c'erano già 5000 persone prima di voi.

Se hai iniziato a monitorare l'infrastruttura e il backend della tua applicazione ha smesso di rispondere, tutti gli utenti perderanno la connessione con l'app mobile. Verrà visualizzato un errore. Ti verranno a dire: «L'app non funziona, cosa state facendo?» — «Stiamo monitorando». — «Come potete monitorare se non vedete che l'app non funziona?!»

Ritengo che il monitoraggio debba iniziare proprio dal punto di accesso dell'utente. Se l'utente non vede che l'app funziona, tutto è perduto. Inoltre, il sistema di monitoraggio deve avvisare prima di tutto di questo.
Solo dopo possiamo monitorare l'infrastruttura. O farlo parallelamente. Con l'infrastruttura è più semplice — qui, finalmente, possiamo semplicemente installare zabbix.
Ora dobbiamo andare alle radici dell'applicazione per capire cosa non funziona.

Il mio pensiero principale è che il monitoraggio dovrebbe procedere parallelamente al processo di sviluppo. Se stacchi il team di monitoraggio su altre attività (creazione di CI/CD, sandbox, riorganizzazione dell'infrastruttura), il monitoraggio inizierà a restare indietro e potresti non riuscire mai più a tenere il passo con lo sviluppo (o prima o poi dovrai fermarlo).

Tutto a livelli

Ecco come vedo l'organizzazione del sistema di monitoraggio.

1) Livello dell'applicazione:

monitoraggio della logica di business dell'applicazione;
monitoraggio delle metriche di salute dei servizi;
monitoraggio dell'integrazione.

2) Livello dell'infrastruttura:

monitoraggio del livello di orchestrazione;
monitoraggio del software di sistema;
monitoraggio del livello hardware.

3) Nuovamente il livello dell'applicazione — ma ora come prodotto ingegneristico:

raccolta e analisi dei log dell'applicazione;
APM;
tracing.

4) Alerting:

organizzazione del sistema di allerta;
organizzazione del sistema di turni;
organizzazione di una base di conoscenze e workflow per la gestione degli incidenti.

Importante: arriviamo all'alerting non dopo, ma subito! Non è necessario avviare il monitoraggio e poi pensare a chi riceverà le allerte. Infatti, qual è la funzione del monitoraggio: capire dove nel sistema qualcosa non funziona e farlo sapere alle persone giuste. Se ciò viene lasciato per ultimo, le persone giuste scopriranno che qualcosa non va solo con una telefonata che dice "nulla funziona".

Livello dell'applicazione — monitoraggio della logica di business

Qui si tratta di verificare che l'applicazione funzioni per l'utente.

Questo livello deve essere realizzato nella fase di sviluppo. Ad esempio, abbiamo un ipotetico Prometheus: si connette a un server che esegue controlli, interroga un endpoint e quest'ultimo verifica l'API.

Quando viene chiesto frequentemente di monitorare la homepage per assicurarsi che il sito funzioni, i programmatori forniscono un endpoint che si può interrogare ogni volta che è necessario controllare se l'API è attiva. Nel frattempo, scrivono anche "/api/test/helloworld".
Qual è l'unico modo per essere certi che tutto funzioni? — No!

La creazione di questi controlli è, in sostanza, compito degli sviluppatori. I test unitari devono essere scritti dai programmatori che scrivono il codice. Perché, se lo lasciate all'amministratore con "Ehi, ecco la lista dei protocolli API di tutte e 25 le funzioni, per favore monitora tutto!" — non funzionerà.
Se scrivi un print “hello world”, nessuno saprà mai che l'API dovrebbe funzionare e effettivamente funziona. Ogni modifica all'API dovrebbe comportare una modifica dei controlli.
Se ti trovi già in questa situazione, fermati con le nuove funzionalità e riunisci gli sviluppatori per scrivere questi controlli, oppure accetta le perdite e rassegnati al fatto che nulla verrà controllato e che ci saranno dei crolli.

Consigli tecnici:

Assicurati di configurare un server esterno per le verifiche — devi essere certo che il tuo progetto sia accessibile al mondo esterno.
Organizza le verifiche su tutto il protocollo API, non solo su endpoint specifici.
Crea un endpoint prometheus con i risultati delle verifiche.

Livello applicativo — monitoraggio delle metriche di salute

Ora parliamo delle metriche di salute esterne dei servizi.

Abbiamo deciso di monitorare tutte le "api" dell'applicazione tramite verifiche esterne, che chiamiamo da un sistema di monitoraggio esterno. Ma queste sono precisamente le "api" che l'utente "vede". Vogliamo essere certi che i servizi stessi funzionino. Qui la situazione è migliore: in K8s ci sono controlli di salute affinché almeno il "cubetto" verifichi che il servizio funzioni. Ma la metà dei controlli che ho visto sono il solito print "hello world". Cioè, lo chiama una volta dopo il deploy, e riceve una risposta che va tutto bene — e basta. Un servizio, se espone la sua API tramite REST, ha a disposizione un'enorme quantità di punti di accesso della stessa API, che devono essere monitorati, perché vogliamo sapere se funziona. E lo monitoriamo già dall'interno.

Come implementarlo correttamente dal punto di vista tecnico: ogni servizio espone un endpoint sulla propria attuale funzionalità e nei grafici di Grafana (o di qualunque altra applicazione) vediamo lo stato di tutti i servizi.

Ogni modifica dell'API deve comportare una modifica dei controlli.
Creare un nuovo servizio subito con metriche di salute.
L'amministratore può avvicinarsi agli sviluppatori e chiedere: "Aggiungetemi alcune funzionalità affinché io possa comprendere e inserire queste informazioni nel mio sistema di monitoraggio". Ma di solito gli sviluppatori rispondono: "Non aggiungeremo nulla due settimane prima del rilascio."
I manager dello sviluppo devono essere consapevoli che ci saranno tali perdite, e anche i dirigenti dei manager dello sviluppo devono esserlo. Perché, quando tutto crolla, qualcuno chiamerà comunque e richiederà di monitorare il "servizio costantemente in caduta" (c).
A proposito, allocate agli sviluppatori il tempo per scrivere plugin per Grafana — sarà un buon aiuto per gli amministratori.

Livello applicativo — Monitoraggio dell'integrazione

Il monitoraggio dell'integrazione si concentra sul monitoraggio della comunicazione tra sistemi critici per il business.

Ad esempio, ci sono 15 servizi che comunicano tra loro. Non sono più siti separati. Cioè, non possiamo chiamare un servizio da solo, ottenere /helloworld e capire che il servizio funziona. Questo perché il servizio di elaborazione degli ordini deve inviare informazioni sull'ordine al bus — il servizio che gestisce il magazzino deve ricevere questo messaggio dal bus e lavorarci ulteriormente. E il servizio di invio e-mail deve elaborarlo in un altro modo, e così via.

Di conseguenza, non possiamo capire, cercando ogni singolo servizio, se tutto questo funziona. Perché abbiamo un certo bus attraverso il quale tutto comunica e interagisce.
Quindi questo passaggio deve rappresentare la fase di test dei servizi in interazione con altri servizi. Non è possibile organizzare il monitoraggio della comunicazione solo monitorando il broker dei messaggi. Se c'è un servizio che fornisce dati e un servizio che li riceve, durante il monitoraggio del broker vedremo solo i dati che viaggiano avanti e indietro. Anche se fossimo in grado di monitorare l'interazione di questi dati internamente — che un certo produttore pubblica dati, qualcuno li legge, e questo flusso continua a viaggiare in Kafka — non otterremo comunque informazioni se un servizio ha inviato un messaggio in una versione mentre l'altro servizio non si aspettava quella versione e l'ha ignorato. Non lo scopriremo, poiché i servizi ci diranno che tutto funziona.

Come consiglio di procedere:

Per la comunicazione sincrona: l'endpoint effettua richieste ai servizi correlati. Cioè, prendiamo questo endpoint, attiviamo uno script all'interno del servizio che esplora tutti i punti e dice 'posso chiamare qui, e posso chiamare lì, posso chiedere…'
Per comunicazione asincrona: i messaggi in ingresso — l'endpoint controlla il bus per vedere se ci sono messaggi di test e restituisce lo stato di elaborazione.
Per comunicazione asincrona: i messaggi in uscita — l'endpoint invia messaggi di test al bus.

Come succede di solito: abbiamo un servizio che invia dati al bus. Ci rivolgiamo a questo servizio e chiediamo informazioni sul suo stato di integrazione. Se il servizio deve produrre un messaggio da inoltrare (WebApp), lo produce. Se interagiamo con il servizio dalla parte di OrderProcessing, prima pubblica ciò che può pubblicare in modo indipendente, e se ci sono elementi dipendenti, legge dal bus un insieme di messaggi di test, comprende quali può elaborare, lo comunica e, se necessario, li pubblica ulteriormente, e dice: tutto ok, sono attivo.

Molto spesso sentiamo la domanda "come possiamo testare questo con dati live?" Ad esempio, si tratta dello stesso servizio ordini. L'ordine invia messaggi al magazzino, dove vengono prelevati i prodotti: non possiamo testare questo con dati live, perché "i miei prodotti saranno prelevati!" La soluzione: pianificare tutto questo test fin dall'inizio. Avete già unit test che generano mock. Fatelo quindi a un livello più profondo, dove avrete un canale di comunicazione che non danneggerà l'operatività del business.

Livello infrastrutturale

Il monitoraggio dell'infrastruttura è stato a lungo considerato il monitoraggio stesso.

Il monitoraggio dell'infrastruttura può e deve essere avviato come processo separato.
Non iniziare dal monitoraggio dell'infrastruttura in un progetto operativo, anche se lo desideri fortemente. Questo è un problema comune per tutti i DevOps. "Inizierò monitorando il cluster, monitorerò l'infrastruttura" — cioè, prima si occuperà di ciò che è sottostante e non si occuperà dell'applicazione. Perché l'applicazione è una cosa complicata per un DevOps. Gli è stata data e non capisce come funziona. Ma comprende l'infrastruttura e inizia da essa. Ma no, bisogna sempre monitorare prima l'applicazione.
Non esagerare con il numero di avvisi. Considerando la complessità dei sistemi moderni, gli allarmi arrivano continuamente e bisogna convivere con questa moltitudine di avvisi. Una persona di turno, guardando centinaia di avvisi, dirà: "Non voglio pensarci". Gli avvisi devono segnalare solo le cose critiche.

Il livello dell'applicazione come unità di business

Punti chiave:

ELK. È lo standard del settore. Se per qualche motivo non aggrega i log, inizia a farlo immediatamente.
APM. APM esterni come modo per chiudere rapidamente il monitoraggio dell'applicazione (NewRelic, BlackFire, Datadog). Puoi installare temporaneamente questo strumento per avere un'idea di cosa stia succedendo.
Tracciamento. Nei numerosi microservizi è necessario traccare tutto, poiché la richiesta non esiste più da sola. Aggiungerlo in seguito è molto difficile, quindi è meglio pianificare il tracciamento durante lo sviluppo — è un lavoro e uno strumento per gli sviluppatori. Se non è ancora stato implementato, implementatelo! Vedi Jaeger/Zipkin

Allerta

Organizzazione del sistema di avvisi: nel contesto del monitoraggio di molteplici elementi deve esserci un sistema unico di invio degli avvisi. Può essere fatto in Grafana. In Occidente tutti usano PagerDuty. Gli avvisi devono essere chiari (ad esempio, da dove provengono…). E sarebbe preferibile controllare che gli avvisi arrivino effettivamente.
Organizzazione del sistema di turni: gli avvisi non devono arrivare a tutti (altrimenti tutti reagiranno in massa, oppure nessuno reagirà). Anche gli sviluppatori devono essere reperibili: è fondamentale definire le aree di responsabilità, creare istruzioni chiare e specificare a chi chiamare il lunedì e il mercoledì, e a chi il martedì e il venerdì (altrimenti non chiameranno nessuno nemmeno in caso di grande emergenza — temeranno di disturbare: le persone generalmente non amano chiamare e svegliare gli altri, specialmente di notte). E spiegate che chiedere aiuto non è un segno di incompetenza («chiedo aiuto — quindi sono un cattivo lavoratore»), incoraggiate le richieste di aiuto.
Organizzazione della «knowledge base» e del workflow di gestione degli incidenti: per ogni incidente serio deve essere pianificato un postmortem, come misura temporanea devono essere registrate le azioni che risolveranno l'incidente. E attuate la pratica che gli avvisi ripetuti sono inaccettabili; devono essere risolti nel codice o nelle operazioni infrastrutturali.

Stack tecnologico

Immaginiamo che il nostro stack sia il seguente:

raccolta dati — Prometheus + Grafana;
analisi dei log — ELK;
per APM o Tracing — Jaeger (Zipkin).

La scelta delle opzioni non è critica. Infatti, se all'inizio hai capito come monitorare il sistema e hai scritto un piano, poi inizi a scegliere gli strumenti in base alle tue esigenze. La questione è cosa hai scelto di monitorare per prima cosa. Perché, potrebbe essere che lo strumento che hai scelto all'inizio non si adatta affatto alle tue necessità.

Alcuni aspetti tecnici che vedo ovunque di recente:

Chi ha avuto l'idea di inserire Prometheus all'interno di Kubernetes?! Se il tuo cluster va giù, cosa farai? Se all'interno hai un cluster complesso, deve funzionare un sistema di monitoraggio interno, e ce ne deve essere uno esterno che raccolga dati dall'interno del cluster.

All'interno del cluster raccogliamo i log e tutto il resto. Ma il sistema di monitoraggio deve essere all'esterno. Molto spesso, in un cluster dove è presente Prometheus installato internamente, ci sono anche sistemi che effettuano controlli esterni del funzionamento del sito. E se le connessioni con il mondo esterno sono crollate e l'applicazione non funziona? Si finisce per avere tutto in ordine all'interno, ma agli utenti non sarà più facile.

Conclusioni

Lo sviluppo del monitoraggio non consiste semplicemente nell'installare utility, ma è un vero e proprio sviluppo di un prodotto software. Il 98% del monitoraggio attuale si basa su codifica: codifica nei servizi, codifica dei controlli esterni, verifiche dei servizi esterni e così via.
Non risparmiate il tempo degli sviluppatori per il monitoraggio: può richiedere fino al 30% del loro lavoro, ma ne vale la pena.
DevOps, non preoccupatevi se non riuscite a monitorare qualcosa, perché alcune cose richiedono un approccio completamente diverso. Non siete stati programmatori, e il compito del monitoraggio è proprio il loro.
Se il progetto è già operativo e non è stato monitorato (e voi siete il manager), allocate risorse per il monitoraggio.
Se il prodotto è già in produzione e voi siete un DevOps che ha ricevuto l'istruzione di 'impostare il monitoraggio', cercate di spiegare alla direzione quello di cui ho appena parlato.

Questa è una versione ampliata della presentazione alla conferenza Saint Highload++.

Se siete interessati alle mie idee e riflessioni riguardo a temi IT e argomenti affini, potete leggere il canale 🙂

Fonte: habr.com