🥇Il monitoraggio è morto? — Monitoraggio a lungo termine

Dal 2008 la nostra azienda si occupa principalmente della gestione dell'infrastruttura e del supporto tecnico 400 ore su 15 per progetti web: abbiamo più di 15 clienti, ovvero circa il XNUMX% dell'e-commerce russo. Di conseguenza, è supportata un'architettura molto diversificata. Se qualcosa cade, siamo obbligati a ripararlo entro XNUMX minuti. Ma per capire che si è verificato un incidente, è necessario monitorare il progetto e rispondere agli incidenti. Come fare questo?

Ritengo che vi sia un problema nell'organizzare un adeguato sistema di monitoraggio. Se non ci fossero stati problemi, il mio discorso consisterebbe in una tesi: “Per favore installa Prometheus + Grafana e i plugin 1, 2, 3”. Sfortunatamente, 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 del sistema di monitoraggio, oserei dire che... non esistono progetti con un monitoraggio competente. E la situazione è così grave che se qualcosa cade, c'è il rischio che passi inosservato - dopo tutto, tutti sono sicuri che "tutto è monitorato".
Forse tutto viene monitorato. Ma come?

Abbiamo tutti riscontrato una storia come la seguente: un certo devops, un certo amministratore sta lavorando, un team di sviluppo va da loro e dice: "siamo rilasciati, ora monitoriamo". Monitorare cosa? Come funziona?

OK. Monitoriamo alla vecchia maniera. E sta già cambiando, e si scopre che hai monitorato il servizio A, che è diventato il servizio B, che interagisce con il servizio C. Ma il team di sviluppo ti dice: "Installa il software, dovrebbe monitorare tutto!"

Quindi cosa è cambiato? - Tutto è cambiato!

2008 Va tutto bene

Ci sono un paio di sviluppatori, un server, un server database. Parte tutto da qui. Abbiamo alcune informazioni, installiamo zabbix, Nagios, cactus. E poi impostiamo avvisi chiari sulla CPU, sul funzionamento del disco e sullo spazio su disco. Effettuiamo anche un paio di controlli manuali per garantire che il sito risponda e che gli ordini arrivino nel database. E questo è tutto: siamo più o meno protetti.

Se confrontiamo la quantità di lavoro che l'amministratore ha svolto per fornire il monitoraggio, il 98% è stato automatico: la persona che esegue il monitoraggio deve capire come installare Zabbix, come configurarlo e configurare gli avvisi. E il 2% - per controlli esterni: che il sito risponda e faccia una richiesta al database, che siano arrivati nuovi ordini.

2010 Il carico sta crescendo

Stiamo iniziando a espandere il web, aggiungendo un motore di ricerca. Vogliamo assicurarci che il catalogo prodotti contenga tutti i prodotti. E la ricerca del prodotto funziona. Che il database funzioni, che vengano effettuati gli ordini, che il sito risponda esternamente e risponda da due server e che l'utente non venga espulso dal sito mentre viene ribilanciato su un altro server, ecc. Ci sono più entità.

Inoltre, l’entità associata alle infrastrutture rimane ancora la più grande nella testa del gestore. C'è ancora l'idea nella mia testa che la persona che esegue il monitoraggio sarà la persona che installerà zabbix e sarà in grado di configurarlo.

Ma allo stesso tempo, si sta lavorando sull'esecuzione di controlli esterni, sulla creazione di una serie di script di query dell'indicizzatore di ricerca, una serie di script per verificare che la ricerca cambi durante il processo di indicizzazione, una serie di script che controllano che le merci vengano trasferite al servizio di consegna, ecc. e così via.

Nota: ho scritto "una serie di script" 3 volte. Cioè, la persona responsabile del monitoraggio non è più quella che installa semplicemente zabbix. Questa è una persona che inizia a programmare. Ma ancora non è cambiato nulla nell’animo della squadra.

