Monitoraggio morto? — 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 più di 400 clienti, che rappresentano circa il 15% dell'e-commerce in Russia. Di conseguenza, ci sono architetture molto varie nel supporto. Se qualcosa si guasta, dobbiamo ripararlo entro 15 minuti. Ma per capire che è avvenuta un'emergenza, è necessario monitorare il progetto e reagire agli incidenti. E come si fa?

Ritengo che, nell'organizzazione di un sistema di monitoraggio adeguato, ci siano problemi. Se non ci fossero problemi, il mio discorso si limiterebbe a un unico punto: «Installate per favore Prometheus + Grafana e i plugin 1, 2, 3». Sfortunatamente, ora non funziona così. E il problema principale è che tutti continuano a credere a qualcosa che esisteva nel 2008, in termini di componenti software.

Per quanto riguarda l'organizzazione di un sistema di monitoraggio, mi azzardo a dire che... i progetti con un monitoraggio adeguato non esistono. E la situazione è così grave che se qualcosa fallisce, c'è il rischio che rimanga inosservato – tutti sono convinti che «tutto sia monitorato».
Forse, tutto è monitorato. Ma come?

Tutti noi ci siamo imbattuti in storie simili alla seguente: un certo devops, un certo admin, ricevono una squadra di sviluppatori che dice – «abbiamo fatto il rilascio, ora monitorate». Cosa monitoriamo? Come funziona?

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

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

2008. Tutto andava bene.

Ci sono un paio di sviluppatori, un server, un server DB. Da qui inizia tutto. Abbiamo alcune informazioni, installiamo zabbix, Nagios, cacti. E poi impostiamo avvisi chiari su CPU, sull'attività dei dischi, sullo spazio disponibile sui dischi. Inoltre, facciamo un paio di controlli manuali, per assicurarci che il sito risponda, che gli ordini arrivino nel database. E poi – siamo più o meno protetti.

Se confrontiamo la quantità di lavoro che l'amministratore doveva svolgere allora per garantire il monitoraggio, il 98% era automatizzato: la persona che si occupa del monitoraggio deve capire come installare Zabbix, come configurarlo e impostare le allerte. E il 2% è dedicato ai controlli esterni: se il sito risponde e fa richieste al database, se sono arrivati nuovi ordini.

Anno 2010. Aumenta il carico

Iniziamo a scalare i web, aggiungiamo un motore di ricerca. Vogliamo essere certi che il catalogo dei prodotti contenga tutti i prodotti. E che la ricerca dei prodotti funzioni. Che il database funzioni, che gli ordini vengano effettuati, che il sito risponda esternamente e risponda da due server e all'utente non venga espulso dal sito finché non viene riequilibrato su un altro server, e così via. Il numero delle entità aumenta.

Inoltre, l'entità legata all'infrastruttura rimane ancora la più grande nella testa del manager. L'idea che la persona responsabile del monitoraggio sia quella che installa Zabbix e sa configurarlo continua a persistere.

Ma nel frattempo compaiono lavori per eseguire controlli esterni, per creare un insieme di script per le richieste dell'indice di ricerca, un insieme di script per verificare che la ricerca cambi durante l'indicizzazione, un insieme di script che controllano che i prodotti vengano trasferiti al servizio di consegna, ecc. ecc.

Notate: ho scritto "insieme di script" tre volte. Quindi chi è responsabile del monitoraggio non è più semplicemente chi installa Zabbix. È una persona che inizia a programmare. Ma nella testa del team nulla cambia ancora.

Eppure il mondo cambia, diventando sempre più complesso. Viene aggiunto uno strato di virtualizzazione, diversi nuovi sistemi. Iniziano a interagire tra loro. Chi ha detto "sembra microservizi?" Ma ogni servizio continua a sembrare un sito separato. Possiamo accedervi e capire che fornisce le informazioni necessarie e funziona autonomamente. E se sei un amministratore che si occupa continuamente di un progetto che si sviluppa da 5-7-10 anni, queste conoscenze si accumulano: emerge un nuovo livello - lo hai compreso, emerge un ulteriore livello - lo hai compreso…

Ma raramente qualcuno accompagna un progetto per 10 anni.

Riepilogo del monitoraggio

