[comment]: # ({30385a91-30385a91}) # 2 保存前処理の詳細 [comment]: # ({/30385a91-30385a91}) [comment]: # ({e8562aba-67b39eda}) #### 概要 このセクションでは、アイテム値の前処理の詳細について説明します。アイテム値の前処理を使用すると、受信したアイテム値に対して[変換ルール](/manual/config/items/preprocessing)を定義および実行できます。 前処理は、前処理マネージャープロセスと、前処理ステップを実行する前処理ワーカーによって管理されます。 前処理付きのすべての値は、異なるデータ収集プロセスから受信され、ヒストリキャッシュに追加される前に前処理マネージャーを通過します。データ収集プロセス（ポーラー、トラッパーなど）と前処理プロセス間の通信には、ソケットベースのIPC通信が使用されます。 前処理ステップは、ZabbixサーバーまたはZabbixプロキシ（プロキシで監視されているアイテムの場合）が実行します。 [comment]: # ({/e8562aba-67b39eda}) [comment]: # ({df5ddb53-7aff5db5}) #### アイテム値の処理 データソースからZabbixデータベースへのデータフローを視覚化するために、以下の簡略化した図を使用できます。 ![](../../../../../assets/en/manual/appendix/items/overall_pic.png) 上記の図は、**簡略化**された形でアイテム値の処理に関連するプロセス、オブジェクト、およびアクションのみを示しています。この図には、条件による方向変更、エラー処理、ループは表示されていません。また、前処理マネージャのローカルデータキャッシュも、データフローに直接影響しないため表示されていません。この図の目的は、アイテム値の処理に関与するプロセスと、それらがどのように相互作用するかを示すことです。 - データ収集は、データソースからの生データから始まります。この時点では、データにはID、タイムスタンプ、値（複数の値も可）のみが含まれています。 - どのタイプのデータ収集プロセスが使用されていても、アクティブチェックやパッシブチェック、トラッパーアイテムなど、考え方は同じです。違いはデータフォーマットと通信の開始者（データ収集プロセスが接続とデータを待つか、通信を開始してデータを要求するか）だけです。生データは検証され、アイテムの設定が設定キャッシュから取得されます（データは設定データで拡張されます）。 - データ収集プロセスから前処理マネージャへデータを渡すために、ソケットベースのIPCメカニズムが使用されます。この時点で、データ収集プロセスは前処理マネージャからの応答を待たずにデータ収集を続行します。 - データの前処理が実行されます。これには、前処理ステップの実行や従属アイテムの処理が含まれます。 ::: noteclassic 前処理の実行中に、いずれかの前処理ステップが失敗した場合、アイテムはNOT SUPPORTED状態に変更されることがあります。 ::: - 前処理マネージャのローカルデータキャッシュからヒストリキャッシュへヒストリデータがフラッシュされます。 - この時点で、次のヒストリキャッシュの同期（ヒストリシンカープロセスがデータ同期を実行するタイミング）までデータフローは停止します。 - 同期プロセスは、Zabbixデータベースにデータを保存する前にデータの正規化から始まります。データの正規化では、アイテム設定で定義されたタイプへの変換や、[定義済みサイズ](/manual/config/items/item#item-data-limits)（文字列の場合はHISTORY_STR_VALUE_LEN、テキストの場合はHISTORY_TEXT_VALUE_LEN、ログ値の場合はHISTORY_LOG_VALUE_LEN）に基づくテキストデータの切り捨てなどが行われます。正規化が完了した後、データはZabbixデータベースに送信されます。 ::: noteclassic データの正規化に失敗した場合（たとえば、テキスト値を数値に変換できない場合など）、アイテムはNOT SUPPORTED状態に変更されることがあります。 ::: - 収集されたデータが処理されます。トリガーのチェック、アイテムがNOT SUPPORTEDになった場合のアイテム設定の更新などが行われます。 - これは、アイテム値の処理の観点から見たデータフローの終了と見なされます。 [comment]: # ({/df5ddb53-7aff5db5}) [comment]: # ({fdc9563a-44da8577}) #### アイテム値の事前処理 データの事前処理は以下の手順で実行されます。 - アイテムに事前処理も従属アイテムもない場合、その値はヒストリキャッシュに追加されるか、LLDマネージャに送信されます。そうでない場合、アイテム値はUNIXソケットベースのIPCメカニズムを使用して事前処理マネージャに渡されます。 - 事前処理タスクが作成され、キューに追加され、事前処理ワーカーに新しいタスクが通知されます。 - この時点で、少なくとも1つの空いている（すなわち、タスクを実行していない）事前処理ワーカーが現れるまでデータフローは停止します。 - 事前処理ワーカーが利用可能になると、キューから次のタスクを取得します。 - 事前処理が完了すると（事前処理ステップの失敗・成功の両方の場合）、事前処理済みの値が完了タスクキューに追加され、マネージャに新しい完了タスクが通知されます。 - 事前処理マネージャは、結果を希望するフォーマット（アイテム値タイプで定義）に変換し、ヒストリキャッシュに追加するか、LLDマネージャに送信します。 - 処理されたアイテムに従属アイテムがある場合、従属アイテムは事前処理済みのマスターアイテム値で事前処理キューに追加されます。従属アイテムは通常の値の事前処理リクエストをバイパスしてキューに追加されますが、値が設定されていてNOT SUPPORTED状態でないマスターアイテムに対してのみ行われます。 ![](../../../assets/en/diagrams/value_preprocessing.png){width="600"} 図では、事前処理のキャッシュを省略することで、マスターアイテムの事前処理がやや簡略化されていることに注意してください。 [comment]: # ({/fdc9563a-44da8577}) [comment]: # ({73f49808-4b6fc468}) #### 前処理キュー 前処理キューは次のように構成されています: * 保留中タスクのリスト: * 受信順に値の前処理リクエストから直接作成されたタスク * 即時タスクのリスト (保留中タスクより先に処理される): * テストタスク (フロントエンドからのアイテム/前処理テストリクエストに応じて作成) * 従属アイテムのタスク * シーケンスタスク (厳密な順序で実行する必要があるタスク): * 最終値を使用する前処理ステップを持つもの: * 差分 * スロットリング * JavaScript (バイトコードキャッシュ) * 従属アイテムの前処理キャッシュ * 完了したタスクのリスト [comment]: # ({/73f49808-4b6fc468}) [comment]: # ({abb85873-c9d6405f}) #### 前処理キャッシュ 前処理キャッシュは、同様の前処理ステップを持つ複数の依存アイテム(これは一般的なLLDの結果です)の前処理パフォーマンスを向上させるために導入されました。 キャッシュは、1つの依存アイテムを前処理し、内部の前処理データの一部を残りの依存アイテムで再利用することで行われます。前処理キャッシュは、以下のタイプの最初の前処理ステップのみサポートされています: * Prometheusパターン(メトリクスで入力をインデックス化) * JSONPath(データをオブジェクトツリーに解析し、最初の式`[?(@.path == "value")]`をインデックス化) [comment]: # ({/abb85873-c9d6405f}) [comment]: # ({e82b6a24-98589fcd}) #### プリプロセッシングワーカー Zabbix サーバーの設定ファイルでは、プリプロセッシングワーカースレッドの数を設定できます。 [StartPreprocessors](/manual/concepts/server/server_params#startpreprocessors) 設定パラメータを使用して、事前起動するプリプロセッシングワーカーのインスタンス数を設定してください。この数は、少なくとも利用可能な CPU コア数と同じである必要があります。 プリプロセッシングタスクが CPU に依存せず、頻繁なネットワークリクエストを伴う場合は、追加のワーカーを設定することを推奨します。 最適なプリプロセッシングワーカー数は、"preprocessable" なアイテム数（何らかのプリプロセッシング手順の実行が必要なアイテム）、データ収集プロセス数、アイテムのプリプロセッシングにおける平均ステップ数など、さまざまな要因によって決まります。 ワーカー数が不足すると、メモリ使用量が増加する可能性があります。Zabbix 環境でメモリ使用量が過剰になっている場合のトラブルシューティングについては、[tcmalloc を使用した過剰なメモリ使用量のプロファイリング](/manual/installation/known_issues#profiling-excessive-memory-usage-with-tcmalloc) を参照してください。 ただし、大きな XML/JSON チャンクの解析のような負荷の高いプリプロセッシング処理がない場合は、プリプロセッシングワーカーの数をデータ収集プロセスの合計数に合わせることができます。こうすることで、ほとんどの場合（データ収集側からのデータが一括で到着する場合を除く）、収集済みデータを処理するための未使用のプリプロセッシングワーカーが少なくとも 1 つ存在する状態になります。 ::: notewarning poller、unreachable poller、ODBC poller、HTTP poller、Java poller、pinger、trapper、proxypoller といったデータ収集プロセスが多すぎると、IPMI manager、SNMP trapper、およびプリプロセッシングワーカーと合わせて、プリプロセッシングマネージャーのプロセスごとのファイルディスクリプタ上限を使い切る可能性があります。