Ma il mondo sta cambiando, diventando sempre più complesso. Vengono aggiunti un livello di virtualizzazione e diversi nuovi sistemi. Cominciano a interagire tra loro. Chi ha detto che "puzza di microservizi?" Ma ogni servizio sembra comunque un sito web individualmente. Possiamo rivolgerci ad esso e capire che fornisce le informazioni necessarie e funziona da solo. E se sei un amministratore costantemente coinvolto in un progetto che si sviluppa da 5-7-10 anni, questa conoscenza si accumula: appare un nuovo livello - te ne sei accorto, appare un altro livello - te ne sei reso conto...

Ma raramente qualcuno accompagna un progetto per 10 anni.

Il curriculum di Monitoringman

Supponiamo che tu sia arrivato in una nuova startup che ha assunto immediatamente 20 sviluppatori, ha scritto 15 microservizi e che tu sei un amministratore a cui viene detto: “Costruisci CI/CD. Per favore." Hai creato CI/CD e all'improvviso senti: “È difficile per noi lavorare con la produzione in un “cubo”, senza capire come funzionerà l'applicazione al suo interno. Rendici una sandbox nello stesso "cubo".
Crea una sandbox in questo cubo. Ti dicono subito: “Vogliamo un database di stage che venga aggiornato ogni giorno dalla produzione, in modo da capire che funziona sul database, ma allo stesso tempo non rovinare il database di produzione”.

Tu vivi in tutto questo. Mancano 2 settimane al rilascio, ti dicono: “Adesso monitoriamo tutto questo…” Cioè. monitorare l'infrastruttura del cluster, monitorare l'architettura dei microservizi, monitorare il lavoro con servizi esterni...

E i miei colleghi si tolgono dalla testa il solito schema e dicono: “Ebbene, qui è tutto chiaro! Installa un programma che monitorerà tutto questo. Sì, sì: Prometeo + Grafana + plugin.
E aggiungono: “Hai due settimane, assicurati che tutto sia sicuro”.

In molti progetti che vediamo, una persona viene assegnata al monitoraggio. Immagina di voler assumere una persona per monitorare per 2 settimane e scrivere un curriculum per lui. Quali competenze dovrebbe avere questa persona, visto tutto quello che abbiamo detto finora?