Supponiamo che tu sia arrivato in una nuova startup, che ha subito assunto 20 sviluppatori, ha scritto 15 microservizi, e tu — sei l'amministratore, a cui dicono: «Costruisci CI/CD. Per favore». Hai costruito CI/CD e all'improvviso senti: «È difficile lavorare con la produzione nel 'cubetto', senza capire come funzionerà l'applicazione al suo interno. Fai una sandbox in questo 'cubetto'.
Hai creato una sandbox in questo cubetto. Ti dicono subito: «Vogliamo un database di stadio, che si aggiorni ogni giorno dalla produzione, per capire se funziona sul database, ma senza rovinare il database di produzione».

Tu vivi tutto questo. Mancano 2 settimane al rilascio, ti dicono: «Ora dobbiamo monitorare tutto...». Cioè, monitorare l'infrastruttura cluster, monitorare l'architettura microservizi, monitorare il lavoro con i servizi esterni...

E i colleghi tirano fuori una soluzione abituale e dicono: «Ma qui è tutto chiaro! Installa un programma che monitori tutto». Sì: Prometheus + Grafana + plugin.
E aggiungono: «Hai circa due settimane, fai in modo che sia tutto affidabile».

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

• Deve comprendere il monitoraggio e la specificità del lavoro dell'infrastruttura hardware.
• Deve capire la specificità del monitoraggio di Kubernetes (tutti vogliono nel 'cubetto', perché si può astrarsi da tutto, nascondersi, visto che l'amministratore si occuperà del resto) — di per sé, della sua infrastruttura e capire come monitorare le applicazioni interne.
• Deve comprendere che i servizi comunicano tra loro in modi particolari e conoscere le specificità dell'interazione tra i servizi. È completamente possibile vedere un progetto in cui parte dei servizi comunicano in modo sincrono, perché non si può fare diversamente. Ad esempio, il backend va via REST, via gRPC al servizio catalogo, ottiene un elenco di prodotti e restituisce indietro. Qui non si può aspettare. E con altri servizi lavora in modo asincrono. Trasmettere un ordine al servizio di consegna, inviare un'email e così via.
  Probabilmente ti sei già perso in tutto questo? E l'amministratore, che deve monitorarlo, è ancora più in difficoltà.
• Deve saper pianificare e pianificare correttamente, poiché il lavoro sta aumentando sempre di più.
• Deve quindi creare una strategia del servizio creato per capire come monitorarlo concretamente. Ha bisogno di comprendere l'architettura del progetto e il suo sviluppo, oltre a avere una comprensione delle tecnologie utilizzate nello sviluppo.

Ricordiamo un caso assolutamente normale: una parte dei servizi è scritta in php, un'altra parte in Go, un'altra ancora in JS. Funzionano in qualche modo tra di loro. Da qui deriva il termine "microservizio": ci sono così tanti sistemi separati che gli sviluppatori non riescono a comprendere il progetto nel suo insieme. Una parte del team scrive servizi in JS che funzionano autonomamente e non sanno come funziona il resto del sistema. Un'altra parte scrive servizi in Python e non si preoccupa di come funzionano gli altri servizi, sono isolati nel loro ambito. Un terzo gruppo scrive servizi in php o in qualcos'altro.
Tutte queste 20 persone sono divise su 15 servizi e c'è solo un amministratore che deve capire tutto questo. Stop! abbiamo appena suddiviso il sistema in 15 microservizi, perché 20 persone non riescono a comprendere l'intero sistema.

Eppure deve essere monitorato in qualche modo...

Qual è il risultato? Alla fine c'è una persona che comprende tutto ciò che non può comprendere un intero team di sviluppatori, e che deve anche conoscere e saper fare ciò che abbiamo indicato sopra: l'infrastruttura hardware, l'infrastruttura Kubernetes, ecc.

Cosa dire a riguardo... Houston, abbiamo un problema.

Il monitoraggio di un moderno progetto software è di per sé un progetto software.

Dalla falsa convinzione che il monitoraggio sia un software, nasce la nostra fiducia nei miracoli. E, purtroppo, i miracoli non esistono. Non si può semplicemente installare zabbix e aspettarsi che tutto funzioni. Non ha senso installare Grafana e sperare che vada tutto bene. La maggior parte del tempo sarà dedicata all'organizzazione dei controlli sul funzionamento dei servizi e delle loro interazioni reciproche, e al controllo di come funzionano i sistemi esterni. Infatti, il 90% del tempo non sarà dedicato alla scrittura di script, ma allo sviluppo del software. E questo compito deve essere svolto da un team che comprende il funzionamento del progetto.
Se in questa situazione si mette una sola persona a occuparsi del monitoraggio, allora si verifica un disastro. Ed è esattamente ciò che accade ovunque.

Ad esempio, ci sono diversi servizi che comunicano tra di loro tramite Kafka. Quando arriva un ordine, inviamo il messaggio dell'ordine a Kafka. C'è un servizio che ascolta le informazioni sull'ordine e gestisce la spedizione della merce. C'è un altro servizio che ascolta le informazioni sull'ordine e invia una email all'utente. Poi ci sono molti altri servizi, e cominciamo a confonderci.

E se poi lo date anche all'amministratore e agli sviluppatori in un momento in cui resta poco tempo fino al rilascio, la persona deve capire tutto questo protocollo. Cioè, un progetto di tale portata richiede molto tempo, e questo deve essere previsto nello sviluppo del sistema.
Ma molto spesso, soprattutto in fase di avvio, vediamo come il monitoraggio venga rimandato. "Ora faremo un Proof of Concept, lanceremo con quello, anche se cade – siamo pronti a sacrificare. E poi monitoreremo tutto." Quando (o se) il progetto inizia a generare entrate, l'azienda vuole implementare ancora più funzionalità — perché ha cominciato a funzionare, quindi bisogna continuare a espandere! Ma ti trovi in un punto in cui all'inizio devi monitorare tutto ciò che è stato fatto, il che richiede molto più del 1% del tempo. E, tra l'altro, per il monitoraggio servono sviluppatori, e risulta più semplice destinarli a nuove funzionalità. Alla fine vengono scritte nuove funzionalità, tutto si accumula, e ti trovi in un deadlock infinito.

Quindi, come monitorare un progetto fin dall'inizio, e cosa fare se ti capita di dover monitorare un progetto ma non sai da dove cominciare?

Innanzitutto, è necessario pianificare.

Una nota lirica: molto spesso si inizia con il monitoraggio dell'infrastruttura. Ad esempio, abbiamo Kubernetes. Iniziamo installando Prometheus con Grafana, installiamo plugin per il monitoraggio del 'cubetto'. Non solo gli sviluppatori, ma anche gli amministratori seguono una pratica infelice: 'Installeremo questo plugin, e il plugin sicuramente sa come farlo'. Le persone amano iniziare con cose semplici e comprensibili, piuttosto che con azioni cruciali. E il monitoraggio dell'infrastruttura è semplice.

Per iniziare, determinate cosa e come volete monitorare, e poi scegliete lo strumento giusto, perché altre persone non possono pensare per voi. E devono farlo? Altre persone hanno pensato a se stesse, a un sistema universale — o non hanno pensato affatto, quando hanno scritto questo plugin. E il fatto che questo plugin abbia 5 mila utenti non significa che porti qualche beneficio. Potreste diventare il 5001° solo perché prima di voi ci sono già stati 5000 utenti.

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

1. Ritengo che il monitoraggio debba iniziare proprio dal punto di ingresso dell'utente. Se l'utente non vede che l'app funziona — è un fallimento. E il sistema di monitoraggio deve avvisare riguardo a ciò prima di tutto.
2. Solo dopo possiamo monitorare l'infrastruttura. O farlo parallelamente. Con l'infrastruttura è più semplice — qui finalmente possiamo semplicemente installare Zabbix.
3. E ora dobbiamo andare alla radice dell'applicazione per capire dove qualcosa non funziona.

Il mio pensiero principale è che il monitoraggio deve andare di pari passo con il processo di sviluppo. Se distogliete il team di monitoraggio su altre attività (creazione di CI/CD, sandbox, riorganizzazione dell'infrastruttura), il monitoraggio inizierà a rimanere indietro e forse non recupererete mai lo sviluppo (o prima o poi dovrete fermarlo).

Tutto per livelli

Ecco come vedo l'organizzazione del sistema di monitoraggio.

1) Livello dell'applicazione:

• monitoraggio della logica aziendale 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) Ancora un livello dell'applicazione — ma come prodotto ingegneristico:

