2 Detalls de preprocessament

Vista general

Aquesta secció proporciona detalls sobre el preprocessament del valor de l'article. El preprocessament del valor d'element us permet definir i executar regles de transformació per als valors d'element rebuts.

El preprocessament es gestiona mitjançant un procés gestor de preprocessament, així com agents de preprocessament que executen passes de preprocessament. Tots els valors (amb o sense preprocessament) dels diferents recopiladors de dades passen pel controlador de preprocessament abans d'afegir-se a la memòria cau de l'historial. La comunicació IPC basada en socket s'empra entre els col·lectors de dades (pollers, trappers, etc.) i el procés de preprocessament. El servidor Zabbix o el proxy Zabbix (per als elements monitorats pel proxy) realitza les passes de preprocessament.

Processament del valor de l'element

Per visualitzar el flux de dades de la font de dades a la base de dades Zabbix, podem emprar el següent diagrama simplificat:

El diagrama anterior només mostra els processos, objectes i accions relacionades amb el processament del valor de l'element en una forma simplificada. El diagrama no mostra canvis de direcció condicionals, tractament d'errors ni bucles. Tampoc es mostra la memòria cau de dades locals del gestor de preprocessament perquè no afecta directament el flux de dades. L'objectiu d'aquest diagrama és mostrar els processos implicats en el processament del valor dels elements i com interactuen.

  • La recollida de dades comença amb dades en brut d'una font de dades. En aquest moment, les dades només contenen ID, marca de temps i valor (també poden ser diversos valors)
  • Independentment del tipus de col·lector de dades emprat, la idea és la mateixa per a controls actius o passius, per a elements trapper, etc., ja que només canvia el format de les dades i l'inici de la comunicació (o el col·lector de dades és esperant una connexió i dades, o el recollidor de dades inicia la comunicació i demana les dades). Les dades en brut es validen, la configuració de l'element es recupera de la memòria cau de configuració (les dades s'enriqueixen amb dades de configuració).
  • El mecanisme IPC basat en socket s'empra per passar dades dels col·lectors de dades al gestor de preprocessament. En aquest punt, el recopilador de dades continua recopilant dades sense esperar la resposta del gestor de preprocessament.
  • Es fa un pretractament de dades. Això inclou fer passes de preprocessament i processar elements dependents.

L'element pot canviar d'estat a NO SOPORTAT durant el preprocessament si alguna de les passes de preprocessament falla.

  • Les dades de l'historial de la memòria cau de dades local del gestor de preprocessament s'envien a la memòria cau de l'historial.
  • En aquest punt, el flux de dades s'atura fins a la següent sincronització de la memòria cau de l'historial (quan el procés de sincronització de l'historial realitza la sincronització de dades).
  • El procés de sincronització comença amb la normalització de dades emmagatzemant dades a la base de dades Zabbix. La normalització de dades realitza conversions al tipus d'element esperat (tipus definit a la configuració de l'element), inclòs el truncament de les dades textuals segons les mides predefinides permeses per a aquests tipus (HISTORY_STR_VALUE_LEN per a la cadena, HISTORY_TEXT_VALUE_LEN per a text i HISTORY_LOG_VALUE_LEN per als valors de registre). Les dades s'envien a la base de dades Zabbix després de la normalització.

L'element pot canviar d'estat a NO SOPORTAT si la normalització de dades falla (per exemple, quan el valor del text no es pot convertir a nombre).

  • S'estan processant les dades recollides: es comproven els triggers, s'actualitza la configuració de l'element si l'element no és compatible, etc.
  • Es considera el final del flux de dades des del punt de vista del processament del valor de l'element.

Preprocessament del valor de l'article

El preprocessament de les dades es realitza en els passos següents:

  • El valor de l'element es passa al gestor de preprocessament mitjançant un mecanisme IPC basat en sòcols UNIX.
  • Si l'element no té elements de preprocessament ni dependents, el seu valor s'afegeix a la memòria cau de l'historial o s'envia al gestor de LLD. D'una altra manera:
    • Es crea una tasca de preprocessament i s'afegeix a la cua i els treballadors de preprocessament reben una notificació sobre la nova tasca.
    • En aquest punt, el flux de dades s'atura fins que hi hagi almenys un treballador de preprocessament desocupat (és a dir, no executant cap tasca).
    • Quan un treballador de preprocessament és disponible, pren la següent tasca de la cua.
    • Un cop finalitzat el preprocessament (tant amb l'execució fallida com amb l'èxit dels passos de preprocessament), el valor preprocessat s'afegeix a la cua de tasques acabades i el gestor rep una notificació sobre una nova tasca acabada.
    • El gestor de preprocessament converteix el resultat al format desitjat (definit pel tipus de valor d'element) i l'afegeix a la memòria cau de l'historial o l'envia al gestor de LLD.
    • Si hi ha elements dependents per a l'element processat, els elements dependents s'afegeixen a la cua de preprocessament amb el valor de l'element principal preprocessat. Els elements dependents es posen a la cua sense passar per alt les sol·licituds de preprocessament del valor normal, però només per als elements mestres amb el valor establert i no en un estat NO SUPORTAT.

Tingueu en compte que al diagrama el preprocessament de l'element principal es simplifica lleugerament si omet la memòria cau del preprocessament.

Cua de preprocessament

La cua de preprocessament s'organitza com:

  • llista de tasques pendents:
    • tasques creades directament a partir de peticions de preprocessament de valors en l'ordre en què es van rebre.
  • llista de tasques immediates (processades abans de les tasques pendents):
    • tasques de prova (creades com a resposta a les peticions de prova d'elements/preprocessament per part del frontend)
    • tasques d'elements dependents
    • tasques de seqüència (tasques que s'han d'executar en un ordre estricte):
      • tenir passos de preprocessament emprant el darrer valor:
        • canviar
        • estrangulament
        • JavaScript (emmagatzematge en memòria cau de bytecode)
      • memòria cau del preprocessament d'elements dependents
  • la llista de tasques acabades

Preprocessament de la memòria cau

La memòria cau del preprocessament es va introduir per millorar el rendiment del preprocessament per a diversos elements dependents amb passes de preprocessament similars (que és un resultat comú de LLD).

La memòria cau es fa preprocessant un element dependent i reutilitzant algunes de les dades de preprocessament intern per a la resta d'elements dependents. La memòria cau de preprocessament només s'admet a la primera passa de preprocessament dels tipus següents:

  • Patró Prometheus (índexs introduïts per mètriques)
  • JSONPath (analitza les dades a l'arbre d'objectes i indexa la primera expressió [?(@.path == "valor")])

Processos de treball de preprocessament

El fitxer de configuració del servidor Zabbix permet als usuaris establir el nombre de processos de treball de preprocessament. El paràmetre de configuració StartPreprocessors s'ha d'emprar per establir el nombre d'instàncies pre-bifurcades dels processos de treball de preprocessament. El nombre òptim de processos de treball de preprocessament es pot determinar per molts factors, inclòs el nombre d'elements "preprocessables" (elements que requereixen que es facin passes de preprocessament), el nombre de processos de recollida de dades, el nombre mitjà de passes per al preprocessament d'elements, etc. .

Però suposant que no hi hagi operacions de preprocessament pesades com ara l'anàlisi de grans blocs XML/JSON, el nombre de processos de treball de preprocessament pot coincidir amb el nombre total de recopiladors de dades. D'aquesta manera hi haurà la majoria de les vegades (excepte en els casos en què les dades del col·lector arriben mica en mica) almenys un preprocessador inactiu per a les dades recollides.

Massa processos de recollida de dades (enquestadors, enquestadors d'inaccessibilitat, enquestadors ODBC, enquestadors HTTP, pollers Java, pingers, trappers, proxypollers) associats amb el gestor IPMI, el trapper SNMP i els agents de preprocessament poden esgotar el límit de descriptors de fitxer per procés per al gestor de preprocessament. Això farà que el servidor Zabbix s'aturi (normalment poc després de l'inici, però de vegades pot trigar més). S'ha de revisar el fitxer de configuració o pujar el límit per evitar aquesta situació.

Pipeline del processament del valor

El processament del valor de l'article es fa en múltiples passos (o fases) mitjançant diversos processos. Això pot dur a:

  • L'element dependent pot rebre valors, a diferència del valor principal. Això es pot aconseguir emprant el següent cas d'ús:
    • L'element principal té el tipus de valor "UINT" (es pot emprar l'element trapper), l'element dependent té el tipus de valor "TEXT".
    • No es requereix cap passa de preprocessament per als elements principals i dependents.
    • El valor de text (com "abc") s'ha de passar a l'element principal.
    • Com que no hi ha passes de preprocessament per executar, el controlador de preprocessament comprova si l'element principal no es troba en l'estat NO SUPORTAT i si el valor és establert (tots dos són certs) posa en cua l'element dependent amb el mateix valor que l'element principal (perquè no hi ha cap passa de preprocessament).
    • Quan els elements primaris i dependents arriben a la fase de sincronització de l'historial, l'element principal passa a NO SUPORTAT, a causa de l'error de conversió de valors (les dades de text no es poden convertir a un nombre enter sense signe).

Per tant, l'element dependent rep un valor, mentre que l'element principal canvia el seu estat a NO SUPORTAT.

  • L'element dependent rep un valor que no és present a l'històric de l'element principal. El cas d'ús és molt semblant a l'anterior, excepte pel tipus d'element principal. Per exemple, si s'empra el tipus CHAR per a l'element principal, el valor de l'element principal es truncarà durant la fase de sincronització de l'historial, mentre que els elements dependents rebran el seu valor del valor inicial (no truncat) de l'element principal.