2 Priekšapstrādes detaļas

Pārskats

Šī sadaļa sniedz informāciju par vienuma vērtības pirmapstrādi. Vienuma vērtības pirmapstrāde ļauj definēt un izpildīt transformācijas noteikumus saņemtajām vienuma vērtībām.

Pirmapstrādi pārvalda pirmapstrādes pārvaldnieka process kopā ar pirmapstrādes darbiniekiem, kas veic pirmapstrādes soļus. Visas vērtības ar pirmapstrādi (pirms Zabbix 7.4.1 — visas vērtības), kas saņemtas no dažādiem datu ievācējiem, pirms pievienošanas vēstures kešatmiņai iziet caur pirmapstrādes pārvaldnieku. Starp datu ievācējiem (aptaujātājiem, traperiem u. c.) un pirmapstrādes procesu tiek izmantota uz ligzdām balstīta IPC saziņa. Pirmapstrādes soļus veic vai nu Zabbix serveris, vai Zabbix starpniekserveris (vienumiem, ko uzrauga starpniekserveris).

Vienuma vērtību apstrāde

Lai vizualizētu datu plūsmu no datu avota uz Zabbix datubāzi, varam izmantot šādu vienkāršotu diagrammu:

Iepriekš redzamajā diagrammā vienkāršotā veidā ir attēloti tikai tie procesi, objekti un darbības, kas saistīti ar vienuma vērtību apstrādi. Diagrammā nav parādītas nosacītas virziena maiņ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 procesus, kas iesaistīti vienuma vērtību apstrādē, un to savstarpējo mijiedarbību.

• Datu iegūšana sākas ar neapstrādātiem datiem no datu avota. Šajā brīdī dati satur tikai ID, laikspiedolu un vērtību (var būt arī vairākas vērtības).
• Neatkarīgi no tā, kāda veida datu savācējs tiek izmantots, princips ir tāds pats aktīvajām vai pasīvajām pārbaudēm, trapper vienumiem u. c., jo tas maina tikai datu formātu un komunikācijas iniciatoru (vai nu datu savācējs gaida savienojumu un datus, vai arī datu savācējs iniciē komunikāciju un pieprasa datus). Neapstrādātie dati tiek validēti, vienuma konfigurācija tiek izgūta no konfigurācijas kešatmiņas (dati tiek papildināti ar konfigurācijas datiem).
• Lai nodotu datus no datu savācējiem uz priekšapstrādes pārvaldnieku, tiek izmantots uz ligzdām balstīts IPC mehānisms. Šajā brīdī datu savācējs turpina vākt datus, negaidot atbildi no priekšapstrādes pārvaldnieka.
• Tiek veikta datu priekšapstrāde. Tas ietver priekšapstrādes soļu izpildi un atkarīgo vienumu apstrādi.

• Priekšapstrādes pārvaldnieka lokālajā datu kešatmiņā esošie vēstures dati tiek iztukšoti vēstures kešatmiņā.
• Šajā brīdī datu plūsma apstājas līdz nākamajai vēstures kešatmiņas sinhronizācijai (kad history syncer process veic datu sinhronizāciju).
• Sinhronizācijas process sākas ar datu normalizāciju pirms datu saglabāšanas Zabbix datubāzē. Datu normalizācija 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_LEN string tipam, HISTORY_TEXT_VALUE_LEN text tipam un HISTORY_LOG_VALUE_LEN log vērtībām). Pēc normalizācijas pabeigšanas dati tiek nosūtīti uz Zabbix datubāzi.

• Iegūtie dati tiek apstrādāti - tiek pārbaudīti trigeri, vienuma konfigurācija tiek atjaunināta, ja vienums kļūst par NOT SUPPORTED, u. c.
• No vienuma vērtību 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 šādos soļos:

• Ja vienumam nav ne priekšapstrādes, ne atkarīgo vienumu, tā vērtība tiek vai nu 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 socket balstītu IPC mehānismu (pirms Zabbix 7.4.1 visas vērtības tika nodotas caur priekšapstrādes pārvaldnieku pirms pievienošanas vēstures kešatmiņai vai nosūtīšanas LLD pārvaldniekam).
• Tiek izveidots priekšapstrādes uzdevums, tas tiek 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 (t. i., neveic nevienu uzdevumu) priekšapstrādes darbinieks.
• Kad priekšapstrādes darbinieks ir pieejams, tas paņem nākamo uzdevumu no rindas.
• Pēc priekšapstrādes pabeigšanas (gan neveiksmīgas, gan veiksmīgas priekšapstrādes soļu izpildes gadījumā) 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ā (definētā pēc vienuma vērtības tipa) 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 ar priekšapstrādāto galvenā vienuma vērtību. Atkarīgie vienumi tiek ievietoti rindā, apejot parastos vērtības priekšapstrādes pieprasījumus, bet tikai galvenajiem vienumiem ar iestatītu vērtību un neatrodoties NOT SUPPORTED stāvoklī.

