🧖🏿 👩‍❤️‍💋‍👩 ✍🏿 Zabbix 3.4：Mercuryおよびsmartmontoolsカウンターの例を使用した大量データ収集 🍞 🗜️ 🖨️

みなさん、こんにちは、先ほどオープンソース監視システムZabbix 3.4の新しいバージョンでの大量データ収集の可能性について既に言及しました。次に、この機能について詳しく説明します。さらに明確にするために、次の2つの例で説明します。

電気メーターMercury 236のコンソールユーティリティからJSONで一度に受信したすべてのデータの収集
smartmontoolsから表形式で取得したハードドライブとSSDのSMARTインジケータのコレクション。

そして実際の問題は何でしたか？

コンソールユーティリティまたはAPIコールを使用して以前にデータを収集することは可能でしたが、困難がありました。

必要なデータ項目ごとにユーティリティの起動を毎回遅くする
各データ要素のリソース（ディスク、ポート、カウンター、アプリケーションAPI）へのアクセス
結果の解析は、外部スクリプト/ユーティリティを使用して行う必要がありました
後で解析を修正する必要がある場合-UserParametersまたはスクリプトを再度更新する必要がありました
とりわけ、複数のZabbixポーラーからの同時リクエストにより、たとえばシリアルポートへのアクセス時にエラーが発生しました。

一般的に、次のようなものでした。

そして、依存データ要素の出現により、次のようになりました。

どのように機能しますか？

Zabbix 3.4では、データソースは親アイテムまたはマスターアイテムと呼ばれる別のデータアイテムにすることができます。このような要素には、たとえば、JSON、XML、または任意のテキスト形式のデータの配列を含めることができます。
新しいデータが親要素に到着すると、従属と呼ばれる残りのデータ要素が親要素にアクセスし、JSONパス、XPath、正規表現などの前処理機能を使用して、テキストから目的のメトリックを抽出します。

ところで、前処理も革新的な3.4です。Zabbixサーバーに新しいプロセスpreprocessing_managerとpreprocessing_workerを追加することで実装されます。したがって、3.2からアップグレードする場合は、サーバーのテンプレートを更新して作業を監視することを忘れないでください。

例に移ります。

マーキュリー236

私たちのプロジェクトでは、コンテナ、仮想マシン、アプリケーション、ネットワークデバイス、データベース、ビジネスインジケーター、および制御を必要とするその他すべてに加えて、電力設備や気候設備などの「エンジニア」のパフォーマンスを監視する必要があると想像してください。弊社のミッドバンドに標準的なデバイスが使用されます：RS-485インターフェースを備えた三相電力計Mercury 236 ART-01 PQRS。メーカー独自のプロトコルを介して通信が行われます。

責任のあるタスクは、電圧、電力、電流、消費、周波数のインジケータをすぐに収集することです。 Zabbixエージェントを使用してこのようなデバイスをサーバーに接続することは実行可能なタスクです。たとえば、RS-485を備えたシリアルポート（USBアダプターなど）で十分です。しかし、データを読み取る方法は？ githubと、スマートホームのソリューションを共有してくれた親切な人々がいなければ、Zabbixにモジュールを作成し、カウンタープロトコルとポーリングインジケーターについて話すことを学びます。

ユーティリティはシンプルで便利です（作成者に感謝します）。作成者は指定されたポートでカウンターに接続し、データを読み取り、テキスト、CSV、またはJSONの形式で提供します。

インストールして実行してみましょう：

git clone https://github.com/Shden/mercury236.git 
      

        
        
        
      

     cd mercury236 
      

        
        
        
      

     make 
      

        
        
        
      

     ./mercury236 /dev/ttyS0 --help 
      

        
        
        
      

     Usage: mercury236 RS485 [OPTIONS] ... 
      

        
        
        
      

     RS485 address of RS485 dongle (eg /dev/ttyUSB0), required 
      

        
        
        
      

     --debug to print extra debug info 
      

        
        
        
      

     --testRun dry run to see output sample, no hardware required 
      

        
        
        
      

     Output formatting: 
      

        
        
        
      

     .... 
      

        
        
        
      

     --help prints this screen

始まる！ OK、カウンターを接続し、質問し、JSONを取得します。

