Il nostro team è molto felice di condividere la notizia che è stata rilasciata una nuova versione del sistema di monitoraggio open source. !
È la versione 4.2 la risposta alla domanda fondamentale sulla vita, l'universo e il monitoraggio in generale? Scopriamolo!
Ricordiamo che Zabbix è un sistema universale per il monitoraggio delle prestazioni e della disponibilità di server, attrezzature ingegneristiche e di rete, applicazioni, database, sistemi di virtualizzazione, contenitori, servizi IT, servizi web.
Zabbix implementa un ciclo completo dalla raccolta dei dati, alla loro elaborazione e trasformazione, all'analisi dei dati ottenuti, fino alla conservazione di questi dati, visualizzazione e invio di avvisi utilizzando regole di escalation. Inoltre, il sistema offre flessibili opportunità di espansione dei metodi di raccolta dati e avvisi, nonché possibilità di automazione tramite API. Un'unica interfaccia web realizza la gestione centralizzata delle configurazioni di monitoraggio e della distribuzione dei diritti di accesso tra diversi gruppi di utenti. Il codice del progetto è distribuito liberamente sotto licenza. .
Zabbix 4.2 è una nuova versione non LTS con un periodo di supporto ufficiale ridotto. Consigliamo agli utenti che puntano a un ciclo prolungato di utilizzo dei prodotti software di utilizzare le versioni LTS, come le 3.0 e 4.0.
Quindi, parliamo delle novità e dei principali miglioramenti della versione 4.2:
Più piattaforme ufficiali
Oltre ai pacchetti ufficiali esistenti, offriamo anche nuove build per:
- RaspberryPi, Mac OS/X, SUSE Enterprise Linux Server 12
- MSI per l'agente Windows
- Immagini Docker
Supporto integrato per Prometheus per il monitoraggio delle applicazioni
Zabbix è in grado di raccogliere dati in vari modi (push/pull) da diverse fonti di dati. Si tratta di JMX, SNMP, WMI, HTTP/HTTPS, RestAPI, XML Soap, SSH, Telnet, agenti e script, e altre fonti. E ora diamo il benvenuto al supporto per Prometheus!
A rigor di termini, la raccolta di dati dagli esportatori di Prometheus era possibile anche in precedenza grazie al tipo di elementi dati HTTP/HTTPS e alle espressioni regolari.
Tuttavia, la nuova versione consente di lavorare con Prometheus in modo estremamente efficiente grazie al supporto integrato del linguaggio di interrogazione PromQL. L'uso di metriche dipendenti consente di raccogliere e elaborare i dati in modo ottimale: si richiedono i dati una sola volta e poi li distribuiamo alle metriche necessarie.
Otteniamo il valore di una metrica specifica
È importante notare che attualmente il rilevamento a basso livello può utilizzare i dati raccolti per generare automaticamente metriche. In questo caso, Zabbix trasforma i dati ricevuti in formato JSON, con cui è molto comodo lavorare.
Troviamo metriche utilizzando il filtro nel linguaggio di query PromQL
Attualmente esistono più di di servizi e applicazioni di terze parti tramite Zabbix. Il supporto per Prometheus permetterà di aggiungere un intero insieme di applicazioni con esportatori ufficiali o supportati dalla comunità di Prometheus. Questi monitoraggi riguardano servizi, contenitori e risorse cloud popolari.
Monitoraggio efficace ad alta frequenza
Vogliamo rilevare i problemi il più rapidamente possibile? Certo, non ci sono dubbi! Spesso, questo approccio porta a dover interrogare i dispositivi troppo frequentemente e raccogliere dati, il che provoca un maggiore carico sul sistema di monitoraggio. Come evitarlo?
Abbiamo implementato un meccanismo di throttling nelle regole di preprocessamento. Il throttling, in sostanza, ci consente di saltare valori identici.
Supponiamo di monitorare lo stato di un'applicazione critica. Ogni secondo controlliamo se la nostra applicazione funziona o meno. Allo stesso tempo, Zabbix riceve un flusso continuo di dati da 1 (funziona) e 0 (non funziona). Ad esempio: 1111111111110001111111111111…
Quando tutto procede bene con la nostra applicazione, Zabbix riceve un flusso di soli uno. È necessario elaborarli? In effetti no, poiché ci interessa solo il cambiamento di stato dell'applicazione, non vogliamo raccogliere e memorizzare così tanti dati. Quindi, il throttling consente di saltare il valore se è identico al precedente. Alla fine, otterremo solo dati sul cambiamento di stato, ad esempio, 01010101… È informazioni più che sufficienti per rilevare problemi!
I valori saltati vengono semplicemente ignorati da Zabbix, non vengono registrati nella cronologia e non influenzano in alcun modo i trigger. Dal punto di vista di Zabbix, i valori saltati non esistono.
Ignoriamo i valori ripetuti
Ottimo! Ora possiamo interrogare molto spesso i dispositivi, scoprendo immediatamente i problemi senza memorizzare informazioni non necessarie nel database.
E i grafici? Saranno vuoti a causa della mancanza di dati! E come capire se Zabbix sta raccogliendo dati, se la maggior parte di questi dati sarà ignorata?
Abbiamo pensato anche a questo! Zabbix offre un altro tipo di throttling, il throttling con punti di controllo (throttling with heartbeat).
Controlliamo una volta al minuto se la metrica è viva
In questo caso, Zabbix, nonostante il flusso di dati ripetuto, conserverà almeno un valore nell'intervallo di tempo specificato. Se i dati vengono raccolti ogni secondo e l'intervallo è di un minuto, Zabbix trasformerà il flusso di dati al secondo in un flusso di dati al minuto. Non è difficile notare che questo porta a una compressione di 60 volte dei dati raccolti.
Ora siamo certi che i dati vengono raccolti, la funzione del trigger nodata() funziona e i grafici sono a posto!
Validazione dei dati raccolti e gestione degli errori
Nessuno di noi vuole raccogliere dati errati o inaffidabili. Ad esempio, sappiamo che un sensore di temperatura dovrebbe restituire dati nell'intervallo da 0°C a 100°C, e qualsiasi altro valore dovrebbe essere considerato errato e/o ignorato.
Adesso è possibile grazie alle regole di validazione dei dati integrate nel preprocessamento, che possono verificare la corrispondenza o l'assenza di corrispondenza con espressioni regolari, intervalli di valori, JSONPath e XMLPath.
Ora possiamo gestire la reazione agli errori. Se la temperatura è al di fuori dell'intervallo, possiamo semplicemente ignorare quel valore, assegnare un valore predefinito (ad esempio, 0°C), oppure definire un nostro messaggio di errore, come "Sensore danneggiato" o "Sostituire la batteria".
La temperatura deve essere tra 0 e 100, il resto viene ignorato
Un buon esempio di utilizzo della validazione è la possibilità di controllare i dati in ingresso per la presenza di messaggi di errore e di impostare questo errore per l'intera metrica. Questa è una funzionalità molto utile quando si ricevono dati da API esterne.
Qualsiasi trasformazione dei dati tramite JavaScript
Se le regole di preprocessamento integrate non sono sufficienti, ora offriamo piena libertà utilizzando script arbitrari in JavaScript!
Basta una sola riga di codice per convertire gradi Fahrenheit in gradi Celsius
Questo apre infinite possibilità per l'elaborazione dei dati in entrata. Il vantaggio pratico di questa funzionalità è che ora non abbiamo più bisogno di script esterni che usavamo per qualsiasi operazione con i dati. Ora tutto questo può essere fatto tramite JavaScript.
Ora sono possibili trasformazioni dei dati, aggregazione, filtri, operazioni aritmetiche e logiche e molto molto altro!
Estraiamo informazioni utili dall'output di Apache mod_status!
Testiamo il preprocessing
Ora non dobbiamo più indovinare come funzionano i nostri complessi scenari di preprocessing. È disponibile un facile controllo della correttezza del preprocessing direttamente dall'interfaccia!
Elaboriamo milioni di metriche al secondo!
Fino a Zabbix 4.2, il preprocessing era gestito esclusivamente dal server Zabbix, il che limitava le possibilità di utilizzo dei proxy per distribuire il carico.
A partire dalla versione Zabbix 4.2 otteniamo un'incredibile efficienza nella scalabilità del carico grazie al supporto per il preprocessing sul lato proxy. Ora se ne occupano i proxy!
In combinazione con il throttling, questo approccio consente di eseguire un monitoraggio ad alta frequenza e scalato, effettuando milioni di controlli al secondo senza sovraccaricare il server centrale di Zabbix. I proxy elaborano enormi volumi di dati, e solo una piccola parte di essi, tramite throttling, arriva al server Zabbix, inferiore di uno o due ordini di grandezza.
Rilevamento a basso livello più semplice
Ricordiamo che il rilevamento a basso livello (LLD) è un meccanismo molto potente per la rilevazione automatica di qualsiasi tipo di risorse da monitorare (sistemi di file, processi, applicazioni, servizi, ecc.) e per la creazione automatica di elementi di dati, trigger, nodi di rete e altri oggetti. Questo fa risparmiare tempo incredibile, semplifica la configurazione e consente di utilizzare un solo modello per i nodi di rete che hanno risorse diverse da monitorare.
Il rilevamento a basso livello richiedeva un JSON formattato in modo speciale. Questo non accadrà più!
Zabbix 4.2 consente al rilevamento di basso livello (LLD) di utilizzare dati arbitrariamente formattati in JSON. Perché è importante? Questo permette di comunicare, ad esempio, con API esterne senza dover ricorrere a script e di utilizzare le informazioni ottenute per creare automaticamente nodi di rete, elementi dati e trigger.
In combinazione con il supporto per JavaScript, ciò crea possibilità fantastiche per la creazione di modelli che lavorano con diverse fonti di dati, come ad esempio API cloud, API di applicazioni, dati in formati XML, CSV e molto altro.
Colleghiamo JSON con le informazioni sui processi tramite LLD
Le possibilità sono veramente illimitate!
Supporto per TimescaleDB
Che cos'è TimescaleDB? È un normale PostgreSQL più un modulo di estensione del team di TimescaleDB. TimescaleDB promette migliori prestazioni grazie a algoritmi e strutture di dati più efficienti.
Inoltre, un altro vantaggio di TimescaleDB è la partizione automatica delle tabelle storiche. TimescaleDB significa velocità e facilità di manutenzione! Tuttavia, devo notare che il nostro team non ha ancora effettuato un'analisi approfondita delle prestazioni rispetto a un normale PostgreSQL.
Al momento, TimescaleDB è un prodotto piuttosto giovane e in rapida evoluzione. Usare con cautela!
Gestione dei tag semplificata
Se prima i tag potevano essere gestiti solo a livello di trigger, ora la gestione dei tag è molto più flessibile. Zabbix supporta i tag per modelli e nodi di rete!
Tutti i problemi rilevati ricevono tag non solo dal trigger, ma anche dal nodo di rete e dai modelli di quel nodo di rete.
Definiamo i tag per il nodo di rete
Autoregistrazione più flessibile
Zabbix 4.2 consente di filtrare i nodi di rete per nome, utilizzando espressioni regolari. Questo consente di creare vari scenari di rilevamento per diversi gruppi di nodi di rete. Particolarmente utile quando utilizziamo regole di denominazione complesse per i dispositivi.
Rilevamento di rete più flessibile
Un altro miglioramento riguarda la denominazione dei nodi di rete. È stata introdotta la possibilità di gestire i nomi dei dispositivi durante il rilevamento di rete e di ottenere il nome del dispositivo dal valore della metrica.
Questa è una funzionalità molto utile, specialmente durante il rilevamento di rete tramite SNMP e Zabbix agent.
Assegniamo automaticamente il nome locale del nodo di rete come nome visibile
Verifica della funzionalità dei metodi di notifica
Ora è possibile inviare un messaggio di prova direttamente dall'interfaccia web e verificare se il metodo di notifica funziona. Questa funzionalità è particolarmente utile per testare gli script di integrazione di Zabbix con vari sistemi di notifica, sistemi di ticketing e altri programmi e API esterni.
Monitoraggio remoto dei componenti dell'infrastruttura Zabbix
È ora possibile monitorare da remoto le metriche interne del server Zabbix e dei proxy (metriche di prestazione e funzionalità dei componenti di Zabbix).
A cosa serve? Questa funzionalità consente di monitorare le metriche interne dei server e dei proxy, permettendo di rilevare rapidamente e segnalare i problemi anche se i componenti stessi sono sovraccarichi o, ad esempio, se ci sono grandi volumi di dati non inviati sul proxy.
Supporto per il formato HTML per le email
Ora non siamo più limitati al semplice testo e possiamo creare email più belle, grazie al supporto per il formato HTML. È tempo di esplorare HTML + CSS!
I messaggi sono più facili da percepire anche con un uso minimo dell'HTML
Accesso a sistemi esterni dalle mappe di rete
È stato introdotto il supporto per un intero insieme di nuovi macro negli URL personalizzati per una migliore integrazione delle mappe con sistemi esterni. Ciò consente di aprire, ad esempio, un ticket nel sistema di ticketing con uno o due clic sull'icona del nodo della rete.
Apriamo un ticket in Jira con un clic
La regola di rilevamento può essere un elemento dipendente dei dati
Perché è utile, vi chiederete. Ciò consente di utilizzare i dati della metrica principale sia per il rilevamento che per la raccolta diretta dei dati. Ad esempio, nel caso della raccolta dati da un esportatore Prometheus, Zabbix eseguirà una richiesta HTTP e utilizzerà immediatamente le informazioni ricevute per tutti gli elementi di dati dipendenti: valori delle metriche e regole di rilevamento di basso livello.
Nuovo modo di visualizzare i problemi nelle mappe
È stato introdotto il supporto per immagini GIF animate nelle mappe per una visualizzazione dei problemi più evidente.
I dispositivi problematici sono diventati più evidenti
Estrazione dei dati dagli header HTTP nel monitoraggio web
Nel monitoraggio web è stata aggiunta la possibilità di selezionare i dati dall'header HTTP ricevuto.
Questo consente di creare scenari di monitoraggio web multi-step o monitoraggio delle API di terze parti, utilizzando un token di autorizzazione ottenuto in uno dei passaggi.
Estraiamo l'AuthID dall'intestazione HTTP
Zabbix Sender utilizza tutti gli indirizzi IP
Zabbix Sender ora invia dati su tutti gli indirizzi IP dal parametro ServerActive del file di configurazione dell'agente.
Un nuovo filtro utile nella configurazione dei trigger
La pagina di configurazione dei trigger ha acquisito un filtro avanzato per la selezione rapida e facile dei trigger in base a criteri specifici.
Selezioniamo i trigger relativi al servizio K8S
Mostriamo l'ora esatta
Qui è tutto semplice, ora Zabbix mostra l'ora esatta quando si passa il mouse sopra il grafico.
Altre novità
- Implementato un algoritmo più prevedibile per modificare l'ordine di disposizione dei widget nel dashboard
- Possibilità di modifica massiva dei parametri dei prototipi degli elementi di dati
- Supporto IPv6 per i controlli DNS: "net.dns" e "new.dns.record"
- Aggiunto il parametro "skip" per i controlli "vmware.eventlog"
- L'errore durante l'esecuzione del passaggio di pre-elaborazione include il numero del passaggio
Come aggiornarsi?
Per passare da versioni precedenti è necessaria solo l'installazione (server e proxy) e della nuova interfaccia. Zabbix eseguirà automaticamente la procedura di aggiornamento del database. Non sarà necessario installare nuovi agenti.
Offriamo webinar gratuiti per chi desidera approfondire Zabbix 4.2 e avere la possibilità di porre domande al team di Zabbix.
Non dimentichiamo il popolare della comunità Zabbix, dove è sempre possibile ricevere consulenze e risposte alle proprie domande in lingua russa da colleghi più esperti, e, se si è fortunati, anche dagli sviluppatori stessi di Zabbix. Consigliamo ai principianti .
Link utili
—
—
—
Fonte: habr.com