Deve comprendere il monitoraggio e le specifiche del funzionamento dell'infrastruttura siderurgica.
Deve comprendere le specifiche del monitoraggio di Kubernetes (e tutti vogliono andare al "cubo", perché puoi astrarre da tutto, nasconderlo, perché l'amministratore si occuperà del resto) - se stesso, la sua infrastruttura e capire come monitorare le applicazioni dentro.
Deve capire che i servizi comunicano tra loro in modi speciali e conoscere le specifiche di come i servizi interagiscono tra loro. È del tutto possibile vedere un progetto in cui alcuni servizi comunicano in modo sincrono, perché non esiste altro modo. Ad esempio, il backend va tramite REST, tramite gRPC al servizio catalogo, riceve un elenco di prodotti e lo restituisce. Non puoi aspettare qui. E con altri servizi funziona in modo asincrono. Trasferire l'ordine al servizio di consegna, inviare una lettera, ecc.
Probabilmente hai già nuotato da tutto questo? E l'amministratore, che ha bisogno di monitorarlo, è diventato ancora più confuso.
Deve essere in grado di pianificare e pianificare correttamente, poiché il lavoro diventa sempre di più.
Deve quindi creare una strategia a partire dal servizio creato per capire come monitorarlo nello specifico. Ha bisogno di comprendere l'architettura del progetto e il suo sviluppo + una comprensione delle tecnologie utilizzate nello sviluppo.

Ricordiamo un caso assolutamente normale: alcuni servizi sono in PHP, alcuni servizi sono in Go, alcuni servizi sono in JS. In qualche modo lavorano insieme. Da qui deriva il termine “microservizio”: ci sono così tanti singoli sistemi che gli sviluppatori non riescono a comprendere il progetto nel suo complesso. Una parte del team scrive servizi in JS che funzionano da soli e non sanno come funziona il resto del sistema. L'altra parte scrive servizi in Python e non interferisce con il funzionamento degli altri servizi; sono isolati nella propria area. Il terzo è scrivere servizi in PHP o qualcos'altro.
Tutte queste 20 persone sono divise in 15 servizi e c'è un solo amministratore che deve capire tutto questo. Fermare! abbiamo semplicemente suddiviso il sistema in 15 microservizi perché 20 persone non riescono a comprendere l’intero sistema.

Ma va monitorato in qualche modo...

Qual è il risultato? Di conseguenza, c'è una persona che esce con tutto ciò che l'intero team di sviluppatori non può capire, e allo stesso tempo deve anche conoscere ed essere in grado di fare ciò che abbiamo indicato sopra: infrastruttura hardware, infrastruttura Kubernetes, ecc.

Cosa posso dire... Houston, abbiamo problemi.

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

Dalla falsa convinzione che il monitoraggio sia un software, sviluppiamo la fede nei miracoli. Ma i miracoli, ahimè, non accadono. Non puoi installare zabbix e aspettarti che tutto funzioni. Non ha senso installare Grafana e sperare che tutto vada bene. La maggior parte del tempo sarà dedicata all'organizzazione dei controlli sul funzionamento dei servizi e sulla loro interazione tra loro, verificando il funzionamento dei sistemi esterni. In effetti, il 90% del tempo verrà dedicato non alla scrittura di script, ma allo sviluppo di software. E dovrebbe essere gestito da un team che comprende il lavoro del progetto.
Se in questa situazione una persona viene incaricata del monitoraggio, accadrà un disastro. Questo è ciò che accade ovunque.

Ad esempio, esistono diversi servizi che comunicano tra loro tramite Kafka. L'ordine è arrivato, abbiamo inviato un messaggio sull'ordine a Kafka. C'è un servizio che ascolta le informazioni sull'ordine e spedisce la merce. Esiste un servizio che ascolta le informazioni sull'ordine e invia una lettera all'utente. E poi compaiono molti altri servizi e iniziamo a confonderci.

E se lo fornisci anche all'amministratore e agli sviluppatori nella fase in cui manca poco tempo prima del rilascio, la persona dovrà comprendere l'intero protocollo. Quelli. Un progetto di questa portata richiede una notevole quantità di tempo e questo dovrebbe essere preso in considerazione nello sviluppo del sistema.
Ma molto spesso, soprattutto nelle startup, vediamo come il monitoraggio venga rimandato a più tardi. “Ora faremo un Proof of Concept, lo lanceremo e lo lasceremo cadere: siamo pronti al sacrificio. E poi monitoreremo il tutto”. Quando (o se) il progetto inizia a generare profitti, l'azienda desidera aggiungere ancora più funzionalità, poiché ha iniziato a funzionare, quindi deve essere implementato ulteriormente! E sei al punto in cui devi prima monitorare tutto ciò che è stato fatto in precedenza, il che non richiede l'1% delle volte, ma molto di più. E a proposito, gli sviluppatori saranno necessari per il monitoraggio ed è più facile lasciarli lavorare su nuove funzionalità. Di conseguenza, vengono scritte nuove funzionalità, tutto viene incasinato e ti trovi in una situazione di stallo senza fine.

Quindi, come monitorare un progetto partendo dall'inizio e cosa fare se ti capita un progetto che deve essere monitorato, ma non sai da dove iniziare?

Per prima cosa devi pianificare.

Digressione lirica: molto spesso si comincia con il monitoraggio delle infrastrutture. Ad esempio, abbiamo Kubernetes. Cominciamo installando Prometheus con Grafana, installando i plugin per il monitoraggio del “cubo”. Non solo gli sviluppatori, ma anche gli amministratori hanno la sfortunata pratica di: “Installeremo questo plugin, ma probabilmente il plugin sa come farlo”. Alla gente piace iniziare con le cose semplici e dirette, piuttosto che con le azioni importanti. E il monitoraggio delle infrastrutture è semplice.

Per prima cosa, decidi cosa e come vuoi monitorare, quindi seleziona uno strumento, perché altre persone non possono pensare per te. E dovrebbero? Altre persone hanno pensato a un sistema universale o non hanno pensato affatto quando è stato scritto questo plugin. E solo perché questo plugin ha 5mila utenti non significa che serva a qualcosa. Forse diventerai il 5001esimo semplicemente perché prima c'erano già 5000 persone.

Se inizi a monitorare l'infrastruttura e il backend della tua applicazione smette di rispondere, tutti gli utenti perderanno la connessione con l'applicazione mobile. Apparirà un errore. Verranno da te e ti diranno "L'applicazione non funziona, cosa ci fai qui?" - "Stiamo monitorando". — "Come fai a monitorare se non vedi che l'applicazione non funziona?!"

Credo che sia necessario iniziare il monitoraggio esattamente dal punto di ingresso dell'utente. Se l’utente non vede che l’applicazione funziona, è tutto, è un fallimento. E il sistema di monitoraggio dovrebbe prima avvisare di questo.
E solo allora potremo monitorare l’infrastruttura. Oppure farlo in parallelo. È più semplice con l'infrastruttura: qui possiamo finalmente installare zabbix.
E ora bisogna andare alle radici dell'applicazione per capire dove le cose non funzionano.

La mia idea principale è che il monitoraggio dovrebbe procedere parallelamente al processo di sviluppo. Se distrai il team di monitoraggio per altre attività (creazione di CI/CD, sandboxing, riorganizzazione dell'infrastruttura), il monitoraggio inizierà a rallentare e potresti non riuscire mai a recuperare il ritardo con lo sviluppo (o prima o poi dovrai interromperlo).

Tutto per livelli

Ecco come vedo l'organizzazione di un sistema di monitoraggio.

1) Livello di applicazione:

monitorare la logica aziendale dell'applicazione;
monitoraggio delle metriche sanitarie dei servizi;
monitoraggio dell’integrazione.

2) Livello di infrastruttura:

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