./mercury236 / dev / ttyS0 --json

 { "U": { "p1": 0.35, "p2": 0.35, "p3": 226.86 }, "I": { "p1": 0.00, "p2": 0.00, "p3": 0.39 }, "CosF": { "p1": 0.00, "p2": 0.00, "p3": 0.60, "sum": 0.60 }, "F": 50.00, "A": { "p1": 41943.03, "p2": 41943.03, "p3": 41943.03 }, "P": { "p1": 0.00, "p2": 0.00, "p3": 53.45, "sum": 53.45 }, "S": { "p1": 0.00, "p2": 0.00, "p3": 89.83, "sum": 89.83 }, "PR": { "ap": 120.51 }, "PR-day": { "ap": 86.00 }, "PR-night": { "ap": 34.51 }, "PY": { "ap": 0.00 }, "PT": { "ap": 0.04 } }

その結果、このユーティリティは、カウンターと通信するためのプロトコルを実装し、データを引き出し、さらに便利なJSONオブジェクトの形で提供することさえして、私たちにとって困難な作業をすべて完了しました。以前のように、そのように、それを使用することはできません。スクリプトの形式でバインディングを作成する必要があり、最も重要なのは、シリアルポート環境へのアクセスを制御するメカニズムを実装することです。確かに、2人のZabbixポーラーが同時に3つ目のフェーズ3の電流の後、もう1つがフェーズ2の電流の後、それを同時に使用した場合、何も返されません。

3.4では、すべてが非常にシンプルになり、スクリプトをラップすることなく、各データ要素で同じことを10回実行することなく、サードパーティのコンソールユーティリティからZabbixにデータをすばやく簡単に転送できるようになりました。だから

Zabbixからmercury236ユーティリティの起動を設定します

sudo cp mercury236 /etc/zabbix/scripts 
      

        
        
        
      

     cd /etc/zabbix/scripts 
      

        
        
        
      

     chmod +x mercury236 
      

        
        
        
      

     sudo usermod -G dialout zabbix

スクリプトを実行するには、Zabbixエージェントの設定で新しいUserParameterを作成します：

 UserParameter=mercury236[*],/etc/zabbix/scripts/mercury236 $1 $2

ファイルを保存します。Zabbixエージェントを再起動することを忘れないでください。

次に、新しいテンプレートに親データ要素を作成します。

ご覧のとおり、親データ要素には特別なものはありません-UserParameter Zabbixエージェントをチェックするだけです。これは、どのタイプの検証が親要素として機能できるかについての制限がないことを意味します。ここでは、 Zabbixトラッパーまたは外部チェックを介してデータを受信できます。選択した唯一のものは、情報タイプ-テキストと1日の履歴保存期間です-より長く保存するには、依存要素にメトリックを個別に保存します（保存期間を0に設定して、親要素にデータをまったく保存できません）。このデータ要素の前処理には触れないことに注意してください。

カウンターメトリックを設定する

依存データ項目の作成を開始するには、新しいアシスタントを使用できます。さて、または単に「データ項目の作成」をクリックしてください：

最初のフェーズの電圧のデータ要素を作成し、次を選択します。

タイプ：依存データ項目
一次データ項目：mercury-get

次に、「前処理」タブで、JSONパス式を追加します。

JSONパス：$ .U.p1

ところで、少しアドバイス。デバッグとエラーのキャッチに多くの時間を費やさないために、JSONパスに入力する前に、たとえば、ユーティリティから受け取ったJSONをコピーして、 jsonpath.comでオンラインで式の正確性をすばやく確認できます。

同様に、興味のある他のメトリックを作成します。含む-毎日のレートでの累積エネルギー。

これを行うには、新しいデータ項目を作成し、次を選択します。

タイプ：依存データ項目
一次データ項目：mercury-get

ただし、「前処理」タブでは、2つのニュアンスに注意してください。

JSONパスにハイフンがあるため、角括弧で表記を使用します
前処理はマルチステップにすることができます。たとえば、ここでは最初のステップの結果に1000を掛けて、kW * hからW * hを取得します。

カウンターの残りの主要なメトリックについても同じことを行います。その結果、次のリストが得られます。

テンプレートを思い出しましょう

テンプレートを完成させるために、マクロを使用してトリガーを追加し、可能な限り柔軟にします。トリガーの依存関係を忘れないでください。

どうした

テンプレートの準備が整い、データが実行されました。取得したものを見てみましょう。

1回の呼び出しで収集されたすべての最新データ：

すべてのメトリックの収集時間はまったく同じであることに注意してください。

