2 Priekšapstrādes detaļas
Pārskats
Šajā sadaļā ir sniegta informācija par vienuma vērtību priekšapstrādi. Vienuma vērtību priekšapstrāde ļauj definēt un izpildīt transformācijas noteikumus saņemtajām vienuma vērtībām.
Priekšapstrādi pārvalda priekšapstrādes pārvaldnieka process kopā ar priekšapstrādes darba procesiem, kas izpilda priekšapstrādes darbības. Visas vērtības, kurām tiek veikta priekšapstrāde (pirms Zabbix 7.4.1 — visas vērtības), kas saņemtas no dažādiem datu ieguves procesiem, pirms pievienošanas vēstures kešatmiņai iziet cauri priekšapstrādes pārvaldniekam. Saziņai starp datu ieguves procesiem (aptaujātājiem, uztvērējiem u. c.) un priekšapstrādes procesu tiek izmantota uz ligzdām balstīta IPC saziņa. Priekšapstrādes darbības izpilda vai nu Zabbix serveris, vai Zabbix starpniekserveris (vienumiem, kurus uzrauga starpniekserveris).
Vienuma vērtības apstrāde
Lai vizualizētu datu plūsmu no datu avota uz Zabbix datubāzi, var izmantot šo vienkāršoto diagrammu:

Iepriekš redzamajā diagrammā vienkāršotā veidā ir parādīti tikai procesi, objekti un darbības, kas saistītas ar vienuma vērtības apstrādi. Diagrammā nav parādītas nosacītas virziena izmaiņas, kļūdu apstrāde vai cikli. Nav parādīta arī priekšapstrādes pārvaldnieka lokālā datu kešatmiņa, jo tā tieši neietekmē datu plūsmu. Šīs diagrammas mērķis ir parādīt vienuma vērtības apstrādē iesaistītos procesus un to mijiedarbību.
- Datu apkopošana sākas ar neapstrādātiem datiem no datu avota. Šajā brīdī dati satur tikai ID, laika zīmogu un vērtību (var būt arī vairākas vērtības).
- Neatkarīgi no izmantotā datu apkopotāja veida ideja aktīvajām vai pasīvajām pārbaudēm, trapper vienumiem u. c. ir tāda pati, jo mainās tikai datu formāts un komunikācijas iniciators (vai nu datu apkopotājs gaida savienojumu un datus, vai arī datu apkopotājs sāk komunikāciju un pieprasa datus). Neapstrādātie dati tiek validēti, un vienuma konfigurācija tiek izgūta no konfigurācijas kešatmiņas (dati tiek papildināti ar konfigurācijas datiem).
- Datu pārsūtīšanai no datu apkopotājiem uz priekšapstrādes pārvaldnieku tiek izmantots uz ligzdām balstīts IPC mehānisms. Šajā brīdī datu apkopotājs turpina apkopot datus, negaidot atbildi no priekšapstrādes pārvaldnieka.
- Tiek veikta datu priekšapstrāde. Tā ietver priekšapstrādes darbību izpildi un atkarīgo vienumu apstrādi.
Priekšapstrādes laikā vienuma stāvoklis var mainīties uz NOT SUPPORTED, ja kāda no priekšapstrādes darbībām neizdodas.
- Vēstures dati no priekšapstrādes pārvaldnieka lokālās datu kešatmiņas tiek izvadīti vēstures kešatmiņā.
- Šajā brīdī datu plūsma apstājas līdz nākamajai vēstures kešatmiņas sinhronizācijai (kad vēstures sinhronizētāja process veic datu sinhronizāciju).
- Sinhronizācijas process sākas ar datu normalizēšanu pirms datu saglabāšanas Zabbix datubāzē.
Datu normalizēšana veic konvertēšanu uz vēlamo vienuma tipu (tipu, kas definēts vienuma konfigurācijā), tostarp teksta datu saīsināšanu, pamatojoties uz iepriekš definētajiem izmēriem, kas atļauti šiem tipiem (
HISTORY_STR_VALUE_LENvirknei,HISTORY_TEXT_VALUE_LENtekstam unHISTORY_LOG_VALUE_LENžurnāla vērtībām). Pēc normalizēšanas dati tiek nosūtīti uz Zabbix datubāzi.
Vienuma stāvoklis var mainīties uz NOT SUPPORTED, ja datu normalizēšana neizdodas (piemēram, ja teksta vērtību nevar konvertēt par skaitli).
- Apkopotie dati tiek apstrādāti — tiek pārbaudīti trigeri, atjaunināta vienuma konfigurācija, ja vienums kļūst par NOT SUPPORTED, u. c.
- No vienuma vērtības apstrādes viedokļa tas tiek uzskatīts par datu plūsmas beigām.
Vienuma vērtības priekšapstrāde
Datu priekšapstrāde tiek veikta, veicot tālāk norādītās darbības:
- Ja vienumam nav ne priekšapstrādes, ne atkarīgo vienumu, tā vērtība tiek pievienota vēstures kešatmiņai vai nosūtīta LLD pārvaldniekam. Pretējā gadījumā vienuma vērtība tiek nodota priekšapstrādes pārvaldniekam, izmantojot uz UNIX ligzdām balstītu IPC mehānismu (pirms Zabbix 7.4.1 visas vērtības tika nodotas caur priekšapstrādes pārvaldnieku, pirms tās tika pievienotas vēstures kešatmiņai vai nosūtītas LLD pārvaldniekam).
- Tiek izveidots priekšapstrādes uzdevums un pievienots rindai, un priekšapstrādes darbinieki tiek informēti par jauno uzdevumu.
- Šajā brīdī datu plūsma apstājas, līdz ir pieejams vismaz viens neaizņemts priekšapstrādes darbinieks (t. i., darbinieks, kas neizpilda nevienu uzdevumu).
- Kad priekšapstrādes darbinieks ir pieejams, tas paņem nākamo uzdevumu no rindas.
- Pēc priekšapstrādes pabeigšanas (neatkarīgi no tā, vai priekšapstrādes darbības ir izpildītas veiksmīgi vai neveiksmīgi) priekšapstrādātā vērtība tiek pievienota pabeigto uzdevumu rindai, un pārvaldnieks tiek informēts par jaunu pabeigtu uzdevumu.
- Priekšapstrādes pārvaldnieks pārveido rezultātu vajadzīgajā formātā (ko nosaka vienuma vērtības tips) un vai nu pievieno to vēstures kešatmiņai, vai nosūta LLD pārvaldniekam.
- Ja apstrādātajam vienumam ir atkarīgie vienumi, tie tiek pievienoti priekšapstrādes rindai kopā ar priekšapstrādāto galvenā vienuma vērtību. Atkarīgie vienumi tiek ievietoti rindā, apejot parastos vērtību priekšapstrādes pieprasījumus, taču tikai tiem galvenajiem vienumiem, kuriem ir iestatīta vērtība un kuri nav stāvoklī NOT SUPPORTED.

