[comment]: # ({30385a91-30385a91})
# 2 Dettagli di preelaborazione
[comment]: # ({/30385a91-30385a91})
[comment]: # ({e20db496-67b39eda})
#### 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](/manual/config/items/preprocessing) per i valori degli item ricevuti.
Il preprocessing è gestito dal processo preprocessing manager insieme ai worker di preprocessing che eseguono le fasi di preprocessing.
Tutti i valori con preprocessing (prima di Zabbix 7.0.17, tutti i valori), ricevuti da diversi data gatherer, passano attraverso il preprocessing manager prima di essere aggiunti alla cache della history.
La comunicazione IPC basata su socket viene utilizzata tra i data gatherer (poller, trapper, ecc.) e il processo di preprocessing. Le fasi di preprocessing vengono eseguite da Zabbix server oppure da Zabbix proxy (per gli item monitorati dal proxy).
[comment]: # ({/e20db496-67b39eda})
[comment]: # ({cbc4231a-7aff5db5})
#### Elaborazione del valore dell'item
Per visualizzare il flusso dei dati dalla sorgente dati al database di Zabbix, possiamo usare il seguente diagramma semplificato:
Il diagramma sopra mostra solo processi, oggetti e azioni relativi all'elaborazione del valore dell'item in forma **semplificata**. Il diagramma non mostra i cambiamenti condizionali di direzione, la gestione degli errori o i cicli. Anche la cache dati locale del manager di preprocessing non è mostrata perché non influisce direttamente sul flusso dei dati. L'obiettivo 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 i dati grezzi provenienti da una sorgente dati. In questo punto, i dati contengono solo ID, timestamp e valore (possono essere presenti anche più valori).
- Indipendentemente dal tipo di data gatherer utilizzato, il principio è lo stesso per i controlli attivi o passivi, per gli item trapper, ecc., poiché cambia solo il formato dei dati e l'iniziatore della comunicazione (o il data gatherer è in attesa di una connessione e dei dati, oppure il data gatherer 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).
- Viene utilizzato un meccanismo IPC basato su socket per passare i dati dai data gatherer al manager di preprocessing. In questo punto il data gatherer continua a raccogliere dati senza attendere la risposta dal manager di preprocessing.
- Viene eseguito il preprocessing dei dati. Questo include l'esecuzione delle fasi di preprocessing e l'elaborazione degli item dipendenti.
::: noteclassic
Un item può cambiare il proprio stato in NOT SUPPORTED durante l'esecuzione del preprocessing se una qualsiasi delle fasi di preprocessing fallisce.
:::
- I dati storici dalla cache dati locale del manager di preprocessing vengono svuotati nella history cache.
- In questo punto il flusso dei dati si interrompe fino alla successiva sincronizzazione della history cache (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 le conversioni nel tipo di item desiderato (tipo definito nella configurazione dell'item), inclusa la troncatura dei dati testuali in base alle [dimensioni predefinite](/manual/config/items/item#text-data-limits) consentite per tali tipi (HISTORY\_STR\_VALUE\_LEN per string, HISTORY\_TEXT\_VALUE\_LEN per text e HISTORY\_LOG\_VALUE\_LEN per i valori log). I dati vengono inviati al database di Zabbix dopo il completamento della normalizzazione.
::: noteclassic
Un item può cambiare il proprio stato in NOT SUPPORTED se la normalizzazione dei dati fallisce
(ad esempio, quando un valore testuale non può essere convertito in numero).
:::
- I dati raccolti vengono elaborati: i trigger vengono controllati, la configurazione dell'item viene aggiornata se l'item diventa NOT SUPPORTED, ecc.
- Questo è considerato la fine del flusso dei dati dal punto di vista dell'elaborazione del valore dell'item.
[comment]: # ({/cbc4231a-7aff5db5})
[comment]: # ({107e489a-44da8577})
#### Preprocessing del valore dell'item
La pre-elaborazione dei dati viene eseguita nei seguenti passaggi:
- Se l'item non ha né pre-elaborazione né item dipendenti, il suo valore viene aggiunto alla cache della cronologia oppure inviato al gestore LLD. In caso contrario, il valore dell'item viene passato al gestore di pre-elaborazione tramite un meccanismo IPC basato su socket UNIX (prima di Zabbix 7.0.17, tutti i valori venivano passati attraverso il gestore di pre-elaborazione prima di essere aggiunti alla cache della cronologia o inviati al gestore LLD).
- Viene creato un task di pre-elaborazione e aggiunto alla coda, e i worker di pre-elaborazione vengono notificati del nuovo task.
- A questo punto il flusso dei dati si interrompe finché non è disponibile almeno un worker di pre-elaborazione libero (cioè non impegnato nell'esecuzione di alcun task).
- Quando un worker di pre-elaborazione è disponibile, preleva il task successivo dalla coda.
- Dopo il completamento della pre-elaborazione (sia in caso di esito negativo sia positivo dei passaggi di pre-elaborazione), il valore pre-elaborato viene aggiunto alla coda dei task completati e il manager viene notificato di un nuovo task completato.
- Il gestore di pre-elaborazione 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 pre-elaborazione con il valore pre-elaborato dell'item master. Gli item dipendenti vengono accodati bypassando le normali richieste di pre-elaborazione del valore, ma solo per gli item master con il valore impostato e non in stato NOT SUPPORTED.
{width="600"}
Si noti che nel diagramma la pre-elaborazione dell'item master è leggermente semplificata omettendo la memorizzazione nella cache della pre-elaborazione.
[comment]: # ({/107e489a-44da8577})
[comment]: # ({73f49808-4b6fc468})
#### 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
[comment]: # ({/73f49808-4b6fc468})
[comment]: # ({abb85873-c9d6405f})
#### 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")]`)
[comment]: # ({/abb85873-c9d6405f})
[comment]: # ({c79ec0eb-98589fcd})
#### 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](/manual/appendix/config/zabbix_server#startpreprocessors) deve essere usato per impostare il numero di istanze avviate in anticipo dei worker di preprocessing, che dovrebbe essere almeno pari al numero di core CPU disponibili.
Se le attività di preprocessing non sono vincolate dalla CPU e comportano frequenti richieste di rete, è consigliabile configurare worker aggiuntivi.
Il numero ottimale di worker di preprocessing può essere determinato da molti fattori, tra cui il numero di item "preprocessable" (item che richiedono l'esecuzione di qualsiasi fase di preprocessing), il numero di processi di raccolta dati, il numero medio di fasi di preprocessing per item, ecc.
Un numero insufficiente di worker può portare a un elevato utilizzo della memoria. Per la risoluzione dei problemi relativi a un uso eccessivo della memoria nella tua installazione di Zabbix, consulta [Profiling excessive memory usage with tcmalloc](/manual/installation/known_issues#profiling-excessive-memory-usage-with-tcmalloc).
Tuttavia, supponendo che non vi siano operazioni di preprocessing pesanti come l'analisi di grandi blocchi XML/JSON, il numero di worker di preprocessing può corrispondere al numero totale di raccoglitori di dati. In questo modo, nella maggior parte dei casi (tranne quando i dati provenienti dal raccoglitore arrivano in blocco) ci sarà almeno un worker di preprocessing non occupato per i dati raccolti.
::: notewarning
Troppi processi di raccolta dati (poller, unreachable poller, ODBC poller, HTTP poller, Java poller, pinger, trapper, proxypoller) insieme a IPMI manager, SNMP trapper e worker di preprocessing possono esaurire il limite di file descriptor per processo del preprocessing manager.
L'esaurimento del limite di file descriptor per processo causerà l'arresto di Zabbix server, in genere poco dopo l'avvio ma talvolta dopo più tempo.
Per evitare tali problemi, esamina il [file di configurazione di Zabbix server](/manual/appendix/config/zabbix_server) per ottimizzare il numero di controlli e processi concorrenti.
Inoltre, se necessario, assicurati che il limite dei file descriptor sia impostato sufficientemente in alto controllando e regolando i limiti di sistema.
:::
[comment]: # ({/c79ec0eb-98589fcd})
[comment]: # ({a459312a-ad691011})
##### 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.
[comment]: # ({/a459312a-ad691011})