カウンターの最終テンプレートは、こちらの share.zabbix.comのソリューションリポジトリから入手できます。

要約すると：

優れたプログラムを再利用し、Mercuryプロトコルに従ってデータ収集の実装を記述する時間を無駄にしませんでした
UserParameterは残りましたが、単純な呼び出しに崩壊しました。実際、 system.run []を使用することもできます
scripts-wrappersも作成しませんでした。テンプレート内のJSONパスを介してすべて解析されます
1回のリクエスト-必要なすべてのデータを一度に、カウンターはあまり苦しめられませんでした。

Smartctlおよびsmartmontools

長い間、UserParametersを使用して、ハードドライブのSMARTを制御し、それらを時間内に変更できるようにする方法について、既に説明しました。このアプローチは機能しますが、欠陥がないわけではありません。

smartctlユーティリティの冗長起動、およびそのたびにハードディスクコントローラを有効にする
LinuxとWindowsでは別々の解析を行う必要がありました。今すぐWinで作業するのは特につらいです：（for / F ... so ...二重引用符をさらに引用符でエスケープします....ああ!!!!）

このすべてを取り除くために3.4で試みます。

smartmontoolsの場合には、上記のカウンターの例とは2つの違いがあります。

smartctlがJSONを返さない
サーバーには異なる数のディスクが存在する可能性があるため、低レベル検出（LLD）を使用する必要があります。

しかし、大したことはありません！第一に、従属データ要素はLLDでも機能し、第二に、前処理フィルターの中にPCRE正規表現もあります。これを使用して、ユーティリティの超構造化されていない回答から必要なインジケータを取得します。このようなもの：

始めましょう。

UserParametersの簡素化

それは：

 UserParameter=uHDD[*], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' ' UserParameter=uHDD.model.[*],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " " UserParameter=uHDD.sn.[*],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " " UserParameter=uHDD.health.[*],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " " UserParameter=uHDD.errorlog.[*],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " " UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

次のようになりました：

 UserParameter=uHDD.A[*],sudo smartctl -A $1 UserParameter=uHDD.i[*],sudo smartctl -i $1 UserParameter=uHDD.health[*],sudo smartctl -H $1 UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

for / Fとfindを使用して、CMDマジックを同時に削除し、Windowsに対しても同じことを行います。こちらで見れます。

新しい親データアイテムを作成する

すべてのSMART属性を収集するには、マスターデータ要素のプロトタイプを作成します。

前の例のように、特別な設定は必要ありません。情報タイプのみがテキストであり、保存期間は1日です。

テスト結果とインベントリデータを収集するには、他のキーでsmartctlを実行する必要があります。したがって、同じ方法で、さらに2つのデータ要素を作成します。

uHDD.i ["{＃DISKNAME}"]
uHDD.health ["{＃DISKNAME}"]

SMARTドライブ属性の取得をセットアップする

属性5、再配置の従属データ項目を作成します。

そして、「前処理」タブでは、正規表現を使用します。

JSONパスと同様に、デバッグやエラーのキャッチに多くの時間を費やさないように、正規表現を入力する前に、式の正確性をオンラインですばやく確認すると便利です。たとえば、regex101.comでsmartctl出力をコピーします。

その結果、プロトタイプのそのようなリストを取得します。

テスト、何が起こったかを見る

2台のHDDの場合：

WindowsのSSDの場合：

smartmontoolsを使用した例を要約するには：

UserParametersからすべての解析を削除しました
外部スクリプトはありません（LLDを除く）、外部依存関係はありません。すべての解析はZabbixサーバーで行われ、必要に応じてそこに表示して修正するのは簡単です。
ユーティリティまたはAPIがXML / JSONを返さない場合-関係ありません。常に正規表現を使用してみてください。
ハードドライブをもう苦しめません。最初にSMARTパラメーターの全リストを取得し、次にZabbixサーバーでメトリックに配置します。

更新されたテンプレート（同時に更新されたトリガー、SSDのデータ要素の追加）は、share.zabbix.comのソリューションリポジトリ（こちら）から入手できます。

最後に

メトリックの大量収集は、ネットワークの負荷と監視対象システムのリソースを削減し、外部スクリプトの必要性を減らすためのシンプルで簡単な方法です。多くのZabbixユーザーが気に入ってくれると確信しています。

PSこの記事は、ブログでも英語で入手できます。

Zabbix 3.4：Mercuryおよびsmartmontoolsカウンターの例を使用した大量データ収集