Esploriamo il concetto di monitoraggio di Kubernetes, conosciamo lo strumento Prometheus e parliamo di alerting.
Il tema del monitoraggio è vasto e non può essere trattato in un solo articolo. L'obiettivo di questo testo è fornire una panoramica sugli strumenti, i concetti e gli approcci.
Il materiale dell'articolo è un riassunto di . Se desideri un percorso formativo completo, iscriviti al corso su .
Cosa viene monitorato nel cluster Kubernetes
Server fisici. Se il cluster Kubernetes è distribuito sui propri server, è necessario monitorarne la salute. Zabbix si occupa di questo compito; se lo utilizzi, non è necessario rinunciarvi poiché non ci saranno conflitti. Zabbix tiene sotto controllo lo stato dei nostri server.
Passiamo al monitoraggio a livello di cluster.
Componenti del Control Plane: API, Scheduler e altri. È fondamentale monitorare che ci siano più di 0 server API o etcd. Etcd è in grado di fornire molte metriche: sui dischi su cui è in esecuzione, sulla salute del suo cluster etcd e altre.
Docker è emerso da tempo e i suoi problemi sono ben noti: molteplici contenitori generano blocchi e altri problemi. Pertanto, è opportuno monitorare anche Docker come sistema, almeno per garantirne l'accessibilità.
DNS. Se il DNS nel cluster fallisce, anche l'intero servizio di Discovery andrà offline, e le comunicazioni tra i pod smetteranno di funzionare. Nella mia esperienza, non ho mai avuto problemi simili, ma ciò non significa che non si debbano monitorare le condizioni del DNS. I ritardi nelle richieste e alcune altre metriche possono essere tracciate su CoreDNS.
Ingress. È necessario monitorare la disponibilità degli ingressi (incluso l'Ingress Controller) come punti di accesso al progetto.
Abbiamo esaminato i componenti principali del cluster — ora scendiamo a un livello di astrazione inferiore.
A prima vista, le applicazioni vengono eseguite nei pod, quindi bisognerebbe monitorarle, ma in realtà non è così. I pod sono efimeri: oggi sono su un server, domani su un altro; oggi ce ne sono 10, domani 2. Pertanto, nessuno monitora semplicemente i pod. Nel contesto di un'architettura a microservizi, è più importante controllare la disponibilità dell'applicazione nel suo insieme. In particolare, verificare la disponibilità degli endpoint del servizio: c'è qualcosa che funziona? Se l'applicazione è accessibile, ciò che avviene dietro e quante repliche ci sono sono domande di secondo ordine. Non è necessario monitorare singoli istanze.
A livello finale, è necessario monitorare il funzionamento stesso dell'applicazione, raccogliere metriche aziendali: numero di ordini, comportamento degli utenti e altro ancora.
Prometheus
Il miglior sistema per il monitoraggio del cluster è . Non conosco nessuno strumento che possa competere con Prometheus in termini di qualità e facilità d'uso. È perfetto per infrastrutture flessibili, quindi quando si parla di "monitoraggio Kubernetes", di solito ci si riferisce proprio a Prometheus.
Ci sono un paio di opzioni per iniziare a lavorare con Prometheus: si può installare il normale Prometheus tramite Helm o Prometheus Operator.
- Prometheus normale. Funziona bene, ma è necessario configurare il ConfigMap: in pratica, si devono scrivere file di configurazione testuali, come facevamo prima dell'architettura a microservizi.
- Prometheus Operator è un po' più complesso, con una logica interna più articolata, ma è più facile da usare: ci sono oggetti separati, le astrazioni vengono aggiunte al cluster, quindi è molto più comodo controllarle e configurarle.
Per iniziare a comprendere il prodotto, consiglio di installare prima il normale Prometheus. Dovrai configurare tutto tramite il file di configurazione, ma questo sarà utile: capirai a cosa si riferisce ogni cosa e come configurarli. Con Prometheus Operator, sali subito a un livello di astrazione superiore, anche se, se desideri, puoi comunque approfondire i dettagli.
Prometheus è ben integrato con Kubernetes: può accedere all'API Server e interagire con esso.
Prometheus è popolare, quindi è supportato da un gran numero di applicazioni e linguaggi di programmazione. Il supporto è necessario, poiché Prometheus ha il proprio formato di metriche, e per la sua trasmissione è necessaria una libreria all'interno dell'applicazione o un esportatore già pronto. E ce ne sono davvero molti. Ad esempio, c'è il PostgreSQL Exporter: raccoglie dati da PostgreSQL e li converte nel formato di Prometheus, affinché Prometheus possa lavorarci.
Architettura di Prometheus
Server Prometheus — è la parte server, il cervello di Prometheus. Qui vengono memorizzate e elaborate le metriche.
Le metriche sono memorizzate in un database di serie temporali (TSDB). TSDB non è un database separato, ma un pacchetto scritto in Go, incorporato in Prometheus. In sostanza, tutto è contenuto in un unico file binario.
Non conservare i dati in TSDB a lungo
L'infrastruttura di Prometheus non è adatta per la conservazione a lungo termine delle metriche. Per impostazione predefinita, il periodo di conservazione è di 15 giorni. È possibile superare questo limite, ma è importante tener presente che più dati si archiviano nel TSDB e più a lungo lo si fa, maggiore sarà il consumo di risorse. Conservare dati storici in Prometheus è considerata una cattiva pratica.
Se ricevete un enorme traffico e il numero di metriche raggiunge centinaia di migliaia al secondo, è consigliabile limitarne la conservazione per volume di disco o per tempo. Di solito, nel TSDB si conservano «dati caldi», metriche raccolte solo nell'arco di poche ore. Per una conservazione più lunga si utilizzano memorie esterne in database realmente adatti a questo scopo, come InfluxDB, ClickHouse e così via. Ho visto molte recensioni positive su ClickHouse.
Il server Prometheus opera secondo il modello pull: va a raccogliere le metriche dagli endpoint che gli abbiamo fornito. Gli abbiamo detto: «vai all'API Server», e lui si collega lì ogni n secondi per raccogliere le metriche.
Per gli oggetti con una breve durata di vita (job o cron job), che possono apparire tra i periodi di scraping, esiste un componente chiamato Pushgateway. Qui vengono inviati i metriche degli oggetti a breve termine: il job si avvia, esegue un'azione, invia metriche a Pushgateway e termina. Dopo un certo periodo, Prometheus recupera queste metriche da Pushgateway secondo il suo ritmo.
Per configurare le notifiche in Prometheus, c'è un componente separato — Alertmanager. E le regole di allerta — alerting rules. Ad esempio, è necessario creare un alert nel caso in cui i server API siano 0. Quando si verifica l'evento, l'alert viene inviato all'alert manager per ulteriori invii. L'alert manager ha impostazioni di routing abbastanza flessibili: un gruppo di alert può essere inviato a una chat Telegram degli amministratori, un altro al chat degli sviluppatori, un terzo al chat degli ingegneri infrastrutturali. Le notifiche possono arrivare su Slack, Telegram, email e altri canali.
Infine, voglio parlare della killer feature di Prometheus — Discovering. Con Prometheus non è necessario specificare indirizzi specifici per gli oggetti da monitorare; è sufficiente definire il loro tipo. Non è necessario dire “ecco l'indirizzo IP, qui c'è la porta — monitora”, ma piuttosto stabilire i principi per trovare questi oggetti (targets — obiettivi). Prometheus stesso, in base a quali oggetti sono attivi, li raccoglie e li aggiunge al monitoraggio.
Questo approccio si adatta bene alla struttura di Kubernetes, dove tutto è dinamico: oggi ci sono 10 server, domani 3. Per non dover indicare ogni volta l'indirizzo IP del server, si scrive una volta come trovarlo — e Discovering lo farà.
Il linguaggio di Prometheus si chiama PromQL. Con questo linguaggio è possibile estrarre i valori di metriche specifiche e successivamente trasformarli, costruendo analisi su di essi.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Una semplice query
container_memory_usage_bytes
Operazioni matematiche
container_memory_usage_bytes / 1024 / 1024
Funzioni incorporate
sum(container_memory_usage_bytes) / 1024 / 1024
Precisa richiesta
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interfaccia web di Prometheus
Prometheus ha una sua interfaccia web piuttosto minimalista. È adatta solo per il debug o la dimostrazione.
Nella riga Expression puoi scrivere query nel linguaggio PromQL.
Nella scheda Alerts sono presenti le regole di allerta — alerting rules, e hanno tre stati:
- inactive — se l’allerta non è attiva al momento, significa che va tutto bene e non è scattato;
- pending — questo stato si verifica se l’allerta è scattato, ma l'invio non è ancora avvenuto. Il ritardo è impostato per compensare i piccoli problemi di rete: se un servizio si riprende entro un minuto, non è necessario attivare l'allerta;
- firing — è il terzo stato, quando l’allerta si attiva e invia messaggi.
Nel menu Status troverai accesso alle informazioni su cosa sia Prometheus. Qui c'è anche un collegamento agli obiettivi (targets) di cui abbiamo parlato prima.
Per una panoramica più dettagliata dell'interfaccia di Prometheus, guarda .
Integrazione con Grafana
Nell'interfaccia web di Prometheus non troverai grafici belli e chiari da cui trarre conclusioni sullo stato del cluster. Per crearli, Prometheus viene integrato con Grafana. Si ottengono dashboard come queste.
Configurare l'integrazione di Prometheus e Grafana è piuttosto semplice, le istruzioni si trovano nella documentazione: , e io qui concludo.
Nei prossimi articoli continueremo a parlare di monitoraggio: discuteremo della raccolta e analisi dei log con Grafana Loki e strumenti alternativi.
Autore: Marsel Ibraev, amministratore certificato Kubernetes, ingegnere praticante presso , relatore e sviluppatore dei corsi di Slyrm.
Fonte: habr.com