Ņemiet vērā, ka diagrammā galvenā vienuma priekšapstrāde ir nedaudz vienkāršota, izlaižot priekšapstrādes kešatmiņu.
Priekšapstrādes rinda
Priekšapstrādes rinda ir organizēta šādi:
- gaidošo uzdevumu saraksts:
- uzdevumi, kas izveidoti tieši no vērtību priekšapstrādes pieprasījumiem to saņemšanas secībā
- tūlītējo uzdevumu saraksts (apstrādāti pirms gaidošajiem uzdevumiem):
- testēšanas uzdevumi (izveidoti, reaģējot uz lietotāja saskarnes nosūtītajiem vienuma/priekšapstrādes testēšanas pieprasījumiem)
- atkarīgo vienumu uzdevumi
- secības uzdevumi (uzdevumi, kas jāizpilda stingrā secībā):
- kuros izmantotas priekšapstrādes darbības, kas izmanto pēdējo vērtību:
- izmaiņas
- ierobežošana
- JavaScript (baitu koda kešatmiņa)
- atkarīgo vienumu priekšapstrādes kešatmiņa
- kuros izmantotas priekšapstrādes darbības, kas izmanto pēdējo vērtību:
- pabeigto uzdevumu saraksts
Iepriekšapstrādes kešatmiņa
Iepriekšapstrādes kešatmiņa tika ieviesta, lai uzlabotu iepriekšapstrādes veiktspēju vairākiem atkarīgajiem vienumiem ar līdzīgiem iepriekšapstrādes soļiem (kas ir bieži sastopams LLD rezultāts).
Kešatmiņa tiek izmantota, iepriekšapstrādājot vienu atkarīgo vienumu un atkārtoti izmantojot daļu iekšējo iepriekšapstrādes datu pārējiem atkarīgajiem vienumiem. Iepriekšapstrādes kešatmiņa tiek atbalstīta tikai šādu tipu pirmajam iepriekšapstrādes solim:
- Prometheus pattern (indeksē ievadi pēc metrikām)
- JSONPath (parsē datus objektu kokā un indeksē pirmo izteiksmi
[?(@.path == "value")])
Iepriekšapstrādes darbinieki
Zabbix servera konfigurācijas fails ļauj lietotājiem iestatīt iepriekšapstrādes darbinieku pavedienu skaitu. Konfigurācijas parametrs StartPreprocessors jāizmanto, lai iestatītu iepriekš palaisto iepriekšapstrādes darbinieku eksemplāru skaitu, kam vajadzētu vismaz atbilst pieejamo CPU kodolu skaitam.
Ja iepriekšapstrādes uzdevumi nav saistīti ar CPU noslodzi un ietver biežus tīkla pieprasījumus, ieteicams konfigurēt papildu darbiniekus. Optimālo iepriekšapstrādes darbinieku skaitu var noteikt, ņemot vērā daudzus faktorus, tostarp "iepriekšapstrādājamo" vienumu skaitu (vienumi, kuriem jāizpilda jebkādi iepriekšapstrādes soļi), datu apkopošanas procesu skaitu, vidējo soļu skaitu vienuma iepriekšapstrādē u. c. Nepietiekams darbinieku skaits var izraisīt lielu atmiņas lietojumu. Lai novērstu pārmērīgu atmiņas lietojumu jūsu Zabbix instalācijā, skatiet Pārmērīga atmiņas lietojuma profilēšana ar tcmalloc.
Tomēr, pieņemot, ka netiek veiktas smagas iepriekšapstrādes darbības, piemēram, lielu XML/JSON datu fragmentu parsēšana, iepriekšapstrādes darbinieku skaits var atbilst kopējam datu apkopotāju skaitam. Tādējādi apkopotajiem datiem lielākoties (izņemot gadījumus, kad dati no apkopotāja tiek saņemti lielapjomā) būs pieejams vismaz viens neizmantots iepriekšapstrādes darbinieks.
Pārāk daudz datu apkopošanas procesu (aptaujātāji, nepieejamības aptaujātāji, ODBC aptaujātāji, HTTP aptaujātāji, Java aptaujātāji, pingotāji, uztvērēji, starpniekservera aptaujātāji) kopā ar IPMI pārvaldnieku, SNMP uztvērēju un iepriekšapstrādes darbiniekiem var izsmelt katram procesam pieejamo failu deskriptoru ierobežojumu iepriekšapstrādes pārvaldniekam.
Katra procesa failu deskriptoru ierobežojuma pārsniegšana izraisīs Zabbix servera darbības apturēšanu, parasti neilgi pēc palaišanas, taču dažkārt tas var aizņemt ilgāku laiku.
Lai izvairītos no šādām problēmām, pārskatiet Zabbix servera konfigurācijas failu, lai optimizētu vienlaicīgo pārbaužu un procesu skaitu.
Turklāt, ja nepieciešams, pārbaudiet un pielāgojiet sistēmas ierobežojumus, lai nodrošinātu pietiekami augstu failu deskriptoru ierobežojumu.
Vērtību apstrādes konveijers
Vienuma vērtību apstrādi vairākos soļos (jeb fāzēs) veic vairāki procesi. Tas var izraisīt tālāk norādīto.
- Atkarīgais vienums var saņemt vērtības, kamēr galvenais vienums tās nevar saņemt.
To var panākt, izmantojot šādu lietošanas gadījumu:
- Galvenajam vienumam ir
UINTvērtības tips (var izmantot trapper vienumu), bet atkarīgajam vienumam irTEXTvērtības tips. - Ne galvenajam, ne atkarīgajam vienumam nav nepieciešamas priekšapstrādes darbības.
- Galvenajam vienumam jānosūta teksta vērtība (piemēram, "abc").
- Tā kā nav izpildāmu priekšapstrādes darbību, priekšapstrādes pārvaldnieks pārbauda, vai galvenais vienums nav stāvoklī NOT SUPPORTED un vai ir iestatīta vērtība (abi nosacījumi ir izpildīti), un ievieto rindā atkarīgo vienumu ar tādu pašu vērtību kā galvenajam vienumam (jo nav priekšapstrādes darbību).
- Kad gan galvenais, gan atkarīgais vienums sasniedz vēstures sinhronizācijas fāzi, galvenais vienums kļūst par NOT SUPPORTED, jo rodas vērtības konvertēšanas kļūda (teksta datus nevar konvertēt uz neparakstītu veselu skaitli).
- Galvenajam vienumam ir
Rezultātā atkarīgais vienums saņem vērtību, bet galvenais vienums maina savu stāvokli uz NOT SUPPORTED.
- Atkarīgais vienums saņem vērtību, kas nav pieejama galvenā vienuma vēsturē.
Lietošanas gadījums ir ļoti līdzīgs iepriekšējam, izņemot galvenā vienuma tipu.
Piemēram, ja galvenajam vienumam tiek izmantots
CHARtips, galvenā vienuma vērtība vēstures sinhronizācijas fāzē tiks saīsināta, savukārt atkarīgie vienumi saņems savas vērtības no galvenā vienuma sākotnējās (nesaīsinātās) vērtības.