このセクションでは、アイテム値の前処理の詳細について説明します。アイテム値の前処理を使用すると、受信したアイテム値に対して変換ルールを定義および実行できます。
前処理は、前処理マネージャープロセスと、前処理ステップを実行する前処理ワーカーによって管理されます。 前処理付きのすべての値は、異なるデータ収集プロセスから受信され、ヒストリキャッシュに追加される前に前処理マネージャーを通過します。データ収集プロセス(ポーラー、トラッパーなど)と前処理プロセス間の通信には、ソケットベースのIPC通信が使用されます。 前処理ステップは、ZabbixサーバーまたはZabbixプロキシ(プロキシで監視されているアイテムの場合)が実行します。
データソースからZabbixデータベースまでのデータフローを可視化するために、以下の簡略化した図を使用できます。

上記の図は、簡略化された形でアイテム値の処理に関連するプロセス、オブジェクト、アクションのみを示しています。条件による方向変更、エラー処理、ループは示されていません。また、前処理マネージャのローカルデータキャッシュも、データフローに直接影響しないため表示されていません。この図の目的は、アイテム値の処理に関与するプロセスと、それらがどのように相互作用するかを示すことです。
前処理の実行中に、いずれかの前処理ステップが失敗した場合、アイテムはNOT SUPPORTED状態に変更されることがあります。
データの正規化に失敗した場合(例:テキスト値を数値に変換できない場合)、アイテムはNOT SUPPORTED状態に変更されることがあります。
データの事前処理は以下の手順で実行されます。

図では、事前処理のキャッシュを省略することで、マスターアイテムの事前処理がやや簡略化されていることに注意してください。
前処理キューは次のように構成されています:
前処理キャッシュは、同様の前処理ステップを持つ複数の依存アイテム(これは一般的なLLDの結果です)の前処理パフォーマンスを向上させるために導入されました。
キャッシュは、1つの依存アイテムを前処理し、内部の前処理データの一部を残りの依存アイテムで再利用することで行われます。前処理キャッシュは、以下のタイプの最初の前処理ステップのみサポートされています:
[?(@.path == "value")]をインデックス化)Zabbixサーバーの設定ファイルでは、前処理ワーカースレッドの数を設定できます。 StartPreprocessors 設定パラメータを使用して、前処理ワーカーの事前起動インスタンス数を設定します。この数は、少なくとも利用可能なCPUコア数と同じである必要があります。
前処理タスクがCPUに依存せず、頻繁にネットワークリクエストを伴う場合は、追加のワーカーを設定することを推奨します。 最適な前処理ワーカー数は、「前処理可能」なアイテム数(前処理ステップの実行が必要なアイテム)、データ収集プロセス数、アイテム前処理の平均ステップ数など、多くの要因によって決まります。 ワーカーが不足すると、メモリ使用量が高くなる可能性があります。Zabbixインストールでの過剰なメモリ使用量のトラブルシューティングについては、tcmallocによる過剰なメモリ使用量のプロファイリング を参照してください。
ただし、大きなXML/JSONチャンクの解析などの重い前処理操作がない場合、前処理ワーカーの数はデータ収集プロセスの合計数と一致させることができます。これにより、(データ収集プロセスからデータが一括で送信される場合を除き)収集されたデータに対して少なくとも1つの空いている前処理ワーカーが存在することになります。
データ収集プロセス(ポーラー、到達不能ポーラー、ODBCポーラー、HTTPポーラー、Javaポーラー、ピンガー、トラッパー、プロキシポーラー)とIPMIマネージャー、SNMPトラッパー、前処理ワーカーが多すぎると、前処理マネージャーのプロセスごとのファイルディスクリプタ制限を使い果たす可能性があります。
プロセスごとのファイルディスクリプタ制限を使い果たすと、Zabbixサーバーは停止します。通常は起動直後ですが、場合によってはそれよりも長くかかることもあります。 このような問題を回避するために、Zabbixサーバーの設定ファイル を見直し、同時チェック数やプロセス数を最適化してください。 さらに必要に応じて、システムの制限を確認・調整し、ファイルディスクリプタの制限が十分に高く設定されていることを確認してください。
アイテムの値の処理は、複数のプロセスによって複数のステップ(またはフェーズ)で実行されます。これにより、以下のようなことが発生する可能性があります。
UINT(トラッパーアイテムを使用可能)、従属アイテムの値の型は TEXT。その結果、従属アイテムは値を受け取りますが、マスターアイテムは「サポートされていない」状態に変わります。
CHAR 型を使用した場合、マスターアイテムの値は履歴同期フェーズで切り捨てられますが、従属アイテムはマスターアイテムの初期値(切り捨てられていない値)から値を受け取ります。