3) Ancora una volta a livello applicativo, ma come prodotto ingegneristico:

raccolta e monitoraggio dei log delle applicazioni;
APM;
tracciamento.

4) Avvisi:

organizzazione di un sistema di allarme;
organizzazione di un sistema di dazi;
organizzazione di una “base di conoscenza” e flusso di lavoro per l’elaborazione degli incidenti.

È importante: arriviamo all'allerta non dopo, ma subito! Non è necessario avviare il monitoraggio e “in qualche modo più tardi” capire chi riceverà gli avvisi. Dopotutto, qual è il compito del monitoraggio: capire dove qualcosa nel sistema non funziona e farlo sapere alle persone giuste. Se lasci tutto questo fino alla fine, le persone giuste sapranno che qualcosa sta andando storto solo dicendo che “per noi non funziona niente”.

Livello applicazione: monitoraggio della logica aziendale

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

Questo livello dovrebbe essere eseguito durante la fase di sviluppo. Ad esempio, abbiamo un Prometheus condizionale: va al server che esegue i controlli, estrae l'endpoint e l'endpoint va e controlla l'API.

Quando spesso viene chiesto di monitorare la home page per assicurarsi che il sito funzioni, i programmatori forniscono un handle che può essere utilizzato ogni volta che è necessario assicurarsi che l'API funzioni. E i programmatori in questo momento continuano a prendere e scrivere /api/test/helloworld
L'unico modo per essere sicuri che tutto funzioni? - NO!

La creazione di tali controlli è essenzialmente compito degli sviluppatori. I test unitari dovrebbero essere scritti dai programmatori che scrivono il codice. Perché se lo fai trapelare all'amministratore, "Amico, ecco un elenco di protocolli API per tutte le 25 funzioni, per favore monitora tutto!" - non funzionerà nulla.
Se stampi "ciao mondo", nessuno saprà mai che l'API dovrebbe e funziona. Ogni modifica dell'API deve comportare una modifica nei controlli.
Se hai già un problema del genere, interrompi le funzionalità e assegna agli sviluppatori chi scriverà questi assegni, oppure accetta le perdite, accetta che nulla venga controllato e fallirà.

