IT knowledge base
CTRL+F per cercare la tua parola chiave

Monitoraggio dei servizi di sistema in tempo reale con Chronograf

Già oggi iniziano le lezioni in un nuovo gruppo del corso "Monitoring and Logging: Zabbix, Prometheus, ELK" di OTUS . Durante la prossima settimana , tutti avranno l'opportunità di iscriversi al corso ad un prezzo speciale . Bene, in questo momento stiamo condividendo una traduzione tradizionale di materiale utile sull'argomento .


Tutti gli amministratori di sistema hanno familiarità con systemd. Sviluppato da Lennart Poettering e freedesktop.org, systemd è uno strumento molto utile per la gestione dei servizi su Linux. La maggior parte dei software moderni si presenta sotto forma di servizi systemd.

Ma cosa succede quando un servizio va giù? La maggior parte delle volte, lo troverai quando alcuni danni sono già stati fatti.

Oggi creeremo una dashboard per monitorare i servizi di sistema in tempo reale. Avrà servizi attivi, inattivi e caduti e invierà anche messaggi a Slack!

Dashboard per systemd Dashboard per systemd

1. Qualche parola su D-Bus

Prima di entrare nell'architettura e nella codifica, ricapitoliamo rapidamente cos'è D-Bus e come può aiutarti a raggiungere il tuo obiettivo (se sei un esperto di D-Bus, sentiti libero di passare alla Sezione 2).

D-Bus è un bus di comunicazione interprocesso che consente a più applicazioni registrate su di esso di comunicare.

Le applicazioni che utilizzano D-Bus sono server o client. Il client si connette a un server D-Bus in attesa di connessioni in entrata. Quando sono connesse a un server D-Bus, le applicazioni si registrano sul bus e ricevono un nome per identificarle.

Le applicazioni si scambiano quindi messaggi e segnali che possono essere intercettati dai client collegati al bus.

Lo scopo di D-Bus può sembrare un po' vago all'inizio, ma è uno strumento molto utile per i sistemi Linux.

Ad esempio, il servizio UPower (che monitora gli alimentatori) può comunicare con il servizio thermald (che monitora la temperatura complessiva) per ridurre il consumo di energia se rileva problemi di surriscaldamento (non te ne accorgerai nemmeno).

Ma qual è la relazione tra D-Bus e il monitoraggio del servizio systemd? Systemd è registrato su D-Bus come servizio org.freedesktop.systemd1. Inoltre, invia alcuni segnali ai client quando lo stato dei servizi systemd cambia. Ed è quello che useremo per il nostro monitoraggio.

2. Ricezione di segnali D-Bus

Per questo tutorial, sto usando una macchina con Xubuntu 18.04 e un kernel standard. Dovrebbe funzionaredbus-daemon e l'utility è installatabusctl ...

Questo può essere verificato eseguendo:

ps aux | grep dbus-daemon

Di conseguenza, dovrebbero esserci almeno due record: un bus di sistema e un bus di sessione.

busctl status

Questo comando verifica lo stato del bus e ne restituisce la configurazione.

Definizione di segnali D-Bus utili

Come affermato in precedenza, il servizio systemd si registra sul bus e invia segnali quando accade qualcosa relativo a systemd.

Quando un servizio si avvia, si arresta o si arresta in modo anomalo, systemd invia un segnale bus a tutti i client disponibili. Poiché systemd invia molti eventi, reindirizzeremo l'output standard a un file per analizzarli.

sudo busctl monitor org.freedesktop.systemd1> systemd.output 

Nel file vediamo molti messaggi, chiamate di metodo, ritorni di metodo e segnali.

Segnali bus di sistema Segnali bus di sistema

Notare la riga "ActiveState" con il valore "disattivazione"? Questo interrompe il mio servizio InfluxDB. Possiamo anche ottenere il tempo associato al cambiamento!

Il servizio org.freedesktop.systemd definisce sei diversi stati: attivo, in ricarica, inattivo, fallito, in attivazione, in disattivazione. Ovviamente, siamo particolarmente interessati al segnale fallito perché segnala un guasto del servizio.

Ora che abbiamo la capacità di intercettare manualmente i segnali systemd sul sistema, creiamo un sistema di monitoraggio completamente automatizzato.

3. Architettura e implementazione

Utilizzeremo la seguente architettura per monitorare i servizi di sistema:

L'architettura di monitoraggio di sistema definitiva L'architettura di monitoraggio di sistema definitiva

L'architettura è piuttosto semplice. La cosa principale è assicurarsi che dbus-daemon sia in esecuzione.

Successivamente, abbiamo bisogno di creare un semplice client D-Bus (in Go!) Che si iscriverà ai segnali da systemd. Tutti i segnali in arrivo verranno analizzati e archiviati in InfluxDB.

Dopo aver salvato i dati su InfluxDB, creeremo una dashboard in Chronograf che visualizza le statistiche sui servizi e il loro stato attuale.