Ņemiet vērā, ka diagrammā galvenā vienuma priekšapstrāde ir nedaudz vienkāršota, izlaižot priekšapstrādes kešatmiņošanu.

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 (tiek apstrādāti pirms gaidošajiem uzdevumiem):

  • testēšanas uzdevumi (izveidoti, atbildot uz vienuma/priekšapstrādes testēšanas pieprasījumiem no lietotāja saskarnes)
  • atkarīgo vienumu uzdevumi
  • secības uzdevumi (uzdevumi, kas jāizpilda stingrā secībā):
    • ar priekšapstrādes soļiem, kuros tiek izmantota pēdējā vērtība:
      • izmaiņa
      • ierobežošana
      • JavaScript (baitkoda kešošana)
    • atkarīgo vienumu priekšapstrādes kešošana

• pabeigto uzdevumu saraksts

Priekšapstrādes kešošana

Priekšapstrādes kešošana tika ieviesta, lai uzlabotu priekšapstrādes veiktspēju vairākiem atkarīgajiem vienumiem ar līdzīgām priekšapstrādes darbībām (tas ir bieži sastopams LLD rezultāts).

Kešošana tiek veikta, priekšapstrādājot vienu atkarīgo vienumu un atkārtoti izmantojot daļu no iekšējiem priekšapstrādes datiem pārējiem atkarīgajiem vienumiem. Priekšapstrādes kešatmiņa tiek atbalstīta tikai pirmajā šādu tipu priekšapstrādes solī:

• Prometheus pattern (indeksē ievadi pēc metrikām)
• JSONPath (parsē datus objektu kokā un indeksē pirmo izteiksmi [?(@.path == "value")])

Priekšapstrādes darbinieki

Zabbix servera konfigurācijas fails ļauj lietotājiem iestatīt priekšapstrādes darbinieku pavedienu skaitu. Konfigurācijas parametrs StartPreprocessors jāizmanto, lai iestatītu iepriekš palaisto priekšapstrādes darbinieku instanču skaitu, kam vismaz jāatbilst pieejamo CPU kodolu skaitam.

Ja priekšapstrādes uzdevumi nav saistīti ar CPU noslodzi un ietver biežus tīkla pieprasījumus, ieteicams konfigurēt papildu darbiniekus. Optimālo priekšapstrādes darbinieku skaitu var noteikt daudzi faktori, tostarp "priekšapstrādājamo" vienumu skaits (vienumi, kuriem jāizpilda jebkādi priekšapstrādes soļi), datu ievākšanas procesu skaits, vidējais vienuma priekšapstrādes soļu skaits utt. Nepietiekams darbinieku skaits var izraisīt lielu atmiņas patēriņu. Lai novērstu pārmērīga atmiņas patēriņa problēmas jūsu Zabbix instalācijā, skatiet Pārmērīga atmiņas patēriņa profilēšana ar tcmalloc.

Tomēr, pieņemot, ka nav smagu priekšapstrādes darbību, piemēram, lielu XML/JSON fragmentu parsēšanas, priekšapstrādes darbinieku skaits var atbilst kopējam datu ievācēju skaitam. Tādējādi lielākoties (izņemot gadījumus, kad dati no ievācēja tiek saņemti paketēs) savāktajiem datiem būs pieejams vismaz viens neizmantots priekšapstrādes darbinieks.

Vērtību apstrādes konveijers

Vienuma vērtību apstrāde tiek izpildīta vairākos soļos (vai fāzēs) ar vairāku procesu palīdzību. Tas var izraisīt:

• Atkarīgais vienums var saņemt vērtības, kamēr GALVENĀ vērtība to nevar. To var panākt, izmantojot šādu lietošanas gadījumu:
  • Galvenajam vienumam ir vērtības tips UINT (var izmantot trapper vienumu), atkarīgajam vienumam ir vērtības tips TEXT.
  • Ne galvenajam, ne atkarīgajam vienumam nav nepieciešami priekšapstrādes soļi.
  • Teksta vērtība (piemēram, "abc") ir jānodod galvenajam vienumam.
  • Tā kā nav izpildāmu priekšapstrādes soļu, priekšapstrādes pārvaldnieks pārbauda, vai galvenais vienums nav stāvoklī NOT SUPPORTED un vai vērtība ir iestatīta (abi nosacījumi ir patiesi), un ievieto rindā atkarīgo vienumu ar tādu pašu vērtību kā galvenajam vienumam (jo nav priekšapstrādes soļu).
  • Kad gan galvenais, gan atkarīgais vienums sasniedz vēstures sinhronizācijas fāzi, galvenais vienums kļūst par NOT SUPPORTED vērtības konvertēšanas kļūdas dēļ (teksta datus nevar konvertēt par unsigned integer).

Rezultātā atkarīgais vienums saņem vērtību, kamēr galvenais vienums maina savu stāvokli uz NOT SUPPORTED.

• Atkarīgais vienums saņem vērtību, kas nav atrodama 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 tips CHAR, tad galvenā vienuma vērtība vēstures sinhronizācijas fāzē tiks saīsināta, kamēr atkarīgie vienumi saņems savas vērtības no galvenā vienuma sākotnējās (nesaīsinātās) vērtības.