You are viewing documentation for the development version, it may be incomplete.
Join our translation project and help translate Zabbix documentation into your native language.

2 保存前処理の詳細

概要

このセクションでは、アイテム値の前処理の詳細について説明します。アイテム値の前処理を使用すると、受信したアイテム値に対して変換ルールを定義および実行できます。

前処理は、前処理マネージャープロセスと、前処理ステップを実行する前処理ワーカーによって管理されます。 前処理付きのすべての値は、異なるデータ収集プロセスから受信され、ヒストリキャッシュに追加される前に前処理マネージャーを通過します。データ収集プロセス(ポーラー、トラッパーなど)と前処理プロセス間の通信には、ソケットベースのIPC通信が使用されます。 前処理ステップは、ZabbixサーバーまたはZabbixプロキシ(プロキシで監視されているアイテムの場合)が実行します。

アイテム値の処理

データソースからZabbixデータベースまでのデータフローを可視化するために、以下の簡略化した図を使用できます。

上記の図は、簡略化された形でアイテム値の処理に関連するプロセス、オブジェクト、アクションのみを示しています。条件による方向変更、エラー処理、ループは示されていません。また、前処理マネージャのローカルデータキャッシュも、データフローに直接影響しないため表示されていません。この図の目的は、アイテム値の処理に関与するプロセスと、それらがどのように相互作用するかを示すことです。

  • データ収集は、データソースからの生データで開始されます。この時点では、データにはID、タイムスタンプ、値(複数値の場合もあり)しか含まれていません。
  • どのタイプのデータ収集プロセスが使用される場合でも、アクティブチェックやパッシブチェック、トラッパーアイテムなど、考え方は同じです。違いはデータフォーマットと通信の開始者(データ収集プロセスが接続とデータを待つか、データ収集プロセスが通信を開始してデータを要求するか)だけです。生データは検証され、アイテム設定が設定キャッシュから取得されます(データは設定データで拡張されます)。
  • ソケットベースのIPCメカニズムを使用して、データ収集プロセスから前処理マネージャにデータを渡します。この時点で、データ収集プロセスは前処理マネージャからの応答を待たずにデータ収集を続行します。
  • データの前処理が実行されます。これには、前処理ステップの実行や従属アイテムの処理が含まれます。

前処理の実行中に、いずれかの前処理ステップが失敗した場合、アイテムはNOT SUPPORTED状態に変更されることがあります。

  • 前処理マネージャのローカルデータキャッシュからヒストリキャッシュにヒストリデータがフラッシュされます。
  • この時点で、次回のヒストリキャッシュの同期(history syncerプロセスがデータ同期を実行するタイミング)までデータフローは停止します。
  • 同期プロセスは、Zabbixデータベースにデータを保存する前にデータの正規化から始まります。データの正規化では、アイテム設定で定義されたタイプへの変換や、タイプごとに許可されている事前定義サイズに基づくテキストデータの切り捨て(文字列の場合はHISTORY_STR_VALUE_LEN、テキストの場合はHISTORY_TEXT_VALUE_LEN、ログ値の場合はHISTORY_LOG_VALUE_LEN)が行われます。正規化が完了した後、データはZabbixデータベースに送信されます。

データの正規化に失敗した場合(例:テキスト値を数値に変換できない場合)、アイテムはNOT SUPPORTED状態に変更されることがあります。

  • 収集されたデータが処理されます。トリガーのチェックや、アイテムがNOT SUPPORTEDになった場合のアイテム設定の更新などが行われます。
  • これは、アイテム値の処理の観点から見たデータフローの終了と見なされます。

アイテム値の事前処理

データの事前処理は以下の手順で実行されます。

  • アイテムに事前処理も従属アイテムもない場合、その値はヒストリキャッシュに追加されるか、LLDマネージャに送信されます。そうでない場合、アイテム値はUNIXソケットベースのIPCメカニズムを使用して事前処理マネージャに渡されます。
  • 事前処理タスクが作成され、キューに追加され、事前処理ワーカーに新しいタスクが通知されます。
  • この時点で、少なくとも1つの空いている(すなわち、タスクを実行していない)事前処理ワーカーが現れるまでデータフローは停止します。
  • 事前処理ワーカーが利用可能になると、キューから次のタスクを取得します。
  • 事前処理が完了すると(事前処理ステップの失敗・成功の両方の場合)、事前処理済みの値が完了タスクキューに追加され、マネージャに新しい完了タスクが通知されます。
  • 事前処理マネージャは、結果を希望するフォーマット(アイテム値タイプで定義)に変換し、ヒストリキャッシュに追加するか、LLDマネージャに送信します。
  • 処理されたアイテムに従属アイテムがある場合、従属アイテムは事前処理済みのマスターアイテム値で事前処理キューに追加されます。従属アイテムは通常の値の事前処理リクエストをバイパスしてキューに追加されますが、値が設定されていてNOT SUPPORTED状態でないマスターアイテムに対してのみ行われます。