Suggerimenti tecnici:

Assicurati di organizzare un server esterno per organizzare i controlli: devi essere sicuro che il tuo progetto sia accessibile al mondo esterno.
Organizza i controlli sull'intero protocollo API, non solo sui singoli endpoint.
Crea un endpoint prometheus con i risultati del test.

Livello applicazione: monitoraggio delle metriche di salute

Ora parliamo di parametri sanitari esterni dei servizi.

Abbiamo deciso di monitorare tutti gli "handle" dell'applicazione utilizzando controlli esterni, che chiamiamo da un sistema di monitoraggio esterno. Ma queste sono le “maniglie” che l’utente “vede”. Vogliamo essere sicuri che i nostri servizi stessi funzionino. C’è una storia migliore qui: K8s dispone di controlli sanitari, in modo che almeno il “cubo” stesso possa essere convinto che il servizio funzioni. Ma la metà degli assegni che ho visto riportano la stessa scritta "ciao mondo". Quelli. Quindi tira una volta dopo lo schieramento, ha risposto che va tutto bene, tutto qui. E il servizio, se fornisce la propria API, ha un numero enorme di punti di ingresso per quella stessa API, che necessitano anch'essi di essere monitorati, perché vogliamo sapere che funzioni. E lo stiamo già monitorando all'interno.

Come implementarlo correttamente tecnicamente: ogni servizio espone un endpoint sulle sue prestazioni attuali e nei grafici di Grafana (o qualsiasi altra applicazione) vediamo lo stato di tutti i servizi.

Ogni modifica dell'API deve comportare una modifica nei controlli.
Crea subito un nuovo servizio con le metriche sanitarie.
Un amministratore può rivolgersi agli sviluppatori e chiedere "aggiungimi un paio di funzionalità in modo che io comprenda tutto e aggiunga informazioni al riguardo al mio sistema di monitoraggio". Ma gli sviluppatori di solito rispondono: "Non aggiungeremo nulla due settimane prima del rilascio".
Fate sapere ai responsabili dello sviluppo che ci saranno tali perdite, fatelo sapere anche alla direzione dei responsabili dello sviluppo. Perché quando tutto crolla, qualcuno chiamerà comunque e chiederà di monitorare il “servizio in costante calo” (c)
A proposito, assegna agli sviluppatori la scrittura di plugin per Grafana: questo sarà di grande aiuto per gli amministratori.

Livello applicazione: monitoraggio dell'integrazione

Il monitoraggio dell'integrazione si concentra sul monitoraggio delle comunicazioni tra i sistemi critici per l'azienda.

Ad esempio, ci sono 15 servizi che comunicano tra loro. Questi non sono più siti separati. Quelli. non possiamo attivare il servizio da solo, ottenere /helloworld e capire che il servizio è in esecuzione. Poiché il servizio web di ordinazione deve inviare informazioni sull'ordine al bus, il servizio di magazzino deve ricevere questo messaggio e lavorarci ulteriormente. E il servizio di distribuzione della posta elettronica deve elaborarlo ulteriormente in qualche modo, ecc.

Di conseguenza, non possiamo capire, frugando ogni singolo servizio, che tutto funzioni. Perché abbiamo un certo autobus attraverso il quale tutto comunica e interagisce.
Pertanto, questa fase dovrebbe segnare la fase di test dei servizi per l'interazione con altri servizi. È impossibile organizzare il monitoraggio della comunicazione monitorando il broker di messaggi. Se esiste un servizio che emette dati e un servizio che li riceve, durante il monitoraggio del broker vedremo solo i dati che volano da una parte all'altra. Anche se in qualche modo riuscissimo a monitorare internamente l'interazione di questi dati - che un certo produttore pubblichi i dati, qualcuno li legga, questo flusso continua ad andare a Kafka - questo non ci fornirà comunque informazioni se un servizio ha inviato il messaggio in una versione , ma l'altro servizio non si aspettava questa versione e l'ha saltata. Non lo sapremo, poiché i servizi ci diranno che tutto funziona.