• raccolta e osservazione dei log dell'applicazione;
• APM;
• tracciamento.

4) Allerta:

• organizzazione del sistema di avviso;
• organizzazione del sistema di turni;
• organizzazione di una «base di conoscenza» e workflow per la gestione degli incidenti.

Importante: arriviamo all’allerta non dopo, ma subito! Non bisogna avviare il monitoraggio e poi pensare a chi devono arrivare gli alert «in un secondo momento». Infatti, qual è l'obiettivo del monitoraggio? Capire dove nel sistema c’è qualcosa che non funziona e informare le persone giuste. Se lasci questo per dopo, le persone giuste scopriranno che qualcosa non va solo quando riceveranno una chiamata «non funziona niente».

Livello applicativo – monitoraggio della logica aziendale

Si tratta di controllare se l'applicazione funziona per l'utente.

Questo livello deve essere realizzato durante la fase di sviluppo. Per esempio, abbiamo un Prometheus convenzionale: si collega al server che si occupa dei controlli, richiama un endpoint e quest'ultimo verifica l'API.

Quando spesso chiedono di monitorare la homepage per assicurarsi che il sito funzioni, i programmatori forniscono un endpoint che può essere richiamato ogni volta che è necessario verificare che l'API funzioni. E mentre fanno questo, i programmatori scrivono anche /api/test/helloworld
L'unico modo per essere certi che tutto funzioni? – No!