図では、事前処理のキャッシュを省略することで、マスターアイテムの事前処理がやや簡略化されていることに注意してください。

前処理キュー

前処理キューは次のように構成されています:

  • 保留中タスクのリスト:
    • 受信順に値の前処理リクエストから直接作成されたタスク
  • 即時タスクのリスト (保留中タスクより先に処理される):
    • テストタスク (フロントエンドからのアイテム/前処理テストリクエストに応じて作成)
    • 従属アイテムのタスク
    • シーケンスタスク (厳密な順序で実行する必要があるタスク):
      • 最終値を使用する前処理ステップを持つもの:
        • 差分
        • スロットリング
        • JavaScript (バイトコードキャッシュ)
      • 従属アイテムの前処理キャッシュ
  • 完了したタスクのリスト

前処理キャッシュ

前処理キャッシュは、同様の前処理ステップを持つ複数の依存アイテム(これは一般的なLLDの結果です)の前処理パフォーマンスを向上させるために導入されました。

キャッシュは、1つの依存アイテムを前処理し、内部の前処理データの一部を残りの依存アイテムで再利用することで行われます。前処理キャッシュは、以下のタイプの最初の前処理ステップのみサポートされています:

  • Prometheusパターン(メトリクスで入力をインデックス化)
  • JSONPath(データをオブジェクトツリーに解析し、最初の式[?(@.path == "value")]をインデックス化)

前処理ワーカー

Zabbixサーバーの設定ファイルでは、前処理ワーカースレッドの数を設定できます。 StartPreprocessors 設定パラメータを使用して、前処理ワーカーの事前起動インスタンス数を設定します。この数は、少なくとも利用可能なCPUコア数と同じである必要があります。

前処理タスクがCPUに依存せず、頻繁にネットワークリクエストを伴う場合は、追加のワーカーを設定することを推奨します。 最適な前処理ワーカー数は、「前処理可能」なアイテム数(前処理ステップの実行が必要なアイテム)、データ収集プロセス数、アイテム前処理の平均ステップ数など、多くの要因によって決まります。 ワーカーが不足すると、メモリ使用量が高くなる可能性があります。Zabbixインストールでの過剰なメモリ使用量のトラブルシューティングについては、tcmallocによる過剰なメモリ使用量のプロファイリング を参照してください。

ただし、大きなXML/JSONチャンクの解析などの重い前処理操作がない場合、前処理ワーカーの数はデータ収集プロセスの合計数と一致させることができます。これにより、(データ収集プロセスからデータが一括で送信される場合を除き)収集されたデータに対して少なくとも1つの空いている前処理ワーカーが存在することになります。

データ収集プロセス(ポーラー、到達不能ポーラー、ODBCポーラー、HTTPポーラー、Javaポーラー、ピンガー、トラッパー、プロキシポーラー)とIPMIマネージャー、SNMPトラッパー、前処理ワーカーが多すぎると、前処理マネージャーのプロセスごとのファイルディスクリプタ制限を使い果たす可能性があります。

プロセスごとのファイルディスクリプタ制限を使い果たすと、Zabbixサーバーは停止します。通常は起動直後ですが、場合によってはそれよりも長くかかることもあります。 このような問題を回避するために、Zabbixサーバーの設定ファイル を見直し、同時チェック数やプロセス数を最適化してください。 さらに必要に応じて、システムの制限を確認・調整し、ファイルディスクリプタの制限が十分に高く設定されていることを確認してください。

値処理パイプライン

アイテムの値の処理は、複数のプロセスによって複数のステップ(またはフェーズ)で実行されます。これにより、以下のようなことが発生する可能性があります。

  • 従属アイテムは値を受け取ることができますが、マスター値は受け取れません。 これは、次のユースケースを使用することで実現できます。
    • マスターアイテムの値の型は UINT(トラッパーアイテムを使用可能)、従属アイテムの値の型は TEXT
    • マスターアイテムと従属アイテムの両方に前処理ステップは不要です。
    • テキスト値(例: "abc")をマスターアイテムに渡す必要があります。
    • 実行する前処理ステップがないため、前処理マネージャはマスターアイテムが「サポートされていない」状態でないことと値が設定されていることを確認し(両方とも真)、従属アイテムをマスターアイテムと同じ値でキューに入れます(前処理ステップがないため)。
    • マスターアイテムと従属アイテムの両方が履歴同期フェーズに到達すると、マスターアイテムは値変換エラー(テキストデータを符号なし整数に変換できないため)により「サポートされていない」状態になります。

その結果、従属アイテムは値を受け取りますが、マスターアイテムは「サポートされていない」状態に変わります。

  • 従属アイテムが、マスターアイテムの履歴に存在しない値を受け取る場合があります。ユースケースは前述のものと非常に似ていますが、マスターアイテムの型が異なります。たとえば、マスターアイテムに CHAR 型を使用した場合、マスターアイテムの値は履歴同期フェーズで切り捨てられますが、従属アイテムはマスターアイテムの初期値(切り捨てられていない値)から値を受け取ります。