2 Dettagli di preelaborazione

Panoramica

Questa sezione fornisce i dettagli del preprocessing dei valori degli item. Il preprocessing dei valori degli item consente di definire ed eseguire regole di trasformazione per i valori degli item ricevuti.

Il preprocessing è gestito dal processo di gestione del preprocessing insieme ai worker di preprocessing che eseguono i passaggi di preprocessing. Tutti i valori con preprocessing, ricevuti da diversi raccoglitori di dati, passano attraverso il gestore del preprocessing prima di essere aggiunti alla cache della cronologia. La comunicazione IPC basata su socket viene utilizzata tra i raccoglitori di dati (poller, trapper, ecc.) e il processo di preprocessing. I passaggi di preprocessing vengono eseguiti da Zabbix server oppure da Zabbix proxy (per gli item monitorati dal proxy).

Elaborazione del valore dell'item

Per visualizzare il flusso dei dati dalla sorgente dati al database di Zabbix, possiamo utilizzare il seguente diagramma semplificato:

Il diagramma sopra mostra solo i processi, gli oggetti e le azioni relativi all'elaborazione del valore dell'item in forma semplificata. Il diagramma non mostra i cambiamenti di direzione condizionali, la gestione degli errori o i cicli. Anche la cache dati locale del gestore di preprocessing non è mostrata, poiché non influisce direttamente sul flusso dei dati. Lo scopo di questo diagramma è mostrare i processi coinvolti nell'elaborazione del valore dell'item e il modo in cui interagiscono.

• La raccolta dei dati inizia con dati grezzi provenienti da una sorgente dati. A questo punto, i dati contengono solo ID, timestamp e valore (possono anche essere presenti più valori).
• Indipendentemente dal tipo di raccoglitore dati utilizzato, il concetto è lo stesso per controlli attivi o passivi, per item trapper, ecc., poiché cambia solo il formato dei dati e chi avvia la comunicazione (il raccoglitore dati è in attesa di una connessione e dei dati, oppure il raccoglitore dati avvia la comunicazione e richiede i dati). I dati grezzi vengono convalidati, la configurazione dell'item viene recuperata dalla cache di configurazione (i dati vengono arricchiti con i dati di configurazione).
• Per trasferire i dati dai raccoglitori dati al gestore di preprocessing viene utilizzato un meccanismo IPC basato su socket. A questo punto il raccoglitore dati continua a raccogliere dati senza attendere la risposta del gestore di preprocessing.
• Viene eseguito il preprocessing dei dati. Questo include l'esecuzione dei passaggi di preprocessing e l'elaborazione degli item dipendenti.

