ここでは、item 値のプリプロセッシングについて説明します。item 値のプリプロセッシングでは、
受け取ったitem 値に対してtransformation rulesを定義し、実行することができます。
プリプロセスは、Zabbix3.4で追加されたプリプロセスマネージャプロセスとプリプロセスワーカーによって管理され、
プリプロセスのステップを実行することができます。
プリプロセスのステップは、異なるデータ収集元からのすべての値(プリプロセスあり/なし)が、
ヒストリーキャッシュに追加される前に、プリプロセッシングマネージャを通過します。
データ収集装置(ポーラ、トラッパーなど)とプリプロセスの間で、ソケットベースのIPC通信が使用されます。
Zabbix server またはZabbix proxy(proxy が監視する item の場合)のどちらかがプリプロセスを実行します。
データソースからZabbixデータベースへのデータフローを可視化するために、以下の簡略化された図を使用します。
上の図は、item 値処理に関連するプロセス、オブジェクト、アクションのみを簡略化して示しています。
この図には条件分岐、エラー処理、ループなどは示していません。プリプロセスマネージャの
ローカルデータキャッシュも表示されていません。データフローに直接影響しないためです。
この図の目的は、item 値処理に関わるプロセスと、それらが相互作用する方法を示すことです。<
item はプリプロセッシングが行われている間にいずれかの処理が失敗した場合、状態が NOT SUPPORTED に変更されることがあります。
データの正規化に失敗した場合(例:テキスト値を数値に変換できない場合)、item はNOT SUPPORTEDに状態を変更されることがあります。
データのプリプロセッシングを可視化するために、以下のような簡略化した図を示します。
上の図は、item 値のプリプロセッシングに関連するプロセス、オブジェクト、および主なアクションのみを 簡略化 した形で示しています。
この図では条件分岐、エラー処理、ループは示していない。ただ1つのプリプロセスワーカーだけが示されています。
(実際は複数のプリプロセスワーカーを使用することも可能です)
この項目は少なくとも1つのプリプロセス工程を実行する必要があると想定している。
この図の目的は、item 値のプリプロセスパイプラインの考え方を示すことである。
item はプリプロセスキューの最後または先頭に配置されます。
Zabbix内部アイテムは常にプリプロセスキューの先頭に配置され、その他のアイテムタイプは最後にキューイングされます。
item 値処理は、複数のプロセスによって、複数のステップ(またはフェーズ)で実行されます。
これが要因となって、
UINT
(トラッパー項目も使用できる)、従属項目は値型 TEXT
を持つ。その結果、従属 item は値を受け取り、親 item の状態が NOT SUPPORTED に変わります。
CHAR
型が親 item に使用されている場合、親 item の値はプリプロセスキューは、 プリプロセスによって得られた値の順序を保持したまま、値を保存するFIFOデータ構造です。
FIFO ロジックにはいくつかの例外があります:
プリプロセスキューのロジックを視覚化するために、次の図を使用します。
プリプロセスキューからの値は、キューの先頭から最初の未処理キューにフラッシュされます。
したがって、例えば、プリプロセスマネージャは、値1、2、3 をフラッシュしますが、値4 はまだ処理されていないため、
値5 はフラッシュしません。
フラッシュ後、キューには2つの値(4と5)だけが残され、プリプロセッシングマネージャのローカルデータキャッシュに追加され、
その後、値がローカルキャッシュからヒストリーキャッシュに転送されます。
プリプロセッシングマネージャは、ローカルデータキャッシュから、単一 item モードまたはバルクモード
(依存する item や一括して受け取った値に使用)で値をフラッシュすることができます。
Preprocessing caching was introduced to improve the preprocessing performance for multiple dependent items having similar preprocessing steps (which is a common LLD outcome).
Caching is done by preprocessing one dependent item and reusing some of the internal preprocessing data for the rest of the dependent items. The preprocessing cache is supported only for the first preprocessing step of the following types:
[?(@.path == "value")]
)Zabbixサーバ設定ファイルでは、プリプロセスワーカープロセスの数を設定することができます。
StartPreprocessors 設定パラメータを使用して、フォークされたプリプロセスワーカーインスタンスの数を設定する必要があります。
最適なプリプロセスワーカーの数は、"プリプロセッシング可能な"アイテムの数など、多くの要因によって決まります。
データ収集プロセスの数、item の前処理にかかる平均ステップ数などです。
しかし、大きなXML/JSONチャンクのパースなどの重いプリプロセスがないと仮定すると、
プリプロセスワーカーの数はデータ収集プロセスの総数と一致させることができます。この方法では、ほとんどの場合
(ギャザラーからのデータが大量に来る場合を除く)、少なくとも1つの空いたプリプロセスワーカーが存在することになります。
データ収集プロセスが多すぎる (ポーラ、到達不能ポーラ、ODBC ポーラ、HTTP ポーラ、Java ポーラ、pingers、trappers,
プロキシポーラ) ケースで、IPMI マネージャ、SNMP トラッパ、プリプロセスワーカーを一緒に使用すると、
プリプロセスマネージャのプロセスごとのファイルディスクリプタを使い果たす可能性があります。
この場合、Zabbixサーバは停止します。(通常は起動後すぐに停止しますが、もっと時間がかかる場合もあります)
この状況を回避するために、設定ファイルを修正するか、制限値を上げる必要があります。