Oggi nel nostro progetto, oltre al codice monolitico, funzionano decine di microservizi. Ognuno di essi richiede monitoraggio. Farlo in questo volume con le forze degli ingegneri DevOps è problematico. Abbiamo sviluppato un sistema di monitoraggio che funziona come un servizio per gli sviluppatori. Possono scrivere metriche nel sistema di monitoraggio, usarle, creare dashboard basate su di esse e collegare allarmi che scattano al raggiungimento di determinati valori soglia. Agli ingegneri DevOps rimane solo l'infrastruttura e la documentazione.
Questo post è la trascrizione del mio intervento durante la nostra a RIT++. Molti ci hanno chiesto di fare versioni testuali delle relazioni presentate lì. Se sei stato alla conferenza o hai visto il video, non troverai nulla di nuovo. A tutti gli altri, benvenuti sotto il tag. Racconterò come siamo arrivati a questo sistema, come funziona e come intendiamo aggiornarlo.
Il passato: schemi e piani
Come siamo arrivati al sistema di monitoraggio esistente? Per rispondere a questa domanda, bisogna tornare al 2015. Ecco come si presentava allora:
Avevamo circa 24 nodi responsabili del monitoraggio. Qui c'è un intero insieme di cronjob, script e demoni che monitorano qualcosa in qualche modo, inviano messaggi e svolgono funzioni. Abbiamo pensato che, proseguendo, un sistema simile sarebbe diventato sempre meno sostenibile. Non ha senso svilupparlo: è troppo ingombrante.
Abbiamo deciso di scegliere quali elementi di monitoraggio mantenere e sviluppare e quali abbandonare. Ne sono rimasti 19. Sono rimasti solo Graphite, aggregatori e Grafana come dashboard. Ma come apparirà il nuovo sistema? Ecco come:
Abbiamo uno storage per le metriche: sono i Graphite, che saranno basati su SSD veloci, e ci sono aggregatori specifici per le metriche. Inoltre, utilizzeremo Grafana per visualizzare le dashboard e Moira per gli allerta. Volevamo anche sviluppare un sistema per la ricerca di anomalie.
Standard: Monitoraggio 2.0
Ecco come si presentavano i piani nel 2015. Ma dovevamo preparare non solo l'infrastruttura e il servizio stesso, ma anche la documentazione ad esso collegata. Abbiamo sviluppato un standard aziendale che abbiamo chiamato monitoraggio 2.0. Quali erano i requisiti per il sistema?
- disponibilità continua;
- intervallo di conservazione delle metriche = 10 secondi;
- archiviazione strutturata di metriche e dashboard;
- SLA > 99,99%
- raccolta di metriche degli eventi tramite UDP (!).
Avevamo bisogno di UDP, poiché gestivamo un alto volume di traffico e eventi che generano metriche. Se le scrivessimo tutte in Graphite contemporaneamente, l'archivio andrebbe in crash. Abbiamo anche scelto prefissi di primo livello per tutte le metriche.
Ciascuno dei prefissi ha una proprietà specifica. Ci sono metriche su server, reti, contenitori, risorse, applicazioni e così via. È stata implementata una filtrazione chiara, rigorosa e tipizzata, dove accettiamo solo metriche di primo livello e le altre semplicemente le scartiamo. Ecco come abbiamo pianificato questo sistema nel 2015. E nel presente?
Presente: schema di interazione dei componenti di monitoraggio
Innanzitutto monitoriamo le applicazioni: il nostro codice PHP, le applicazioni e i microservizi — in breve, tutto ciò che scrivono i nostri sviluppatori. Tutte le applicazioni inviano metriche all'aggregatore Brubeck (statsd, riscritto in C) tramite UDP. Si è rivelato essere il più veloce nei test sintetici. E invia già le metriche aggregate a Graphite tramite TCP.
Esso ha un tipo di metrica chiamata timer. È una cosa molto utile. Ad esempio, per ogni connessione di un utente con il servizio, inviate a Brubeck una metrica con il tempo di risposta. Arrivano un milione di risposte, e l'aggregatore restituisce solo 10 metriche. Avete il numero di utenti arrivati, il tempo massimo, minimo e medio di risposta, la mediana e 4 percentili. Poi i dati vengono trasferiti a Graphite e possiamo vederli tutti in tempo reale.
Abbiamo anche aggregazione per le metriche sull'hardware, software, metriche di sistema e il nostro vecchio sistema di monitoraggio Munin (che è stato in uso fino al 2015). Raccolgliamo tutto questo tramite il demone CollectD in C (che ha una vasta gamma di plugin integrati, è in grado di interrogare tutte le risorse del sistema host su cui è installato, basta specificare nella configurazione dove scrivere i dati) e scriviamo attraverso di esso dati in Graphite. Supporta anche plugin Python e script shell, così potete scrivere le vostre soluzioni personalizzate: CollectD raccoglierà questi dati da un host locale o remoto (supponiamo ci sia Curl) e li invierà a Graphite.
Successivamente, tutte le metriche che abbiamo raccolto vengono inviate a Carbon-c-relay. Questa è una soluzione di Carbon Relay da Graphite, modificata in C. Si tratta di un router che raccoglie tutte le metriche che inviamo dai nostri aggregatori e le instrada verso i nodi. Inoltre, durante l'instradamento, verifica la validità delle metriche. Esse, da un lato, devono corrispondere allo schema con i prefissi che ho mostrato in precedenza e, dall'altro, devono essere valide per Graphite. Altrimenti vengono scartate.
Successivamente, Carbon-c-relay invia le metriche al cluster Graphite. Utilizziamo Carbon-cache, riscritto in Go, come principale sistema di archiviazione delle metriche. Go-carbon, a causa della sua multithreading, supera notevolmente le prestazioni di Carbon-cache. Riceve i dati e li scrive sui dischi utilizzando il pacchetto whisper (standard, scritto in python). Per leggere i dati dai nostri archivi, utilizziamo l'API di Graphite. Funziona molto più velocemente rispetto al Graphite WEB standard. Cosa succede ai dati successivamente?
Essi vanno in Grafana. Come principale fonte di dati utilizziamo i nostri cluster di Graphite, e abbiamo Grafana come interfaccia web per visualizzare le metriche e costruire dashboard. Ogni sviluppatore crea un proprio dashboard per il proprio servizio. Successivamente, costruiscono grafici che mostrano le metriche inviate dalle proprie applicazioni. Oltre a Grafana, abbiamo anche SLAM. Si tratta di un demone Python che calcola SLA sulla base dei dati provenienti da Graphite. Come ho già detto, abbiamo diverse decine di microsistemi, ciascuno dei quali ha le proprie esigenze. Con SLAM confrontiamo la documentazione con ciò che abbiamo in Graphite e verifichiamo quanto le esigenze si allineano con la disponibilità dei nostri servizi.
Procediamo oltre: il monitoraggio degli allerta. È organizzato attraverso un robusto sistema: Moira. È indipendente perché ha un proprio Graphite sotto il cofano. È stata sviluppata dai ragazzi di SKB 'Kontur', scritta in Python e Go, completamente open source. Moira riceve tutto lo stesso flusso che va verso i Graphite. Se per qualche motivo il vostro archivio si guasta, il monitoraggio degli allerta continuerà a funzionare.
Moira è stata implementata in Kubernetes, utilizzando un cluster di server Redis come database principale. Il risultato è un sistema tollerante ai guasti. Confronta il flusso delle metriche con un elenco di trigger: se non ci sono menzioni, scarta la metrica. In questo modo è in grado di elaborare gigabyte di metriche al minuto.
Inoltre, abbiamo integrato un LDAP aziendale, tramite il quale ogni utente del sistema aziendale può creare notifiche per trigger esistenti (o appena creati). Poiché Moira include Graphite, supporta tutte le sue funzionalità. Pertanto, prima prendi una riga e la copi in Grafana. Controlla come vengono visualizzati i dati nei grafici. Successivamente prendi la stessa riga e la copi in Moira. Le applichi i limiti e ottieni l'allerta in uscita. Per fare tutto questo, non sono necessarie conoscenze specifiche. Moira è in grado di inviare avvisi tramite SMS, email, in Jira, Slack... Supporta anche l'esecuzione di script personalizzati. Quando si verifica un trigger e Moira è iscritta a uno script personalizzato o a un eseguibile, lo avvia e passa a stdin a quell'eseguibile un JSON. Di conseguenza, il tuo programma deve analizzarlo. Cosa fare con questo JSON è una tua scelta. Vuoi, invialo su Telegram, vuoi, apri i task in Jira, fai quello che preferisci.
Per l'allerta utilizziamo anche uno sviluppo interno: Imagotag. Abbiamo adattato un pannello di solito utilizzato per i prezzi elettronici nei negozi, per le nostre esigenze. Abbiamo visualizzato i trigger da Moira su di esso. Sono indicati i loro stati e quando si sono verificati. Alcuni membri del team di sviluppo hanno rinunciato alle notifiche in Slack e email in favore di questo pannello.
Essendo una compagnia all'avanguardia, abbiamo monitorato anche Kubernetes in questo sistema. L'abbiamo integrato utilizzando Heapster, che abbiamo installato nel cluster, raccoglie i dati e li invia a Graphite. Alla fine, lo schema appare così:
Componenti di monitoraggio
Ecco l'elenco dei link ai componenti che abbiamo utilizzato per questo compito. Sono tutti open source.
Graphite:
- go-carbon:
- whisper:
- graphite-api:
Carbon-c-relay:
Brubeck:
Collectd:
Moira:
Grafana:
Heapster:
Statistiche
Ecco alcune cifre su come funziona il sistema da noi.
Aggregator (brubeck)
Numero di metriche: ~ 300 000 / sec
Intervallo di invio delle metriche a Graphite: 30 sec
Utilizzo delle risorse del server: ~ 6% CPU (riferito a server completi); ~ 1Gb RAM; ~ 3 Mbps LAN
Graphite (go-carbon)
Numero di metriche: ~ 1 600 000 / min
Intervallo di aggiornamento delle metriche: 30 sec
Schema di archiviazione delle metriche: 30sec 35d, 5min 90d, 10min 365d (fornisce comprensione su cosa sta accadendo con il servizio su un lungo periodo di tempo)
Utilizzo delle risorse del server: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Flessibilità
In Avito, teniamo molto alla flessibilità del nostro servizio di monitoraggio. Perché è diventato così? In primo luogo, le sue parti costitutive sono intercambiabili: sia i componenti stessi che le loro versioni. In secondo luogo - manutenibilità. Poiché l'intero progetto è basato su open source, puoi modificare il codice, apportare modifiche e implementare funzionalità non disponibili di default. Vengono utilizzate pile abbastanza diffuse, principalmente Go e Python, quindi è abbastanza semplice.
Ecco un esempio di un problema realmente verificatosi. Una metrica in Graphite è un file. Ha un nome. Nome del file = nome della metrica. E c'è un percorso per questo. I nomi dei file in Linux sono limitati a 255 caratteri. E noi abbiamo (come 'clienti interni') ragazzi del dipartimento database. Ci dicono: 'Vogliamo monitorare le nostre query SQL. E queste non sono 255 caratteri, ma 8 MB ognuna. Vogliamo visualizzarle in Grafana, vedere i parametri di questa query e, anche meglio, vogliamo vedere il top di queste query. Sarebbe fantastico se si visualizzassero in tempo reale. E sarebbe davvero straordinario se potessimo inserirle nell'allerta.'
Esempio di query SQL preso come esempio da
Stiamo avviando il server Redis e i nostri plugin Collectd, che accedono a Postgres per recuperare tutti i dati e inviare le metriche a Graphite. Tuttavia, sostituiamo il nome della metrica con gli hash. Questo stesso hash viene inviato contemporaneamente a Redis come chiave, e l'intera query SQL come valore. Ci rimane da fare in modo che Grafana possa accedere a Redis e ottenere queste informazioni. Apriamo l'API di Graphite, poiché è l'interfaccia principale per l'interazione tra tutti i componenti di monitoraggio e Graphite, e inseriamo una nuova funzione chiamata aliasByHash() — riceviamo il nome della metrica da Grafana e lo utilizziamo nella richiesta a Redis come chiave, ricevendo in risposta il valore di quella chiave, che è la nostra “query SQL”. In questo modo, abbiamo visualizzato in Grafana la rappresentazione della query SQL, che teoricamente non poteva essere visualizzata, insieme alle statistiche relative (chiamate, righe, tempo totale, ...).
Conclusioni
Disponibilità. Il nostro servizio di monitoraggio è disponibile 24 ore su 24, 7 giorni su 7, da qualsiasi applicazione e codice. Se hai accesso ai repository, puoi scrivere dati nel servizio. Il linguaggio non è importante, le soluzioni non contano. Devi solo sapere come aprire un socket, inviare la metrica e chiudere il socket.
Affidabilità. Tutti i componenti sono resistenti ai guasti e gestiscono bene i nostri carichi.
Basso livello di ingresso. Per utilizzare questo sistema, non è necessario studiare i linguaggi di programmazione o le query in Grafana. Basta aprire la propria applicazione, inserire il socket che invierà le metriche a Graphite, chiuderlo, aprire Grafana, creare dashboard e osservare il comportamento delle metriche, ricevendo notifiche tramite Moira.
Autonomia. Tutto questo può essere fatto in autonomia, senza l'aiuto di ingegneri DevOps. E questo è un overkill, perché puoi monitorare il tuo progetto proprio ora, senza chiedere aiuto — né per iniziare, né per modifiche.
Qual è il nostro obiettivo?
Tutti i punti elencati di seguito non sono solo pensieri astratti, ma rappresentano ciò a cui sono stati compiuti anche i primi passi.
- Rilevatore di anomalie. Vogliamo sviluppare un servizio che acceda ai nostri repository Graphite e verifichi ogni metrica tramite vari algoritmi. Abbiamo già algoritmi che vogliamo esaminare, abbiamo dati, sappiamo come lavorare con essi.
- Metadati. Abbiamo molti servizi, che nel tempo cambiano, proprio come le persone che lavorano con loro. Tenere costantemente la documentazione manualmente non è un'opzione. Pertanto, attualmente nei nostri microservizi vengono integrati i metadati. Qui è specificato chi lo ha sviluppato, i linguaggi con cui interagisce, i requisiti di SLA, dove e a chi inviare le notifiche. Al momento del deployment del servizio, tutti i dati delle entità vengono creati autonomamente. Alla fine, ricevi due link: uno ai trigger e l'altro ai dashboard in Grafana.
- Monitoraggio in ogni casa. Riteniamo che un sistema simile debba essere utilizzato da tutti gli sviluppatori. In questo modo saprai sempre dove si trova il tuo traffico, cosa sta accadendo, dove scende e dove ha punti deboli. Se, ad esempio, arriva qualcosa e sovraccarica il tuo servizio, lo scoprirai non durante una telefonata da un manager, ma da un avviso, e potrai subito aprire i log recenti e vedere cosa è successo.
- Alte prestazioni. Il nostro progetto cresce costantemente e oggi elabora circa 2.000.000 di valori di metriche al minuto. Un anno fa, questo numero era di 500.000. E la crescita continua, il che significa che tra un po’ Graphite (whisper) inizierà a sovraccaricare notevolmente il sistema di archiviazione. Come ho già detto, questo sistema di monitoraggio è piuttosto versatile grazie all'intercambiabilità dei componenti. Qualcuno gestisce e amplia costantemente la propria infrastruttura specificamente per Graphite, ma noi abbiamo deciso di seguire un'altra strada: usare come archivio per le nostre metriche. Questo passaggio è praticamente completato e presto racconterò in dettaglio come è stato fatto: quali difficoltà ci sono state e come sono state superate, come si è svolto il processo di migrazione, descriverò i componenti scelti come middleware e le loro configurazioni.
Grazie per l'attenzione! Fate le vostre domande sull'argomento, cercherò di rispondere qui o nei prossimi post. È possibile che qualcuno abbia esperienza nella creazione di un sistema di monitoraggio simile o nella transizione a Clickhouse in una situazione analoga: condividetela nei commenti.
Fonte: habr.com