• La creazione di tali controlli è, in sostanza, compito dei programmatori. I test unitari devono essere scritti dai programmatori che scrivono il codice. Perché, se lo affidi a un admin dicendo «Ehi, ecco un elenco dei protocolli API per tutte e 25 le funzioni, per favore, monitora tutto!» – non servirà a nulla.
• Se fai print “hello world”, nessuno saprà mai che l'API deve e funziona effettivamente. Ogni modifica dell'API deve comportare una modifica dei controlli.
• Se hai già questo problema, interrompi le funzionalità e assegna programmatori che scriveranno questi controlli, oppure rassegnati alle perdite, accettando che nulla venga verificato e che tutto cadrà.

Consigli tecnici:

• Assicurati di organizzare un server esterno per i controlli – devi essere certo che il tuo progetto sia accessibile al mondo esterno.
• Organizza il monitoraggio di tutto il protocollo API, non solo di singoli endpoint.
• Crea un endpoint Prometheus con i risultati dei controlli.

Livello applicativo – monitoraggio delle metriche di salute

Ora si parla delle metriche di salute esterne dei servizi.

Abbiamo deciso che monitoreremo tutte le "maniglie" dell'applicazione utilizzando controlli esterni, che chiamiamo da un sistema di monitoraggio esterno. Ma queste sono proprio le "maniglie" che l'utente "vede". Vogliamo essere sicuri che i servizi stessi funzionino. Qui la situazione è migliore: in K8s ci sono controlli di salute, affinché almeno il "cubo" possa verificare che il servizio funziona. Ma la metà dei controlli che ho visto è semplicemente un print "hello world". Cioè, viene richiamato una volta dopo il deploy, riceve la risposta che va tutto bene — e basta. E per un servizio, se restituisce il proprio API tramite REST, ci sono moltissimi punti di ingresso di quell'API che devono essere monitorati, poiché vogliamo sapere che funziona. E noi lo monitoriamo già internamente.

Come implementarlo correttamente a livello tecnico: ogni servizio espone un endpoint sulla propria attuale operatività, e nei grafici di Grafana (o di qualsiasi altra applicazione) vediamo lo stato di tutti i servizi.

• Ogni modifica dell'API deve comportare una modifica dei controlli.
• Creare un nuovo servizio immediatamente con metriche di salute.
• L'amministratore può andare dagli sviluppatori e chiedere "scrivete un paio di funzionalità in più, così capisco tutto e posso aggiungere informazioni al mio sistema di monitoraggio". Ma gli sviluppatori di solito rispondono: "Due settimane prima del rilascio non scriviamo nulla di nuovo."
  Facciamo sapere ai manager dello sviluppo che ci saranno delle perdite, e che anche i supervisori dei manager dello sviluppo ne siano a conoscenza. Perché, quando tutto crolla, qualcuno chiamerà comunque e richiederà di monitorare il "servizio che continua a cadere" (c)