Cosa consiglio di fare:

Per la comunicazione sincrona: l'endpoint effettua richieste ai servizi correlati. Quelli. prendiamo questo endpoint, inseriamo uno script all'interno del servizio, che va a tutti i punti e dice "Posso tirare lì, e tirare lì, posso tirare lì..."
Per la comunicazione asincrona: messaggi in entrata: l'endpoint controlla il bus per i messaggi di prova e visualizza lo stato di elaborazione.
Per la comunicazione asincrona: messaggi in uscita: l'endpoint invia messaggi di prova al bus.

Come di solito accade: abbiamo un servizio che immette i dati nel bus. Veniamo a questo servizio e vi chiediamo di parlarci della sua integrazione sanitaria. E se il servizio deve produrre un messaggio da qualche altra parte (WebApp), produrrà questo messaggio di prova. E se eseguiamo un servizio sul lato OrderProcessing, prima pubblica ciò che può pubblicare in modo indipendente e, se ci sono alcune cose dipendenti, allora legge una serie di messaggi di prova dal bus, capisce che può elaborarli, segnalarli e , se necessario, pubblicali ulteriormente e a riguardo dice: va tutto bene, sono vivo.

Molto spesso sentiamo la domanda "come possiamo testarlo sui dati di combattimento?" Ad esempio, stiamo parlando dello stesso servizio di ordinazione. L'ordine invia messaggi al magazzino dove la merce viene cancellata: non possiamo testarlo sui dati di combattimento, perché "la mia merce verrà cancellata!" Soluzione: pianificare l'intero test fin dall'inizio. Hai anche test unitari che creano prese in giro. Quindi, fallo a un livello più profondo in cui disponi di un canale di comunicazione che non danneggi il funzionamento dell’azienda.

Strato infrastrutturale

Il monitoraggio delle infrastrutture è qualcosa che è stato a lungo considerato il monitoraggio stesso.

Il monitoraggio delle infrastrutture può e deve essere avviato come processo separato.
Non dovresti iniziare con il monitoraggio dell’infrastruttura su un progetto in corso, anche se lo desideri davvero. Questo è un dolore per tutti i devop. “Prima monitorerò il cluster, monitorerò l’infrastruttura” – ovvero Innanzitutto, monitorerà ciò che si trova di seguito, ma non entrerà nell'applicazione. Perché l'applicazione è una cosa incomprensibile per i devops. Gli è trapelato e non capisce come funziona. Ma capisce l'infrastruttura e inizia da essa. Ma no: devi sempre monitorare prima l'applicazione.
Non esagerare con il numero di avvisi. Considerando la complessità dei sistemi moderni, gli avvisi volano costantemente e in qualche modo devi convivere con questo mucchio di avvisi. E il reperibile, dopo aver visionato un centinaio di avvisi successivi, deciderà “non ci voglio pensare”. Gli avvisi dovrebbero informare solo su cose critiche.

Livello di applicazione come unità aziendale

Punti chiave:

ALCE. Questo è lo standard del settore. Se per qualche motivo non stai aggregando i log, inizia a farlo immediatamente.
APM. APM esterni come modo per chiudere rapidamente il monitoraggio delle applicazioni (NewRelic, BlackFire, Datadog). Puoi installare questa cosa temporaneamente per capire almeno in qualche modo cosa ti sta succedendo.
Tracciamento. In decine di microservizi bisogna tracciare tutto, perché la richiesta non vive più da sola. È molto difficile aggiungerlo in seguito, quindi è meglio pianificare immediatamente la tracciabilità in fase di sviluppo: questo è il lavoro e l'utilità degli sviluppatori. Se non l'hai ancora implementato, implementalo! Vedi Jaeger/Zipkin

Avviso