プロセスごとのファイルディスクリプタ上限を使い切ると、Zabbix サーバーは停止します。通常は起動直後に発生しますが、場合によってはより時間がかかることもあります。 このような問題を回避するには、[Zabbix サーバーの設定ファイル](/manual/concepts/server/server_params) を確認し、同時チェック数とプロセス数を最適化してください。 さらに、必要に応じてシステムの制限を確認・調整し、ファイルディスクリプタ上限が十分に高く設定されていることを確認してください。 ::: [comment]: # ({/e82b6a24-98589fcd}) [comment]: # ({a459312a-ad691011}) ##### 値処理パイプライン アイテムの値の処理は、複数のプロセスによって複数のステップ（またはフェーズ）で実行されます。これにより、以下のようなことが発生する可能性があります。 - 従属アイテムは値を受け取ることができますが、マスター値は受け取れません。 これは、次のユースケースを使用することで実現できます。 - マスターアイテムの値の型は `UINT`（トラッパーアイテムを使用可能）、従属アイテムの値の型は `TEXT`。 - マスターアイテムと従属アイテムの両方に前処理ステップは不要です。 - テキスト値（例: "abc"）をマスターアイテムに渡す必要があります。 - 実行する前処理ステップがないため、前処理マネージャはマスターアイテムが「サポートされていない」状態でないことと値が設定されていることを確認し（両方とも真）、従属アイテムをマスターアイテムと同じ値でキューに入れます（前処理ステップがないため）。 - マスターアイテムと従属アイテムの両方が履歴同期フェーズに到達すると、マスターアイテムは値変換エラー（テキストデータを符号なし整数に変換できないため）により「サポートされていない」状態になります。 その結果、従属アイテムは値を受け取りますが、マスターアイテムは「サポートされていない」状態に変わります。 - 従属アイテムが、マスターアイテムの履歴に存在しない値を受け取る場合があります。ユースケースは前述のものと非常に似ていますが、マスターアイテムの型が異なります。たとえば、マスターアイテムに `CHAR` 型を使用した場合、マスターアイテムの値は履歴同期フェーズで切り捨てられますが、従属アイテムはマスターアイテムの初期値（切り捨てられていない値）から値を受け取ります。 [comment]: # ({/a459312a-ad691011})