• A proposito, dedicate degli sviluppatori alla scrittura di plugin per Grafana — sarà un grande aiuto per gli amministratori.

Livello dell'applicazione — Monitoraggio d'integrazione

Il monitoraggio d'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 richiamare un servizio da solo, ottenere /helloworld e capire che il servizio funziona. Perché il servizio web per la gestione degli ordini deve inviare informazioni sull'ordine al bus — dal bus il servizio di gestione del magazzino deve ricevere questo messaggio e lavorare su di esso. E il servizio di invio e-mail deve elaborarlo in un secondo momento, e così via.

Di conseguenza, non possiamo capire, esplorando ogni singolo servizio, se tutto questo funzioni. Perché abbiamo una sorta di bus attraverso cui tutto comunica e interagisce.
Pertanto, questa fase dovrebbe rappresentare la fase di test dei servizi in interazione con altri servizi. Non è possibile, monitorando il broker di messaggi, organizzare il monitoraggio della comunicazione. Se c'è un servizio che fornisce dati e un servizio che li riceve, monitorando il broker vedremo solo i dati che volano avanti e indietro. Anche se in qualche modo riusciamo a monitorare l'interazione di questi dati all'interno — cioè un certo produttore posta dei dati, qualcuno li legge, questo flusso continua a fluire in Kafka — questo non ci darà comunque informazioni, se un servizio ha inviato un messaggio in una versione e un altro servizio non si aspettava quella versione e l'ha persa. Non lo scopriremo, poiché i servizi ci diranno che tutto funziona.

Come consiglio di fare:

• Per la comunicazione sincrona: l'endpoint esegue richieste ai servizi collegati. Cioè, prendiamo questo endpoint, tiriamo un piccolo script all'interno del servizio, che passa attraverso tutti i punti e dice «posso tirare là, e tirare là, posso tirare lì…»
• Per la comunicazione asincrona: i messaggi in arrivo — l'endpoint controlla il bus per la presenza di messaggi di test e restituisce lo stato di elaborazione.
• Per la comunicazione asincrona: i messaggi in uscita — l'endpoint invia messaggi di test sul bus.

Come avviene di solito: abbiamo un servizio che invia dati sul bus. Andiamo a questo servizio e chiediamo di parlarci della sua salute di integrazione. E se il servizio deve produrre un certo messaggio a un altro luogo (WebApp), allora produce quel messaggio di test. E se tiriamo il servizio dal lato di OrderProcessing, prima posta ciò che può postare in modo indipendente, e se ci sono delle cose dipendenti — legge dal bus un insieme di messaggi di test, comprende cosa può elaborare, comunica questo e, se necessario, li posta ulteriormente, e di questo dice — va tutto bene, sono vivo.

Spesso sentiamo la domanda “come possiamo testare questi dati in produzione?” Ad esempio, parliamo dello stesso servizio ordini. Un ordine invia messaggi al magazzino, dove i prodotti vengono detratti: non possiamo testare questo sui dati reali, perché “i miei prodotti verranno detratti!” La soluzione: nella fase iniziale pianificare tutto questo test. Hai già unit test che creano mock. Quindi, fallo a un livello più profondo, dove avrai un canale di comunicazione che non danneggia l'operatività del business.

Livello infrastrutturale

Il monitoraggio dell'infrastruttura è ciò che da tempo viene considerato il monitoraggio stesso.

• È possibile e necessario avviare il monitoraggio dell'infrastruttura come processo separato.
• Non dovresti iniziare con il monitoraggio dell'infrastruttura in un progetto attivo, anche se lo vuoi fortemente. È una questione comune per tutti i DevOps. “Inizierò a monitorare il cluster, monitorerò l'infrastruttura” – cioè, prima monitorerò ciò che è sotto, senza addentrarmi nell'applicazione. Perché l'applicazione è qualcosa di sconosciuto per i DevOps. È stata passata a lui e non capisce come funziona. Ma l'infrastruttura, quella la capisce e inizia da lì. Ma no, è sempre necessario monitorare prima l'applicazione.
• Non esagerare con il numero di avvisi. Considerando la complessità dei sistemi moderni, gli alert arrivano continuamente e bisogna in qualche modo convivere con questa miriade di alert. E chi è di guardia, guardando un centinaio di alert, penserà “non voglio pensarci”. Gli avvisi devono segnalare solo le cose critiche.

