2 Priekšapstrādes detaļas

Pārskats

Šajā sadaļā ir sniegta informācija par vienumu vērtību priekšapstrādi. Vienumu vērtību priekšapstrāde ļauj definēt un izpildīt saņemtajām vienumu vērtībām transformācijas noteikumus.

Priekšapstrādi pārvalda priekšapstrādes pārvaldnieka process kopā ar priekšapstrādes darbiniekiem, kas izpilda priekšapstrādes soļus. Visas vērtības ar priekšapstrādi, kas saņemtas no dažādiem datu ievācējiem, pirms to pievienošanas vēstures kešatmiņai iziet caur priekšapstrādes pārvaldnieku. Saziņai, kas balstīta uz ligzdām, tiek izmantota IPC starp datu ievācējiem (aptaujātājiem, uztvērējiem u.c.) un priekšapstrādes procesu. Priekšapstrādes soļus 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 līdz Zabbix datubāzei, varam izmantot šādu vienkāršotu diagrammu:

Iepriekš redzamajā diagrammā vienkāršotā veidā ir parādīti tikai tie procesi, objekti un darbības, kas saistīti ar vienuma vērtības apstrādi. Diagrammā nav attēlotas nosacītas virziena maiņas, kļūdu apstrāde vai cikli. Tāpat nav parādīta 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ības 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, laika zīmogu un vērtību (iespējamas arī vairākas vērtības).
• Neatkarīgi no tā, kāds datu ieguvēja tips tiek izmantots, pamatideja ir vienāda gan aktīvajām, gan pasīvajām pārbaudēm, trapper vienumiem u.c., jo mainās tikai datu formāts un komunikācijas iniciators (vai nu datu ieguvējs gaida savienojumu un datus, vai arī datu ieguvējs uzsāk komunikāciju un pieprasa datus). Neapstrādātie dati tiek validēti, un vienuma konfigurācija tiek iegūta no konfigurācijas kešatmiņas (dati tiek papildināti ar konfigurācijas datiem).
• Lai nodotu datus no datu ieguvējiem priekšapstrādes pārvaldniekam, tiek izmantots uz ligzdām balstīts IPC mehānisms. Šajā brīdī datu ieguvējs turpina iegūt 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.

• Vēstures dati no priekšapstrādes pārvaldnieka lokālās datu kešatmiņas tiek pārvietoti uz vēstures kešatmiņu.
• Š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ēšanu pirms datu saglabāšanas Zabbix datubāzē. Datu normalizēšana veic pārveidošanu uz vēlamo vienuma tipu (tipu, kas definēts vienuma konfigurācijā), tostarp teksta datu saīsināšanu atbilstoši iepriekš noteiktajiem izmēriem, kas ir atļauti šiem tipiem (HISTORY_STR_VALUE_LEN virknei, HISTORY_TEXT_VALUE_LEN tekstam un HISTORY_LOG_VALUE_LEN žurnāla vērtībām). Pēc normalizēšanas pabeigšanas dati tiek nosūtīti uz Zabbix datubāzi.

• Iegūtie dati tiek apstrādāti — tiek pārbaudīti trigeri, atjaunināta vienuma konfigurācija, ja vienums kļūst par NOT SUPPORTED, utt.
• No vienuma vērtības apstrādes viedokļa tas tiek uzskatīts par datu plūsmas beigu punktu.

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 ligzdām balstītu IPC mehānismu.
• Tiek izveidots priekšapstrādes uzdevums, 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., neizpilda 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ā (to 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, tad atkarīgie vienumi 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ību priekšapstrādes pieprasījumus, bet tikai galvenajiem vienumiem ar iestatītu vērtību, kas 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š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.