1年少し前、複数のサーバーから同じタイプの多数のインジケーターを取得して表示する問題を解決する必要がありましたが、サーバーの数とそれらから削除されるインジケーターの数は時間とともに変化する可能性があります。
zabbix_agent
がノードにインストールされ、ユーザーパラメータが設定され、テンプレートが作成され、データがZabbixに正常に取得されました。 2番目のシステム-Cactiについては、どこかで見つかったスクリプトを急いで再編集し、
zabbix_get
データを収集して
Data Queriesを使用しました。 しかし、このスクリプトの一部がすぐに壊れ、Zabbixが唯一の有効なソリューションとして残されました。
データクエリとは何か、どのように機能させるかを理解するために、年末年始だけの時間がありました。
私は、すべてを単独で動作させたいシステム管理者の土台の従来の表現を繰り返します。 私の場合、各制御ノードに対して必要なすべてのグラフをすぐに追加することができ、取得したインジケーターの数を変更するときに必要な情報が追加されました。 データを受信して処理するだけでなく、取得できるデータを把握するメカニズムが必要でした。 これは、
データクエリメソッドの仕組みとまったく同じです。これにより、
データ入力として値を収集し、さらにすべての可能なパラメーターのリストを返すことができます。
Cactiでは、このアプローチは、彼らが言うように、組み込みのまま組み込まれています。
汎用SNMPテンプレートを使用するノードの場合、すべてのネットワークインターフェースのリストを表示し、必要なものを選択し、関連する
データクエリSNMP-インターフェース統計を使用して必要なグラフを作成
できます 。 どのように機能するかを確認し、
こちらと
こちらのドキュメントを読み、自分でやり直してください。 しかし、私の意見では、説明に失敗した複雑なスクリプトの例が選択されているのは痛いです。 ユーザーコンポーネントは、インターフェイスで何をクリックして機能するかについては疑問を投げかけません。
したがって、
データクエリは、
SNMPデータの 取得、スクリプトサーバーデータの取得、スクリプト データの取得の 3種類で表され
ます。- Get SNMP Dataは、削除するパラメーターと、もちろんSNMPプロトコルを使用する場所を設定するXMLテンプレートによってのみ表されます。
- Get Script Server DataおよびGet Script Dataメソッドは、XMLテンプレートとその関連スクリプトによって定義されます。 Get Script Server Dataの場合のみ、PHPの使用を必要とする一般的なPHPプロセスを使用して実行速度が最適化されました。 Get Script Dataは最も一般的なアプローチであり、以下ではそれのみを検討します。
サボテンの側面からは、このように見えます。 表示する必要があるスクリプトパラメータと引数は、XMLテンプレートから読み取られます。
データクエリをノードにバインドした後、スクリプトが要求され、値を返すすべての可能な要素(インデックス)のリストが保存されます。 データが変更された場合、バインドされたメソッドの
Reload Data Queryインターフェイスから実行して、
データを再読み取りする必要があります。 次のポーリング中に、同じスクリプトは指定されたインデックスと引数に対して要求されたデータを返す必要があります。 毎回、保存されているすべてのインデックスと、表示されている各引数に対して、異なるスクリプト呼び出しが行われます。 その後、
データソースに保存し、チャートに描画します。
解決する必要があるタスクは、制御されたサーバーから
fping
ポーリングの結果を取得することです。この場合、
ya.ru
や
habrahabr.ru
などのリモートノードがパラメーターとして指定されます。 そして、答えは遅延と損失の値です。 したがって、各サーバーから他の多くのノードにpingを実行できます。 ノードのリストは自動的に取得されるはずです。
まず、XMLテンプレートを作成します
一般的なオプション
name
と
description
-混乱しないように、それは何で、何を意図しているのか:
<name>Get fping stats</name> <description>Remote monitoring fping statistics</description>
<script_path>
-スクリプトファイルへの
|path_cacti|
変数
|path_cacti|
:
<script_path>|path_cacti|/scripts/query-fping-stat.sh</script_path>
<arg_index>
、
<arg_num_indexes>
、
<arg_query>
、
<arg_get>
-スクリプトに渡されるパラメーターの値。これにより、操作モードと返される値が決まります。 4つのモードのみ、複雑なものを発明しないでください。
<arg_index>index</arg_index> <arg_num_indexes>num_indexes</arg_num_indexes> <arg_query>query</arg_query> <arg_get>get</arg_get>
<arg_prepend>
-スクリプトのコマンドラインで最初に渡されるパラメーター。 自動的に、他のパラメーターはスクリプトに転送されません。ただし、その操作モードを決定するパラメーターを除きます。つまり、どのサーバーに対してアクションを実行しているかはわかりません。 必要な追加引数はここで定義されます。
変数を使用することもでき
ます :
<arg_prepend>|host_hostname|</arg_prepend>
<output_delimeter>
は、戻り値の区切り文字です。 派手なものも何もない-コロンを使用する:
<output_delimeter>:</output_delimeter>
これで十分です。多くのオプションはありません。
それが残っています。
データフィールド
ここでは、出力で取得するデータを説明します。 値は、
入力と
出力の 2つのタイプに分けられます。
入力タイプは、
クエリモードの操作に関連付けられており、特定のインデックスを特徴付ける値を返す必要があります。 たとえば、ネットワークインターフェイスの場合:署名、物理アドレス、タイプ-時間が経過しても変化しないものすべて。 このようにして得られた
データは
データソースに送信され、
データソースはこれを希望のインデックスに関連付けます。
Data Sourceに関連付けられているのは少なくとも1つの
Input要素が必要です。
さらに、変数
|query__|
グラフのシグネチャで使用できます。これらの値は
、このホストのグラフの作成を個別の列として呼び出すときに、要素の一般リストに表示されます。
出力タイプ-グラフ上にデータが構築されるフィールド。
フィールド自体は非常に簡単に定義されます:
name
-name、
query_name
スクリプトと
direction
渡される値
query_name
または
Outputと 入力します。
ノードの名前を返す
入力フィールドが1つあります。 作成される変数
|query_host|
:
<host> <name>host</name> <direction>input</direction> <query_name>host</query_name> </host>
4つの
出力フィールド、最大、最小、平均応答遅延、パケット損失の割合:
<avg> <name>avg</name> <direction>output</direction> <query_name>avg</query_name> </avg> <max> <name>max</name> <direction>output</direction> <query_name>max</query_name> </max> <min> <name>min</name> <direction>output</direction> <query_name>min</query_name> </min> <loss> <name>loss</name> <direction>output</direction> <query_name>loss</query_name> </loss>
完全にXMLテンプレート <interface> <name>Get fping stats</name> <description>Remote monitoring fping statistics</description> <script_path>|path_cacti|/scripts/query-fping-stat.sh</script_path> <arg_index>index</arg_index> <arg_query>query</arg_query> <arg_get>get</arg_get> <arg_num_indexes>num_indexes</arg_num_indexes> <arg_prepend>|host_hostname|</arg_prepend> <output_delimeter>:</output_delimeter> <fields> <host> <name>host</name> <direction>input</direction> <query_name>host</query_name> </host> <avg> <name>avg</name> <direction>output</direction> <query_name>avg</query_name> </avg> <max> <name>max</name> <direction>output</direction> <query_name>max</query_name> </max> <min> <name>min</name> <direction>output</direction> <query_name>min</query_name> </min> <loss> <name>loss</name> <direction>output</direction> <query_name>loss</query_name> </loss> </fields> </interface>
スクリプト
テンプレートには、必要なものがすべて記載されています。 動作には4つのモードがあるため、4つの呼び出しモードがあります。
索引
<script_path> <arg_prepend> <arg_index>
可能なすべてのインデックス値の出力。それぞれに新しい行があります。 問題を解決するために、これは、制御されたサーバーで観察されるすべての可能なリモートノードのリストです。 すべてのサーバーが同じデータセットを生成するため、スクリプトで直接定義します。これは、何かを変更する必要がある唯一の場所です。 もちろん、データセットは異なる場合があり、必要に応じてサーバーから直接取得できます。 どのサーバーについてリストを返すかについては、テンプレートで
|host_hostname|
として指定されている最初のパラメーターから学習します
|host_hostname|
:
hosts="ya.ru habrahabr.ru" zabbix="/usr/local/bin/zabbix_get -s $1" case $2 in index) for host in $hosts; do echo $host; done ;; esac
Num_indexes
<script_path> <arg_prepend> <arg_num_indexes>
最初のモードからのインデックスの数:
numhosts=`echo $hosts | wc -w` case $2 in num_indexes) echo $numhosts ;; esac
問い合わせ
<script_path> <arg_prepend> <arg_query> <query_name>
Inputとして定義されたすべてのデータフィールドに対して実行されます。 出力は、各インデックスと指定されたデータフィールドごとに
index output_delimeter <>
を取得する必要があり、それぞれ新しい行があります。 テンプレートには値が1つしか定義されておらず、インデックスは読みやすいため、結果として使用します。
case $2 in query) for host in $hosts do case $3 in host) echo $host:$host ;; esac done ;; esac
リストされたモードはすべて、ノード要素のリストを作成するときに実行されます。 次のモードは、各インデックスおよび各引数のデータの次のポーリング中に毎回呼び出されます。
ゲット
<script_path> <arg_prepend> <arg_get> <query_name>
Outputとして定義されているすべてのデータフィールドに対して呼び出されます。 出力は、指定されたフィールドとインデックスの<>
を取得する必要があります。 フォーマットされた文字列で値を出力する必要があるデータ入力よりも簡単なものは、ここではすべてがテンプレートで定義されています:
zabbix="/usr/local/bin/zabbix_get -s $1" get_ping () { res=`$zabbix -k ping[$1,$2]` if [ -z $res ] then res=-1 fi echo $res } case $2 in get) echo $(get_ping $4 $3) ;; esac
データクエリを作成し、ノードにバインドして、 詳細クエリのデバッグ実行を実行します。
エラーのないテンプレート:
+ Found data query XML file at '/usr/local/cacti/resource/script_queries/fping-stat.xml' + XML file parsed ok.
Num_indexesモード、要素数:
+ Executing script for num of indexes '/usr/local/cacti/scripts/query-fping-stat.sh server num_indexes' + Found number of indexes: 2
インデックスモード、すべての要素のリスト:
+ Executing script for list of indexes '/usr/local/cacti/scripts/query-fping-stat.sh server index' Index Count: 2 + Found index: ya.ru + Found index: habrahabr.ru
クエリモード、すべての要素のすべての引数の出力値:
+ Executing script query '/usr/local/cacti/scripts/query-fping-stat.sh server query host' + Found item [host='ya.ru'] index: ya.ru + Found item [host='habrahabr.ru'] index: habrahabr.ru
すべてが機能する場合は、Cactiの場合と同じように、データ テンプレートであるチャートテンプレートを作成します。 私たちは一緒にバインドします 。これは作成されたデータクエリで直接行わなければなりません。 その後、 このホストのグラフ作成を使用すると、使用可能なオプションのリストが自動的に取得されます。
次に、グラフを作成します。その後、各入力引数、各インデックス、各ノードに対してスクリプトの呼び出しがポーラーに追加されます。 ポーラーキャッシュを表示すると、スクリプトが呼び出されているパラメーター、およびそのパラメーターが表示されます。
Script: /usr/local/cacti/scripts/query-fping-stat.sh server get avg ya.ru
これは、新しいスケジュールをほぼ自動的に追加できることを意味し、システム管理者はより重要なことを引き続き実行できます。
PS壊れたものを修正できましたか?グラフを見てテキストが完全に準備できたとき、昨年のかなりやり直したバージョンでも問題が解決しないことに気付きました。 標準のデータクエリスクリプトを使用する他の多くのグラフでは、説明したソリューションを繰り返し実装した後、1日に数回、データの削除と表示は行われません。 おそらく、使用されているインフラストラクチャの機能、または構成エラー。 いずれにせよ、これはData Queriesの利便性を否定するものではありませんが、理由は...:「We will search」(c)