This is a translation of the original English documentation page. Help us make it better.

2 Детаљи претходне обраде

Преглед

Овај одељак пружа детаље о вредности предобраде корака ставке. Предобрада вредности ставке омогућава да се дефинишу и изврше правила трансформације за примљене вредности ставкe.

Предобрада управља процес менаџера за претходну обраду заједно са радницима за предобрадy који обављају кораке претходне обраде. Све вредности (са или без претходне обраде) од различитих сакупљача података пролазе кроз менаџер за предобраду пре него што се додају у кеш историје. IPC комуникација заснована на сокету се користи између сакупљача података (полери, трапери, итд.) и процеса предобраде. Или Zabbix сервер или Zabbix прокси (за ставке које надгледа проки) обављају кораке предобраде.

Item value processing

To visualize the data flow from data source to the Zabbix database, we can use the following simplified diagram:

The diagram above shows only processes, objects and actions related to item value processing in a simplified form. The diagram does not show conditional direction changes, error handling or loops. The local data cache of the preprocessing manager is not shown either because it doesn't affect the data flow directly. The aim of this diagram is to show processes involved in the item value processing and the way they interact.

  • Data gathering starts with raw data from a data source. At this point, the data contains only ID, timestamp and value (can be multiple values as well).
  • No matter what type of data gatherer is used, the idea is the same for active or passive checks, for trapper items, etc., as it only changes the data format and the communication starter (either data gatherer is waiting for a connection and data, or data gatherer initiates the communication and requests the data). The raw data is validated, the item configuration is retrieved from the configuration cache (data is enriched with the configuration data).
  • A socket-based IPC mechanism is used to pass data from data gatherers to the preprocessing manager. At this point the data gatherer continues to gather data without waiting for the response from preprocessing manager.
  • Data preprocessing is performed. This includes the execution of preprocessing steps and dependent item processing.

An item can change its state to NOT SUPPORTED while preprocessing is performed if any of preprocessing steps fail.

  • The history data from the local data cache of the preprocessing manager is being flushed into the history cache.
  • At this point the data flow stops until the next synchronization of history cache (when the history syncer process performs data synchronization).
  • The synchronization process starts with data normalization before storing data in Zabbix database. The data normalization performs conversions to the desired item type (type defined in item configuration), including truncation of textual data based on predefined sizes allowed for those types (HISTORY_STR_VALUE_LEN for string, HISTORY_TEXT_VALUE_LEN for text and HISTORY_LOG_VALUE_LEN for log values). The data is being sent to the Zabbix database after the normalization is done.

An item can change its state to NOT SUPPORTED if data normalization fails (for example, when a textual value cannot be converted to number).

  • The gathered data is being processed - triggers are checked, the item configuration is updated if item becomes NOT SUPPORTED, etc.
  • This is considered the end of data flow from the point of view of item value processing.

Претходна обрада вредности ставке

Претходна обрада података се врши у следећим корацима:

  • Вредност ставке се прослеђује менаџеру претходне обраде користећи UNIX IPC механизам заснован на сокету.
  • Ако ставка нема ни претходну обраду ни зависне ставке, њена вредност се или додаје у кеш историје или шаље LLD менаџеру. У супротном:
  • Креира се задатак претходне обраде и додаје се у ред, а радници претходне обраде се обавештавају о новом задатку.
  • У овом тренутку проток података се зауставља док не постоји барем један незаузет (тј. који не извршава ниједан задатак) радник претходне обраде.
  • Када је радник претходне обраде доступан, он преузима следећи задатак из реда.
  • Након што је претходна обрада завршена (и неуспешно и успешно извршавање корака претходне обраде), претходна вредност се додаје у ред завршених задатака, а менаџер се обавештава о новом завршеном задатку.
  • Менаџер претходне обраде конвертује резултат у жељени формат (дефинисан типом вредности ставке) и или га додаје у кеш историје или га шаље LLD менаџеру.
  • Ако постоје зависне ставке за обрађену ставку, онда се зависне ставке додају у ред за претходну обраду са вредношћу главне ставке која је претходно обрађена. Зависне ставке се стављају у ред за претходну обраду заобилазећи захтеве за претходну обраду нормалне вредности, али само за главне ставке са подешеном вредношћу и које нису у стању НИЈЕ ПОДРЖАНО.

Имајте на уму да је на дијаграму претходна обрада главне ставке мало поједностављена прескакањем кеширања претходне обраде.

Ред за претходну обраду

