Considera il concetto di monitoraggio di Kubernetes, acquisisci familiarità con lo strumento Prometheus e parla di avvisi.
L'argomento del monitoraggio è voluminoso, non può essere smontato in un articolo. Lo scopo di questo testo è quello di fornire una panoramica degli strumenti, dei concetti e degli approcci.
Il materiale dell'articolo è una compressione da . Se vuoi seguire un corso completo, iscriviti a un corso su .
Cosa viene monitorato in un cluster Kubernetes
server fisici. Se il cluster Kubernetes viene distribuito sui suoi server, è necessario monitorarne l'integrità. Zabbix gestisce questo compito; se lavori con lui, non devi rifiutare, non ci saranno conflitti. È Zabbix che monitora lo stato dei nostri server.
Passiamo al monitoraggio a livello di cluster.
Componenti del piano di controllo: API, pianificazione e altri. Come minimo, devi assicurarti che l'API dei server o etcd sia maggiore di 0. Etcd può restituire molti parametri: dai dischi su cui gira, dallo stato del suo cluster etcd e altri.
docker è apparso molto tempo fa e tutti conoscono bene i suoi problemi: molti contenitori causano blocchi e altri problemi. Pertanto anche Docker stesso, come sistema, dovrebbe essere controllato, almeno per quanto riguarda la disponibilità.
dns. Se il DNS si interrompe nel cluster, l'intero servizio Discovery verrà interrotto e le chiamate da pod a pod smetteranno di funzionare. Nella mia pratica non si sono verificati problemi del genere, ma ciò non significa che non sia necessario monitorare lo stato del DNS. La latenza della richiesta e alcuni altri parametri possono essere monitorati su CoreDNS.
Ingresso. È necessario controllare la disponibilità degli ingressi (incluso l'Ingress Controller) come punti di ingresso al progetto.
I componenti principali del cluster sono stati smantellati: ora scendiamo al livello delle astrazioni.
Sembrerebbe che le applicazioni funzionino in pod, il che significa che devono essere controllate, ma in realtà non è così. I pod sono effimeri: oggi girano su un server, domani su un altro; oggi sono 10, domani 2. Quindi nessuno controlla i pod. All'interno di un'architettura a microservizi è più importante controllare la disponibilità dell'applicazione nel suo insieme. In particolare, controlla la disponibilità degli endpoint del servizio: funziona qualcosa? Se l'applicazione è disponibile, cosa succede dietro di essa, quante repliche ci sono ora: queste sono domande del secondo ordine. Non è necessario monitorare le singole istanze.
All'ultimo livello, è necessario controllare il funzionamento dell'applicazione stessa, acquisire metriche aziendali: numero di ordini, comportamento degli utenti e così via.
Prometeo
Il miglior sistema per monitorare un cluster è . Non conosco nessuno strumento che possa eguagliare Prometheus in termini di qualità e facilità d'uso. È ottimo per le infrastrutture flessibili, quindi quando dicono "monitoraggio Kubernetes", di solito intendono Prometheus.
Esistono un paio di opzioni per iniziare con Prometheus: utilizzando Helm, puoi installare un normale Prometheus o Prometheus Operator.
- Prometeo regolare. Con lui va tutto bene, ma è necessario configurare ConfigMap: in effetti, scrivere file di configurazione basati su testo, come abbiamo fatto prima, prima dell'architettura dei microservizi.
- Prometheus Operator è un po' più esteso, un po' più complicato in termini di logica interna, ma è più facile lavorarci: ci sono oggetti separati, le astrazioni vengono aggiunte al cluster, quindi sono molto più convenienti da controllare e configurare.
Per comprendere il prodotto, consiglio di installare prima il normale Prometheus. Dovrai configurare tutto tramite il config, ma questo sarà vantaggioso: capirai cosa appartiene a cosa e come è configurato. In Prometheus Operator sali immediatamente a un'astrazione più alta, anche se puoi anche approfondire le profondità se lo desideri.
Prometheus è ben integrato con Kubernetes: può accedere e interagire con l'API Server.
Prometeo è popolare, motivo per cui è supportato da un gran numero di applicazioni e linguaggi di programmazione. È necessario il supporto, poiché Prometheus ha il proprio formato di metrica e per trasferirlo è necessaria una libreria all'interno dell'applicazione o un esportatore già pronto. E ci sono parecchi di questi esportatori. Ad esempio, c'è PostgreSQL Exporter: prende i dati da PostgreSQL e li converte nel formato Prometheus in modo che Prometheus possa lavorarci.
Architettura di Prometeo
Server Prometeo è il back-end, il cervello di Prometeo. Le metriche vengono archiviate ed elaborate qui.
Le metriche vengono archiviate nel database delle serie temporali (TSDB). TSDB non è un database separato, ma un pacchetto nel linguaggio Go incorporato in Prometheus. In parole povere, tutto è in un binario.
Non archiviare i dati in TSDB per un lungo periodo
L'infrastruttura Prometheus non è adatta per l'archiviazione di parametri a lungo termine. Il periodo di conservazione predefinito è di 15 giorni. Puoi superare questo limite, ma tieni presente: più dati archivi in TSDB e più a lungo lo fai, più risorse consumerà. La memorizzazione dei dati storici in Prometheus è considerata una cattiva pratica.
Se hai un traffico enorme, il numero di parametri è di centinaia di migliaia al secondo, quindi è meglio limitarne l'archiviazione in base allo spazio su disco o al periodo. Di solito, i "dati importanti" vengono archiviati in TSDB, le metriche in poche ore. Per un'archiviazione più lunga, viene utilizzata l'archiviazione esterna in quei database che sono veramente adatti a questo scopo, ad esempio InfluxDB, ClickHouse e così via. Ho visto altre recensioni positive su ClickHouse.
Prometheus Server funziona sul modello tirare: cerca le metriche per quegli endpoint che gli abbiamo fornito. Hanno detto: "vai al server API", e lui ci va ogni n-esimo numero di secondi e prende le metriche.
Per gli oggetti con una durata breve (lavoro o lavoro cron) che possono comparire tra periodi di scraping, esiste un componente Pushgateway. Al suo interno vengono inserite le metriche degli oggetti a breve termine: il lavoro è aumentato, ha eseguito un'azione, ha inviato metriche a Pushgateway ed è stato completato. Dopo un po', Prometheus scenderà al suo ritmo e raccoglierà questi parametri da Pushgateway.
Per configurare le notifiche in Prometheus esiste un componente separato: Gestore avvisi. E le regole di allerta. Ad esempio, è necessario creare un avviso se l'API del server è 0. Quando l'evento si attiva, l'avviso viene passato al gestore avvisi per un ulteriore invio. Il gestore degli avvisi ha impostazioni di routing abbastanza flessibili: un gruppo di avvisi può essere inviato alla chat di Telegram degli amministratori, un altro alla chat degli sviluppatori e un terzo alla chat degli operatori dell'infrastruttura. Le notifiche possono essere inviate a Slack, Telegram, e-mail e altri canali.
E infine, ti parlerò della funzione killer di Prometeo: Alla scoperta. Quando si lavora con Prometheus, non è necessario specificare indirizzi specifici di oggetti da monitorare, è sufficiente impostarne il tipo. Cioè, non è necessario scrivere "ecco l'indirizzo IP, ecco la porta - monitor", è invece necessario determinare in base a quali principi trovare questi oggetti (obiettivi - obiettivi). Prometheus stesso, a seconda di quali oggetti sono attualmente attivi, recupera quelli necessari e li aggiunge al monitoraggio.
Questo approccio si adatta bene alla struttura Kubernetes, dove anche tutto galleggia: oggi ci sono 10 server, domani 3. Per non specificare ogni volta l'indirizzo IP del server, hanno scritto una volta come trovarlo - e Discovering lo farà .
Si chiama la lingua di Prometeo PromQL. Usando questo linguaggio, puoi ottenere i valoridi metriche specifiche e poi convertirli, costruire calcoli analitici basati su di essi.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interfaccia web di Prometeo
Prometheus ha una propria interfaccia web abbastanza minimalista. Adatto solo per debug o dimostrazione.
Nella riga Espressione è possibile scrivere una query nel linguaggio PromQL.
La scheda Avvisi contiene regole di avviso e hanno tre stati:
- inattivo: se l'avviso non è attivo al momento, ovvero va tutto bene e non ha funzionato;
- in sospeso: questo è se l'avviso ha funzionato, ma l'invio non è ancora terminato. Il ritardo è impostato per compensare il lampeggio della rete: se il servizio specificato è aumentato entro un minuto, l'allarme non dovrebbe ancora suonare;
- l'attivazione è il terzo stato in cui l'avviso si accende e invia messaggi.
Nel menu Stato troverai l'accesso alle informazioni su cos'è Prometheus. C'è anche una transizione verso gli obiettivi (obiettivi), di cui abbiamo parlato sopra.
Per una panoramica più dettagliata dell'interfaccia Prometheus, vedere .
Integrazione con Grafana
Nell'interfaccia web di Prometheus non troverai grafici belli e comprensibili da cui trarre una conclusione sullo stato del cluster. Per costruirli, Prometeo è integrato con Grafana. Otteniamo tali dashboard.
Configurare l'integrazione di Prometheus e Grafana non è affatto difficile, puoi trovare le istruzioni nella documentazione: Bene, concludo con questo.
Negli articoli successivi continueremo il tema del monitoraggio: parleremo della raccolta e dell'analisi dei log utilizzando Grafana Loki e strumenti alternativi.
Autore: Marcel Ibraev, amministratore Kubernetes certificato, ingegnere praticante in azienda , relatore e sviluppatore del corso Slurm.
Fonte: habr.com