Quando il servizio va in crash, Kapacitor (il motore di streaming) raccoglie il segnale e invia automaticamente un messaggio a Slack agli amministratori di sistema.

È così semplice! Giusto?

Costruire un client D-Bus in Go

Il primo passo per catturare i segnali da systemd è creare un semplice client che:

  1. Collegati al bus
  2. Iscriviti ai segnali di sistema
  3. Analizza i dati e inviali a InfluxDB

Nota: ti starai chiedendo perché ho scelto Go per creare il client D-Bus. Le librerie client dbus e InfluxDB sono scritte in Go, il che lo rende un candidato ideale per questo piccolo esperimento.

Il codice client è abbastanza lungo da essere completamente codificato in questo articolo, ma elencherò di seguito la funzione principale che svolge la maggior parte del lavoro. Il codice completo è disponibile su Github .

Per ogni singolo segnale da systemd, viene creato un punto in InfluxDB. Ho scelto questa implementazione perché volevo avere una cronologia completa di tutte le modifiche che si verificano nei diversi servizi. Questo può essere molto utile per indagare su alcuni errori ricorrenti per un periodo di tempo.

Opzioni di implementazione

Per la struttura dati in InfluxDB, ho scelto il nome del servizio (a scopo di indicizzazione) come tag (etichette) e lo stato (fallito, attivo, in attivazione...) come valore.

Uso anche una semplice mappatura dei valori di stato in numeri. Le funzioni aggregate IQL funzionano meglio con i valori numerici che con i valori di testo.

Nota: nel frammento di codice sopra, puoi vedere che sto ottenendo molte proprietà da systemd, ma recupero solo la proprietà "ActiveState" che hai visto nella prima sezione.

Ora che abbiamo un semplice client Go, trasformiamolo in un servizio, avviamolo e accediamo a Chronograf.

4. Dashboard per amministratori di sistema

Quando abbiamo dati in InfluxDB, inizia il divertimento. Creiamo una dashboard in Chronograf che mostri le statistiche del servizio e gli indicatori per i singoli servizi che vogliamo monitorare.

Una dashboard è composta da tre parti principali:

  1. Il numero di servizi attivi, inattivi e interrotti in un determinato momento.
  2. Una tabella che mostra la cronologia completa dei cambiamenti di stato nel tempo per ogni servizio.
  3. 12 indicatori che mostrano 12 diversi servizi di sistema che vogliamo evidenziare.

Nota: si presume che tu abbia una conoscenza preliminare di Chronograf, che tu sappia come configurarlo e collegarti a InfluxDB. La documentazione è disponibile qui .

Numero di servizi attivi, inattivi e interrotti

Ecco un'opzione per creare un blocco con una metrica:

Cronologia completa dei cambiamenti di stato

Creiamo tabelle di cronologia in modo simile:

Indicatori per i singoli servizi

Naturalmente, ti incoraggio a giocare con i widget e a creare le tue dashboard. La tua dashboard non dovrebbe essere una copia esatta di quanto sopra.

Ora che abbiamo una dashboard, possiamo monitorare i servizi di sistema in tempo reale. Grande!

E se avessimo ancora avvisi in tempo reale in Slack?

5. Invio di avvisi in caso di guasto del servizio

Utilizzeremo Kapacitor (un motore di streaming), responsabile della generazione e della gestione degli avvisi in caso di guasto del servizio.

Dopo aver installato ed eseguito Kapacitor, torniamo a Chronograf e andiamo al pannello degli avvisi.

Quando fai clic sul pulsante "Gestisci attività", vedrai due sezioni: regole di avviso e script di spunta. Creiamo un nuovo avviso facendo clic sul pulsante "Crea regola avviso".

Di seguito è riportata la configurazione completa degli avvisi:

Questo avviso è configurato per inviare notifiche al webhook Slack se il servizio non risponde entro quindici minuti (ovvero, il valore dello stato è meno uno). Sul lato Slack, l'avviso si presenta così:

6. Conclusione

Ho imparato molto creando questo piccolo progetto. Non avendo esperienza con D-Bus e Golang, questo esperimento mi ha insegnato che uscire dalla mia zona di comfort (anche nella programmazione) è il modo per sviluppare nuove abilità.

Il processo di creazione di un dashboard di questo tipo può sembrare dispendioso in termini di tempo, ma una volta implementato offre vantaggi reali ai team operativi e agli amministratori di sistema.

Se ti piace costruire le tue soluzioni di monitoraggio, puoi certamente trarre alcune idee da questo articolo. Ma se sei più interessato all'utilizzo di strumenti standard, allora consiglierei sicuramente SignalFX o Telegraf. Queste sono soluzioni affidabili ed efficienti per la tua infrastruttura.

Visualizza l'offerta speciale

Articoli di lettura consigliati:

  • Monitoraggio di Kubernetes con Prometheus e Thanos
  • Gestire gli avvisi con Alerta.io