• I dati di history dalla cache dati locale del gestore di preprocessing vengono scaricati nella cache di history.
• A questo punto il flusso dei dati si interrompe fino alla successiva sincronizzazione della cache di history (quando il processo history syncer esegue la sincronizzazione dei dati).
• Il processo di sincronizzazione inizia con la normalizzazione dei dati prima di memorizzarli nel database di Zabbix. La normalizzazione dei dati esegue conversioni nel tipo di item desiderato (tipo definito nella configurazione dell'item), inclusa la troncatura dei dati testuali in base alle dimensioni predefinite consentite per tali tipi (HISTORY_STR_VALUE_LEN per string, HISTORY_TEXT_VALUE_LEN per text e HISTORY_LOG_VALUE_LEN per valori log). I dati vengono inviati al database di Zabbix dopo il completamento della normalizzazione.

• I dati raccolti vengono elaborati: i trigger vengono controllati, la configurazione dell'item viene aggiornata se l'item diventa NOT SUPPORTED, ecc.
• Questo è considerato il termine del flusso dei dati dal punto di vista dell'elaborazione del valore dell'item.

Preelaborazione del valore dell'item

La preelaborazione dei dati viene eseguita nei seguenti passaggi:

• Se l'item non ha né preelaborazione né item dipendenti, il suo valore viene aggiunto alla cache della cronologia oppure inviato al gestore LLD. Altrimenti, il valore dell'item viene passato al gestore della preelaborazione utilizzando un meccanismo IPC basato su socket UNIX.
• Viene creato un task di preelaborazione, aggiunto alla coda e i worker di preelaborazione vengono notificati del nuovo task.
• A questo punto il flusso dei dati si interrompe finché non è disponibile almeno un worker di preelaborazione non occupato (cioè che non sta eseguendo alcun task).
• Quando un worker di preelaborazione è disponibile, preleva il task successivo dalla coda.
• Al termine della preelaborazione (sia in caso di esecuzione non riuscita che riuscita dei passaggi di preelaborazione), il valore preelaborato viene aggiunto alla coda dei task completati e il gestore viene notificato della presenza di un nuovo task completato.
• Il gestore della preelaborazione converte il risultato nel formato desiderato (definito dal tipo di valore dell'item) e lo aggiunge alla cache della cronologia oppure lo invia al gestore LLD.
• Se esistono item dipendenti per l'item elaborato, gli item dipendenti vengono aggiunti alla coda di preelaborazione con il valore preelaborato del master item. Gli item dipendenti vengono accodati bypassando le normali richieste di preelaborazione dei valori, ma solo per i master item con il valore impostato e non nello stato NOT SUPPORTED.

Si noti che nel diagramma la preelaborazione del master item è leggermente semplificata, omettendo la cache di preelaborazione.

Coda di preprocessing

La coda di preprocessing è organizzata come segue:

• l'elenco delle attività in sospeso:

  • attività create direttamente dalle richieste di preprocessing dei valori nell'ordine in cui sono state ricevute

• l'elenco delle attività immediate (elaborate prima delle attività in sospeso):

  • attività di test (create in risposta alle richieste di test di item/preprocessing dal frontend)
  • attività degli item dipendenti
  • attività di sequenza (attività che devono essere eseguite in un ordine rigoroso):
    • con passaggi di preprocessing che utilizzano l'ultimo valore:
      • modifica
      • throttling
      • JavaScript (cache del bytecode)
    • cache del preprocessing degli item dipendenti

• l'elenco delle attività completate

Cache di preprocessing

La cache di preprocessing è stata introdotta per migliorare le prestazioni del preprocessing per più item dipendenti che hanno passaggi di preprocessing simili (un risultato comune di LLD).

Il caching viene eseguito effettuando il preprocessing di un item dipendente e riutilizzando parte dei dati interni di preprocessing per il resto degli item dipendenti. La cache di preprocessing è supportata solo per il primo passaggio di preprocessing dei seguenti tipi:

• Pattern Prometheus (indicizza l'input in base alle metriche)
• JSONPath (analizza i dati in un albero di oggetti e indicizza la prima espressione [?(@.path == "value")])

Worker di preprocessing

Il file di configurazione di Zabbix server consente agli utenti di impostare il numero di thread worker di preprocessing. Il parametro di configurazione StartPreprocessors deve essere utilizzato per impostare il numero di istanze preavviate dei worker di preprocessing, che dovrebbe almeno corrispondere al numero di core CPU disponibili.

Se le attività di preprocessing non sono limitate dalla CPU e comportano frequenti richieste di rete, si consiglia di configurare worker aggiuntivi. Il numero ottimale di worker di preprocessing può essere determinato da molti fattori, tra cui il numero di item "preprocessabili" (item che richiedono l'esecuzione di uno qualsiasi dei passaggi di preprocessing), il numero di processi di raccolta dati, il numero medio di passaggi per il preprocessing degli item, ecc. Un numero insufficiente di worker può causare un elevato utilizzo della memoria. Per la risoluzione dei problemi relativi all'utilizzo eccessivo della memoria nella propria installazione di Zabbix, vedere Profiling excessive memory usage with tcmalloc.

Tuttavia, supponendo che non vi siano operazioni di preprocessing pesanti come il parsing di grandi blocchi XML/JSON, il numero di worker di preprocessing può corrispondere al numero totale di processi di raccolta dati. In questo modo, nella maggior parte dei casi (tranne quando i dati dal processo di raccolta arrivano in blocco) ci sarà almeno un worker di preprocessing libero per i dati raccolti.

Pipeline di elaborazione dei valori

L'elaborazione dei valori degli item viene eseguita in più passaggi (o fasi) da più processi. Questo può causare:

• Un item dipendente può ricevere valori, mentre il valore master NON può. Questo può essere ottenuto utilizzando il seguente caso d'uso:
  • L'item master ha il tipo di valore UINT (può essere utilizzato un item trapper), l'item dipendente ha il tipo di valore TEXT.
  • Non sono richiesti passaggi di preprocessing né per l'item master né per l'item dipendente.
  • Un valore testuale (ad esempio, "abc") deve essere passato all'item master.
  • Poiché non ci sono passaggi di preprocessing da eseguire, il gestore del preprocessing verifica che l'item master non sia nello stato NOT SUPPORTED e che il valore sia impostato (entrambe le condizioni sono vere) e mette in coda l'item dipendente con lo stesso valore dell'item master (poiché non ci sono passaggi di preprocessing).
  • Quando sia l'item master sia l'item dipendente raggiungono la fase di sincronizzazione della history, l'item master diventa NOT SUPPORTED a causa dell'errore di conversione del valore (i dati testuali non possono essere convertiti in un intero senza segno).

Di conseguenza, l'item dipendente riceve un valore, mentre l'item master cambia il proprio stato in NOT SUPPORTED.

• Un item dipendente riceve un valore che non è presente nella history dell'item master. Il caso d'uso è molto simile al precedente, tranne per il tipo dell'item master. Ad esempio, se per l'item master viene utilizzato il tipo CHAR, allora il valore dell'item master verrà troncato nella fase di sincronizzazione della history, mentre gli item dipendenti riceveranno i propri valori dal valore iniziale (non troncato) dell'item master.