Livello dell'applicazione come unità commerciale

Punti chiave:

• ELK. Questo è uno standard industriale. Se per qualche motivo non stai aggregando i log, inizia a farlo subito.
• APM. APM esterni come mezzo per chiudere rapidamente il monitoraggio dell'applicazione (NewRelic, BlackFire, Datadog). Puoi temporaneamente installare questo strumento, per avere almeno un'idea di cosa sta succedendo.
• Tracing. In dozzine di microservizi devi tracciare tutto, perché la richiesta non vive più da sola. Aggiungere in seguito è molto difficile, quindi è meglio pianificare subito il tracing nello sviluppo – è lavoro e strumento per gli sviluppatori. Se non lo hai già implementato, fallo! Vedi Jaeger/Zipkin.

Alerting

• Organizzazione del sistema di avvisi: in condizioni di monitoraggio di un certo numero di oggetti deve esserci un'unica sistema di invio di avvisi. Può essere in Grafana. In Occidente, tutti usano PagerDuty. Gli avvisi devono essere chiari (ad esempio, da dove provengono…). Ed è desiderabile 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à). I sviluppatori devono essere inclusi nella turnistica: è fondamentale definire le aree di responsabilità, creare un'istruzione chiara e indicare a chi telefonare il lunedì e il mercoledì, e a chi il martedì e il venerdì (altrimenti non chiameranno nessuno nemmeno in caso di grande crisi — temeranno di svegliare, disturbare: le persone in generale non amano chiamare e svegliare gli altri, soprattutto 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 "base di conoscenze" e del workflow per la gestione degli incidenti: per ogni serio incidente deve essere pianificato un post-mortem, come misura temporanea devono essere registrate le azioni che risolveranno l'incidente. E avviate la pratica che gli avvisi ripetuti sono un peccato; devono essere corretti nel codice o in lavori infrastrutturali.

Stack tecnologico

Immaginiamo che il nostro stack sia il seguente:

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

La scelta delle opzioni non è critica. Perché, se all'inizio hai compreso come monitorare il sistema e hai delineato un piano, poi inizi a scegliere gli strumenti in base alle tue esigenze. La questione è quale hai scelto di monitorare all'inizio. Perché, forse, lo strumento che hai scelto all'inizio non è affatto adatto alle tue esigenze.

Alcuni aspetti tecnici che vedo ovunque ultimamente:

Prometheus viene inserito all'interno di Kubernetes — chi l'ha pensato?! Se il tuo cluster va in crash, cosa farai? Se hai un cluster complesso all'interno, deve funzionare un certo sistema di monitoraggio all'interno del cluster, e un altro sistema — all'esterno, che raccoglierà dati da dentro il cluster.

All'interno del cluster raccogliamo log e tutto il resto. Ma il sistema di monitoraggio deve essere all'esterno. Molto spesso, nel cluster dove c'è Prometheus installato internamente, ci sono anche sistemi che effettuano verifiche esterne del funzionamento del sito. E se la tua connessione con il mondo esterno cade e l'applicazione non funziona? Risultato: internamente va tutto bene, ma per gli utenti non è facile.

Conclusioni

• Sviluppare il monitoraggio non significa installare utility, ma sviluppare un prodotto software. Il 98% del monitoraggio attuale consiste in coding. Coding nei servizi, coding delle verifiche esterne, controlli dei servizi esterni, e tanto altro.
• Non risparmiate il tempo degli sviluppatori per il monitoraggio: può assorbire 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 altro tipo di mentalità. Non eravate programmatori, e il lavoro di monitoraggio è proprio quello degli sviluppatori.
• Se il progetto è già operativo e non è monitorato (e voi siete un manager) - allocate risorse per il monitoraggio.
• Se il prodotto è già in produzione e voi siete un DevOps a cui è stato detto di 'configurare il monitoraggio' - cercate di spiegare alla direzione ciò di cui ho parlato.

Questa è una versione estesa della relazione presentata alla conferenza Saint Highload++.

Se siete interessati alle mie idee e riflessioni sull'IT e temi correlati, potete leggere il canale 🙂

Fonte: habr.com