Ред за претходну обраду је организован као:

  • листа задатака на чекању:
    • задаци креирани директно из захтева за претходну обраду вредности по редоследу којим су примљени
  • листа непосредних задатака (обрађених пре задатака на чекању):
    • задаци за тестирање (креирани као одговор на ставку /претходна обрада захтева за тестирање од стране корисничког интерфејса)
    • задаци зависне ставке
    • задаци низа (задаци који се морају извршити у строгом редослед):
    • са корацима за претходну обраду користећи последњу вредност:
    • промена
    • пригушивање
    • JavaScript (кеширање бајткода)
    • кеширање зависне ставке за претходну обраду
    • листа завршених задатака

Кеширање предпроцесирања

Кеширање предпроцесирања је уведено да би се побољшале перформансе препроцесирања за више зависних ставки које имају сличне кораке препроцесирања (што је уобичајен LLD исход).

Кеширање се врши претходном обрадом једне зависне ставке и поновним коришћењем неких интерних података за претпроцесирање за остале зависне ставке. Кеш за претходну обраду је подржан само за први корак претходне обраде следећих типова:

  • Прометејев образац (индексира унос помоћу метрике)
  • JSONPath (рашчлањава податке у стабло објеката и индексира први израз [?(@.path == "value) ")])

Радници претходне обраде

Конфигурациони фајл Zabbix сервера омогућава корисницима да подесе број нити радника претходне обраде. Параметар конфигурације StartPreprocessors треба користити за подешавање броја претходно покренутих инстанци радника претходне обраде, који би требало да се подудара барем са бројем доступних језгара процесора.

Ако задаци претходне обраде нису ограничени на процесор и укључују честе мрежне захтеве, препоручује се конфигурисање додатних радника. Оптималан број радника претходне обраде може се одредити многим факторима, укључујући број "претходно обрадивих" ставки (ставки које захтевају извршавање било којих корака претходне обраде), број процеса прикупљања података, просечан број корака за претходну обраду ставки итд. Недовољан број радника може довести до велике употребе меморије. За решавање проблема прекомерне употребе меморије на вашој Zabbix инсталацији, погледајте Профилисање прекомерне употребе меморије помоћу tcmalloc.

Али под претпоставком да нема тешких операција претходне обраде попут парсирања великих XML/JSON делова, број радника претходне обраде може се подударати са укупним бројем сакупљача података. На овај начин, углавном ће (осим у случајевима када подаци из сакупљача долазе у великом броју) бити барем један незаузет радник претходне обраде за прикупљене податке.

Превише процеса прикупљања података (анкетирачи, недоступни анкери, ODBC анкери, HTTP анкери, Јава анкери, пингери, трапери, прокси анкери) заједно са IPMI менаџером, SNMP трапером и радницима претходне обраде могу исцрпети ограничење дескриптора датотеке по процесу за менаџер претходне обраде.

Исцрпљивање ограничења дескриптора датотеке по процесу ће довести до заустављања Zabbix сервера, обично убрзо након покретања, али понекад траје дуже. Да бисте избегли такве проблеме, прегледајте конфигурациону датотеку Zabbix сервера да бисте оптимизовали број истовремених провера и процеса. Поред тога, ако је потребно, проверите и прилагодите системска ограничења да ли је ограничење дескриптора датотеке довољно високо.

Value processing pipeline

Обрада вредности ставке се извршава у више корака (или фаза) од стране више процеса. Ово може проузроковати:

  • Зависна ставка може да прима вредности, док главна вредност не може. Ово се може постићи коришћењем следећег случаја употребе:
  • Главна ставка има тип вредности UINT (ставка за хватање се може користити), зависна ставка има тип вредности TEXT.
  • Нису потребни кораци претходне обраде ни за главну ни за зависне ставке.
  • Текстуална вредност (на пример, "abc") треба да се проследи главној ставци.
  • Пошто нема корака претходне обраде за извршавање, менаџер претходне обраде проверава да ли је главна ставка у стању НЕ ПОДРЖАНА и ако је вредност подешена (оба су тачна) и ставља зависну ставку у ред са истом вредношћу као главна ставка (јер нема корака претходне обраде ).
  • Када и главна и зависна ставка достигну фазу синхронизације историје, главна ставка постаје НЕ ПОДРЖАНА због грешке у конверзији вредности (текстуални подаци се не могу конвертовати у неозначени цео број).

Као резултат тога, зависна ставка добија вредност, док главна ставка мења своје стање у НИЈЕ ПОДРЖАНО.

  • Зависна ставка добија вредност која није присутна у историји главне ставке. Случај употребе је веома сличан претходном, осим типа главне ставке. На пример, ако се тип CHAR користи за главну ставку, онда ће вредност главне ставке бити скраћена у фази синхронизације историје, док ће зависне ставке добити своје вредности од почетне (не скраћене) вредности главне ставке.