Organizzazione di un sistema di notifica: in condizioni di monitoraggio di una serie di cose, dovrebbe esserci un sistema unificato per l'invio di notifiche. A Grafana puoi. In Occidente tutti usano PagerDuty. Gli avvisi dovrebbero essere chiari (ad esempio da dove provengono...). Ed è consigliabile controllare che le notifiche vengano ricevute
Organizzazione di un sistema di dazi: gli allarmi non dovrebbero essere inviati a tutti (o tutti reagiranno in mezzo alla folla, o nessuno reagirà). Anche gli sviluppatori devono essere reperibili: assicurarsi di definire le aree di responsabilità, dare istruzioni chiare e scrivere in esso chi chiamare esattamente lunedì e mercoledì e chi chiamare martedì e venerdì (altrimenti non chiameranno nessuno nemmeno in orario caso di un grosso problema - avranno paura di svegliarvi o di disturbarvi: generalmente alle persone non piace chiamare e svegliare altre persone, soprattutto di notte). E spiegare che chiedere aiuto non è indice di incompetenza (“chiedo aiuto, vuol dire che sono un cattivo lavoratore”), incentivare le richieste di aiuto.
Organizzazione di una "base di conoscenza" e di un flusso di lavoro per l'elaborazione degli incidenti: per ogni incidente grave, dovrebbe essere pianificata un'autopsia e, come misura temporanea, dovrebbero essere registrate le azioni che risolveranno l'incidente. E rendi pratica che gli avvisi ripetuti siano un peccato; devono essere corretti nel codice o nel lavoro infrastrutturale.

Pila tecnologica

Immaginiamo che il nostro stack sia il seguente:

raccolta dati - Prometeo + Grafana;
analisi del registro - ELK;
per APM o Tracing - Jaeger (Zipkin).

La scelta delle opzioni non è critica. Perché se all'inizio hai capito come monitorare il sistema e hai scritto un piano, poi inizi a scegliere gli strumenti adatti alle tue esigenze. La domanda è: cosa hai scelto di monitorare in primo luogo. Perché forse lo strumento che hai scelto all'inizio non soddisfa affatto le tue esigenze.

Alcuni punti tecnici che vedo ovunque ultimamente:

Prometeo viene spinto all'interno di Kubernetes: chi ha inventato tutto questo?! Se il tuo cluster si blocca, cosa farai? Se hai un cluster complesso all'interno, dovrebbe esserci una sorta di sistema di monitoraggio all'interno del cluster e alcuni all'esterno, che raccoglierà i dati dall'interno del cluster.

All'interno del cluster raccogliamo log e tutto il resto. Ma il sistema di monitoraggio deve essere esterno. Molto spesso, in un cluster dove internamente è installato Promtheus, sono presenti anche sistemi che effettuano controlli esterni del funzionamento del sito. Cosa succede se le tue connessioni con il mondo esterno si interrompono e l'applicazione non funziona? Si scopre che dentro va tutto bene, ma questo non rende le cose più facili per gli utenti.

risultati

Il monitoraggio dello sviluppo non è l'installazione di utilità, ma lo sviluppo di un prodotto software. Il 98% del monitoraggio odierno è codificato. Codificare i servizi, codificare i controlli esterni, controllare i servizi esterni e questo è tutto.
Non sprecare il tempo dei tuoi sviluppatori con il monitoraggio: può richiedere fino al 30% del loro lavoro, ma ne vale la pena.
Devops, non preoccuparti di non poter monitorare qualcosa, perché alcune cose sono un modo di pensare completamente diverso. Non eri un programmatore e monitorare il lavoro è esattamente il loro lavoro.
Se il progetto è già in esecuzione e non monitorato (e sei un manager), alloca le risorse per il monitoraggio.
Se il prodotto è già in produzione e sei un devops a cui è stato detto di "impostare il monitoraggio", prova a spiegare alla direzione di cosa ho scritto tutto questo.

Questa è una versione estesa del rapporto presentato alla conferenza Saint Highload++.

Se sei interessato alle mie idee e pensieri al riguardo e agli argomenti correlati, allora qui puoi farlo leggi il canale 🙂

Fonte: habr.com

Il monitoraggio è morto? — Monitoraggio a lungo termine