Consideriamo il concetto di monitoraggio di Kubernetes, ci familiarizziamo con lo strumento Prometheus e discutiamo dell'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, le concetti e le metodologie.
Il materiale dell'articolo è un riassunto di . Se desiderate seguire una formazione completa, iscrivetevi al corso di .
Cosa si monitora nel cluster Kubernetes
Server fisici. Se il cluster Kubernetes è distribuito sui propri server, è necessario monitorare la loro salute. Questa operazione è gestita da Zabbix; se lavorate con esso, non è necessario rinunciare, non ci saranno conflitti. È proprio Zabbix a monitorare lo stato dei nostri server.
Passiamo al monitoraggio a livello di cluster.
Componenti del Control Plane: API, Scheduler e altri. Al minimo, è necessario tenere d'occhio che il numero di server API o etcd sia superiore a 0. Etcd è in grado di restituire molte metriche: sul disco su cui è in esecuzione, sulla salute del suo cluster etcd e altre.
Docker è presente da tempo e i suoi problemi sono ben noti: una moltitudine di container genera blocchi e altri problemi. Pertanto, è utile controllare anche Docker stesso, sebbene solo per la disponibilità.
DNS. Se il DNS nel cluster fallisce, anche l'intero servizio di discovery non funzionerà, smetteranno di funzionare le comunicazioni tra i pod. Nella mia esperienza, non ho mai riscontrato problemi di questo tipo, ma ciò non significa che non sia necessario monitorare lo stato del DNS. I ritardi nelle richieste e alcune altre metriche possono essere monitorate su CoreDNS.
Ingress. È necessario controllare la disponibilità degli ingressi (incluso l'Ingress Controller) come punti di accesso al progetto.
Abbiamo analizzato i principali componenti del cluster - ora scendiamo più in basso, al livello delle astrazioni.
A prima vista, le applicazioni vengono eseguite nei pod, quindi è necessario monitorarle, ma in realtà non è così. I pod sono efimeri: oggi funzionano su un server, domani su un altro; oggi ce ne sono 10, domani 2. Pertanto, i singoli pod non vengono monitorati. Nell'architettura a microservizi, è più importante controllare la disponibilità dell'applicazione nel suo insieme. In particolare, verificare la disponibilità degli endpoint del servizio: funziona almeno qualcosa? Se l'applicazione è disponibile, allora cosa sta succedendo dietro di essa, quante repliche ci sono attualmente - queste sono domande di secondo ordine. Non è necessario monitorare i singoli istanziamenti.
Nell'ultimo livello, è necessario controllare il funzionamento dell'applicazione stessa, raccogliere metriche aziendali: numero di ordini, comportamento degli utenti e altro.
Prometheus
Il miglior sistema per monitorare un cluster è . Non conosco alcun 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», generalmente ci si riferisce proprio a Prometheus.
Ci sono un paio di opzioni per iniziare a lavorare con Prometheus: usando Helm, è possibile installare il normale Prometheus o il Prometheus Operator.
- Prometheus normale. Va tutto bene, ma è necessario configurare il ConfigMap: in sostanza, scrivere file di configurazione testuali, come facevamo prima, prima dell'architettura a microservizi.
- Il Prometheus Operator è un po' più ingombrante, leggermente più complesso nella logica interna, ma è più semplice da usare: ci sono oggetti separati, le astrazioni vengono aggiunte al cluster, quindi è molto più comodo controllarle e configurarle.
Per comprendere il prodotto, consiglio di installare prima il normale Prometheus. Dovrai configurare tutto tramite il file di configurazione, ma sarà utile: capirai a cosa si riferisce ogni cosa e come si configura. Con il Prometheus Operator si sale subito a un'astrazione superiore, anche se, se desideri, potrai sondare in profondità.
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 trasmetterlo è necessaria una libreria all'interno dell'applicazione o un esportatore già pronto. Ce ne sono abbastanza. Ad esempio, c'è l'esportatore PostgreSQL: raccoglie dati da PostgreSQL e li converte nel formato di Prometheus, affinché Prometheus possa lavorarci.
Architettura di Prometheus
Prometheus Server è la parte server, il cervello di Prometheus. Qui vengono memorizzate e elaborate le metriche.
Le metriche sono memorizzate nel database di serie temporali (TSDB). Il TSDB non è un database separato, ma un pacchetto in linguaggio Go, integrato in Prometheus. In semplici termini, tutto si trova in un unico eseguibile.
Non mantenere i dati nel TSDB per lungo tempo
L'infrastruttura Prometheus non è adatta per la conservazione a lungo termine delle metriche. Per impostazione predefinita, il periodo di conservazione è di 15 giorni. È possibile superare questa limitazione, ma bisogna tenere presente che più dati si conservano nel TSDB e più a lungo lo si fa, più risorse verrà a consumare. Conservare dati storici in Prometheus è considerato una cattiva pratica.
Se hai un enorme traffico, con metriche che si contano a centinaia di migliaia al secondo, è meglio limitarne la conservazione in base allo spazio su disco o al tempo. Di solito, nel TSDB si conservano "dati caldi", metriche letteralmente risalenti a poche ore. Per una conservazione più duratura si utilizzano archivi esterni in quei database che sono realmente adatti a questo scopo, come InfluxDB, ClickHouse e così via. Ho visto più recensioni positive riguardo ClickHouse.
Il server Prometheus funziona secondo un modello pull: si reca direttamente agli endpoint per le metriche che gli abbiamo fornito. Abbiamo detto: "recati all'API Server", e lui vi si reca 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 Pushgateway. Qui vengono inviate metriche da oggetti a breve termine: il job parte, esegue un'azione, invia metriche a Pushgateway e termina. Dopo un certo periodo, Prometheus si presenta nel suo ritmo e raccoglie queste metriche da Pushgateway.
Per impostare avvisi in Prometheus c'è un componente separato — Alertmanager. Le regole di allerta — alerting rules. Per esempio, è necessario creare un avviso nel caso in cui i server API siano 0. Quando si attiva l'evento, l'avviso viene inviato all'alert manager per ulteriori invii. L'alert manager offre impostazioni di routing sufficientemente flessibili: un gruppo di avvisi può essere inviato a un chat Telegram degli amministratori, un altro a un chat degli sviluppatori, un terzo a un chat degli esperti di infrastruttura. Le notifiche possono arrivare via Slack, Telegram, email e altri canali.
Infine, vi parlerò della killer feature di Prometheus — Discovering. Lavorando con Prometheus, non è necessario specificare gli indirizzi esatti degli oggetti da monitorare, è sufficiente definire il loro tipo. Cioè non è necessario scrivere "ecco l'indirizzo IP, ecco la porta — monitora", invece è necessario stabilire secondo quali principi trovare questi oggetti (targets — obiettivi). Prometheus stesso, in base agli oggetti attualmente attivi, raccoglie quelli necessari e li aggiunge al monitoraggio.
Questo approccio si adatta bene alla struttura di Kubernetes, dove anche tutto è fluido: oggi 10 server, domani 3. Per non dover specificare ogni volta l'indirizzo IP del server, abbiamo scritto una volta come trovarlo — e Discovering si occuperà di farlo.
Il linguaggio di Prometheus si chiama PromQL. Con questo linguaggio è possibile estrarre i valori di metriche specifiche e poi elaborarle, costruendo analisi su di esse.
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 la query
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interfaccia web di Prometheus
Prometheus ha una propria interfaccia web, abbastanza minimalista. È adatta solo per il debug o le dimostrazioni.
Nella casella Expression puoi scrivere richieste nel linguaggio PromQL.
Nella scheda Alerts ci sono le regole di allerta — alerting rules, e hanno tre stati:
- inactive — se al momento l'allerta non è attiva, significa che va tutto bene e non è scattata;
- pending — questo nel caso in cui l'allerta sia scattata, ma l'invio non è ancora avvenuto. Viene impostato un ritardo per compensare i lampi di rete: se nel corso di un minuto il servizio specificato è ripartito, non è necessario ancora suonare l'allerta;
- firing — questo è il terzo stato, quando l'allerta si attiva e invia messaggi.
Nel menu Status puoi trovare accesso alle informazioni su cosa sia Prometheus. Qui c'è anche un passaggio agli obiettivi (targets), di cui abbiamo parlato sopra.
Per una panoramica più dettagliata dell'interfaccia di Prometheus, consulta .
Integrazione con Grafana
Nell'interfaccia web di Prometheus non troverai grafici belli e comprensibili da cui trarre conclusioni sullo stato del cluster. Per costruirli, Prometheus viene integrato con Grafana. Ne risultano cruscotti come questi.
Configurare l'integrazione tra Prometheus e Grafana non è affatto complicato, e le istruzioni sono disponibili nella documentazione: , e con questo concludo.
Nei prossimi articoli continueremo a parlare del monitoraggio: discuteremo della raccolta e analisi dei log utilizzando Grafana Loki e strumenti alternativi.
Autore: Marsel Abraev, amministratore certificato Kubernetes, ingegnere praticante presso , relatore e sviluppatore dei corsi di Slyrm.
Fonte: habr.com
