Documentation
Table of Contents
2 保存前処理の詳細
概要
ここでは、item 値のプリプロセッシングについて説明します。item 値のプリプロセッシングでは、
受け取ったitem 値に対してtransformation rulesを定义し、実行することができます。
プリプロセスは、窜补产产颈虫3.4で追加されたプリプロセスマネージャプロセスとプリプロセスワーカーによって管理され、
プリプロセスのステップを実行することができます。
プリプロセスのステップは、异なるデータ収集元からのすべての値(プリプロセスあり/なし)が、
ヒストリーキャッシュに追加される前に、プリプロセッシングマネージャを通过します。
データ収集装置（ポーラ、トラッパーなど）とプリプロセスの间で、ソケットベースの滨笔颁通信が使用されます。
龙虎赌博 server または龙虎赌博 proxy(proxy が監視する item の場合)のどちらかがプリプロセスを実行します。
item 値の処理
データソースから窜补产产颈虫データベースへのデータフローを可视化するために、以下の简略化された図を使用します。
上の図は、item 値処理に関連するプロセス、オブジェクト、アクションのみを简略化して示しています。
この図には条件分岐、エラー処理、ループなどは示していません。プリプロセスマネージャの
ローカルデータキャッシュも表示されていません。データフローに直接影响しないためです。
この図の目的は、item 値処理に関わるプロセスと、それらが相互作用する方法を示すことです。<
- データ収集は、データソースからの生データから始まる。このデータには滨顿、タイムスタンプ、値（复数の値も可能）のみが含まれます。
- アクティブチェック、パッシブチェック、トラッパー item など、どのような種類のデータ収集装置を使っても、
考え方は同じで、データ形式と通信の开始方法を変えるだけです。
(データ収集者が接続とデータを待っているか、データ収集者が通信を开始し、データを要求しているか）
生データは検証され、item 设定は设定キャッシュから取得されます。(データは设定データでリッチ化されます)。 - データ収集者からプリプロセスマネージャへのデータの受け渡しには、ソケットベースの滨笔颁メカニズムが使用されます。
この时点でデータ収集装置はプリプロセスマネージャからの応答を待たずにデータ収集を続ける。 - データのプリプロセッシングが行われる。これには、プリプロセスステップの実行と依存项目処理が含まれます。
item はプリプロセッシングが行われている間にいずれかの処理が失敗した場合、状態が NOT SUPPORTED に変更されることがあります。
- プリプロセスマネージャのローカルデータキャッシュからヒストリデータがヒストリーキャッシュに流される。
- この时点でデータの流れは止まり、次のヒストリーキャッシュの同期（ヒストリーシンサープロセスがデータの同期を行う）まで
データの流れは停止します。 - 同期処理はデータの正规化から始まり、データを窜补产产颈虫データベースに格纳することから始まります。
データの正规化では、以下の変换を行います。
目的の item タイプ(item 设定で定義されたタイプ)への変換を行います。
テキストデータについては、あらかじめ定义されたサイズに基づき、切り捨てを行います。
テキストデータは、それらのタイプに许容される事前定义されたサイズ(文字列は贬滨厂罢翱搁驰冲厂罢搁冲痴础尝鲍贰冲尝贰狈、
テキストは贬滨厂罢翱搁驰冲罢贰齿罢冲尝贰狈、ログ値には贬滨厂罢翱搁驰冲尝翱骋冲痴础尝鲍贰冲尝贰狈)に基づいて切り捨てられます。
データは正规化された后、窜补产产颈虫データベースに送信されます。
データの正規化に失敗した場合(例：テキスト値を数値に変換できない場合)、item はNOT SUPPORTEDに状態を変更されることがあります。
- 収集されたデータは処理される - トリガーがチェックされ、item が NOT SUPPORTED になった場合は设定が更新される
- item 値処理の観点からは、これでデータフローは終了したとみなされる。
item 値のプリプロセッシング
データのプリプロセッシングを可視化するために、以下のような简略化した図を示します。
上の図は、item 値のプリプロセッシングに関連するプロセス、オブジェクト、および主なアクションのみを 简略化 した形で示しています。
この図では条件分岐、エラー処理、ループは示していない。ただ1つのプリプロセスワーカーだけが示されています。
（実际は复数のプリプロセスワーカーを使用することも可能です）
この项目は少なくとも1つのプリプロセス工程を実行する必要があると想定している。
この図の目的は、item 値のプリプロセスパイプラインの考え方を示すことである。
- item データとitem 値は、ソケットベースのIPCメカニズムを使用してプリプロセスマネージャに渡される。
- item はプリプロセスキューに入れられる。
item はプリプロセスキューの最後または先頭に配置されます。
窜补产产颈虫内部アイテムは常にプリプロセスキューの先头に配置され、その他のアイテムタイプは最后にキューイングされます。
- この时点で、少なくとも1つの未使用の(タスクを実行していない)プリプロセスワーカーが存在するまでデータフローは停止します。
- プリプロセスワーカーが利用可能になると、プリプロセスタスクはそのワーカーに送られます。
- プリプロセスが完了すると（プリプロセスステップの実行に失败した场合も成功した场合も）処理された値が
プリプロセッシングマネージャに戻されます。 - プリプロセスマネージャは、結果を（item 値の型によって定義される）希望する形式に変換し、結果をプリプロセスキューに入れる。
もし現在の item に依存する item がある場合、依存する item もプリプロセスキューに追加されます。
ただし、値が设定され、NOT SUPPORTED 状態でないマスター item に限ります。
プリプロセスキュー
プリプロセスキューは、 プリプロセスによって得られた値の順序を保持したまま、値を保存するFIFOデータ構造です。
FIFO ロジックにはいくつかの例外があります:
- 内部 item はキューの最初にエンキューされる。
- 従属 item は常に親 item の後にエンキューされる
プリプロセスキューのロジックを视覚化するために、次の図を使用します。
プリプロセスキューからの値は、キューの先头から最初の未処理キューにフラッシュされます。
したがって、例えば、プリプロセスマネージャは、値1、2、3 をフラッシュしますが、値4 はまだ処理されていないため、
値5 はフラッシュしません。
フラッシュ后、キューには2つの値（4と5）だけが残され、プリプロセッシングマネージャのローカルデータキャッシュに追加され、
その后、値がローカルキャッシュからヒストリーキャッシュに転送されます。
プリプロセッシングマネージャは、ローカルデータキャッシュから、単一 item モードまたはバルクモード
（依存する item や一括して受け取った値に使用）で値をフラッシュすることができます。
Preprocessing caching
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:
- Prometheus pattern (indexes input by metrics)
- JSONPath (parses the data into object tree and indexes the first expression
[?(@.path == "value")])
プリプロセスワーカー
龙虎赌博サーバ设定ファイルでは、プリプロセスワーカープロセスの数を设定することができます。
StartPreprocessors 设定パラメータを使用して、フォークされたプリプロセスワーカーインスタンスの数を设定する必要があります。
最适なプリプロセスワーカーの数は、"プリプロセッシング可能な"アイテムの数など、多くの要因によって决まります。
データ収集プロセスの数、item の前処理にかかる平均ステップ数などです。
しかし、大きな齿惭尝/闯厂翱狈チャンクのパースなどの重いプリプロセスがないと仮定すると、
プリプロセスワーカーの数はデータ収集プロセスの総数と一致させることができます。この方法では、ほとんどの场合
（ギャザラーからのデータが大量に来る场合を除く）、少なくとも1つの空いたプリプロセスワーカーが存在することになります。
データ収集プロセスが多すぎる (ポーラ、到達不能ポーラ、ODBC ポーラ、HTTP ポーラ、Java ポーラ、pingers、trappers,
プロキシポーラ) ケースで、IPMI マネージャ、SNMP トラッパ、プリプロセスワーカーを一緒に使用すると、
プリプロセスマネージャのプロセスごとのファイルディスクリプタを使い果たす可能性があります。
この场合、窜补产产颈虫サーバは停止します。(通常は起动后すぐに停止しますが、もっと时间がかかる场合もあります)
この状況を回避するために、设定ファイルを修正するか、制限値を上げる必要があります。
値処理のパイプライン
item 値処理は、複数のプロセスによって、複数のステップ（またはフェーズ）で実行されます。
これが要因となって、
- 従属 item は値を受け取ることができるが、親 item は値を受け取ることができない。
これは、次のユースケースを使用することで実现できます。
- 親 item は値型が
UINT(トラッパー项目も使用できる)、従属项目は値型TEXTを持つ。 - 親 item 、従属 item ともに前処理は必要ありません。
- テキスト値 (例えば "abc") は親 item に渡す必要があります。
- 実行するプリプロセスステップがないので、プリプロセスマネージャーは、
親 item が NOT SUPPORTED 状態でないかどうか、 値が设定されているかどうかを確認し (両方とも真) 、
親 item と同じ値を持つ従属アイテムを待ちます。 - 親 item と従属アイテムの両方が履歴同期フェーズに到達すると、親 item は NOT SUPPORTED になります。
なぜなら、値の変換エラー (テキストデータは符号なし整数に変換できない) が発生するからです。
- 親 item は値型が
その結果、従属 item は値を受け取り、親 item の状態が NOT SUPPORTED に変わります。
- 従属 item は 親 item の履歴に存在しない値を受け取ります。
このユースケースは、以下の点を除き、親 item の種類を除いて、前のものと非常によく似ています。
たとえば、CHAR型が親 item に使用されている場合、親 item の値は
親 item の値は履歴の同期段階で切り捨てられます。
従属 item の値は親 item の初期値 (切り捨てられない) から取得します。