こんにちは。SCSKの嶋谷です。
mackerelはエージェント型の監視ツールのため、ネットワーク機器のようなエージェント導入不可の機器を監視できないと思っていませんか？
ネットワーク機器のようにエージェントを導入できない機器であっても、mackerelでは監視を行うことができます。
具体的には、mackerelが提供する公式プラグインやOSSを活用することで、Ping監視やSNMP監視を実現できます。
これにより、ルーターやスイッチ、ファイアウォールなどのネットワーク機器についても、サーバーと同様に統合的な監視が可能となります。
本記事では、ネットワーク機器の死活監視に焦点を当て、mackerelで監視を実現する方法を解説します。
mackerelでは主に以下の2つの方法が利用できます。
- mackerel公式プラグインを利用する方法
- OSSを利用する方法
以降より、2つの詳細な方法を解説していきます。
mackerelでのネットワーク機器(エージェント導入不可機器)の監視
mackerelでは、監視マネージャーとなるサーバーを1台用意し、そのサーバーから各機器へポーリングを実施することで監視を実現します。
監視マネージャーにはmackerelエージェントおよびOSSを導入し、PingやSNMPによってネットワーク機器の状態を定期的に取得します。取得した監視結果はmackerelへ送信され、ダッシュボードでの可視化やアラート通知に利用されます。
この構成を採用することで、エージェントを導入できないルーターやスイッチ、ファイアウォールなどのネットワーク機器についても、mackerel上で一元的に管理することが可能です。
構成イメージを以下に示します。
公式プラグイン(check-ping)を利用する場合
check-pingとは
check-pingは、mackerelで公式にサポートされているPing監視用プラグインです。
監視マネージャーから監視対象機器に対して定期的にICMP Echo Request（Ping）を送信し、応答の有無を確認することで死活監視を実現します。
check-pingでは、監視設定で指定した回数だけPingを送信し、すべてのPingで応答が得られなかった場合に障害と判定します。
詳細は下記をご参照ください。
チェックプラグイン – check-ping – Mackerel ヘルプ
設定方法
監視マネージャーにmackerel-agentがインストールされていることと監視対象機器への疎通性があることが前提条件となります。
mackerel-agentのコンフィグファイル(mackerel-agent.conf)に監視設定を記載します。
[plugin.checks.プラグイン名] command = ["check-ping", "-H", "監視対象ホスト名またはIPアドレス", "-n", "パケット送信回数", "-w", "RTT閾値"]
上記内容を監視対象台数分記載する必要があり、プラグイン名は重複が不可となります。
コンフィグファイルへの監視設定記載後、mackerel-agentの再起動を実施することで設定が反映されます。
実行結果
check-pingを設定した際の正常時とアラート検知時のmackerelコンソールを以下に示します。
正常時はホストのMonitor一覧にOKの状態で表示されます。
アラート検知時はホストのMonitor一覧にCRITICALの状態で表示されます。
アラート詳細画面から発生日時などを確認することができます。
上記のようにcheck-pingを利用することで監視対象の死活判定を簡単に実施することができます。
OSS(sabapingd)を利用する場合
sabapingdとは
Mackerel Labsが提供しているOSSの監視ツールであり、mackerel-agentを導入せずに動作させることが可能です。もちろん、mackerel-agent環境と併用して利用することもできます。
Linux向けのdebパッケージおよびrpmパッケージが提供されています。
※制約としてOSのsystemdバージョンがv247以降に対応している必要があります。
一方で、Windows向けのパッケージは提供されていないため、利用する場合はLinuxサーバーを監視マネージャーとして準備する必要があります。
sabapingdは監視マネージャーから監視対象機器へ定期的にICMPパケットを送信し、その結果をmackerelへメトリックとして送信します。
check-pingが死活判定を主目的としているのに対し、sabapingdは応答時間（Response Time）やパケットロス率（Packet Loss Rate）を継続的なメトリックとして収集できる点が特徴です。
そのため、「応答があるかどうか」だけではなく、「応答時間が通常時より長くなっていないか」「パケットロスが発生していないか」といったネットワーク品質の変化を可視化できます。
また、収集したメトリックに対してしきい値監視を設定することで、応答時間の増加やパケットロス率の上昇をトリガーとしたアラート通知も実現できます。
詳細は下記をご参照ください。
GitHub – mackerelio-labs/sabapingd · GitHub
設定方法
①メトリック送信先となるホスト（仮想ホスト）の登録
sabapingd は、mackerel-agent を導入できないネットワーク機器の Ping 監視結果をメトリックとして収集し、mackerel へ送信するツールです。
そのため、送信したメトリックを受け取るための ホスト（仮想ホスト） をあらかじめ mackerel に登録しておく必要があります。
サーバー監視の場合は、mackerel-agent をインストールするとホスト情報が自動的に mackerel へ登録されますが、ネットワーク機器の監視ではその仕組みを利用できません。そのため、監視対象ごとにメトリックの送信先となる仮想ホストを手動で作成する必要があります。
また、1つの仮想ホストを複数の監視対象で共有することはできないため、監視対象となるネットワーク機器の台数分だけ仮想ホストを登録する必要があります。
仮想ホストの登録はmkrコマンドを利用する場合とmackerelAPIを利用する場合の2種類を利用することができます。
mkrコマンドの場合
MACKEREL_APIKEY=<API_KEY> mkr create --customIdentifier <custom-identifier-name> <hostname>
mackerelAPIの場合
curl -k -X POST -H "X-Api-Key: <API_KEY>" -H "Content-Type: application/json" -d '{"name":"XXX","customIdentifier":"XXX","meta":{}}' "https://api.mackerelio.com/api/v0/hosts"
詳細は下記をご参照ください。
mkr：CLIツール mkr を使う – Mackerel ヘルプ
mackerelAPI：ホスト – Mackerel API ドキュメント (v0)
②パッケージのインストール
監視マネージャーのOSに合わせたパッケージをインストールしてください。
GithubのReleaseページからダウンロード可能です。
Releases · mackerelio-labs/sabapingd · GitHub
③設定ファイルに監視設定を記述
/etc/sabapindディレクトリにsabapingd.yamlを作成して設定を記述。(/etc/sabapingdディレクトはインストール時に自動で生成されます。)
インストール時には設定ファイルのサンプルとしてsabapingd.yaml.sampleがあらかじめ配置されます。そのため、新規に設定ファイルを作成するのではなく、サンプルファイルをコピーして必要な箇所のみ修正する方法がおすすめです。
x-api-key: xxxxx # disk-cache: # 通信が長時間途絶えた場合にデータを保持する機能で、一定数を超えるとファイルとしてデータを保存 # directory: cache #未送信データの保存パス # size: 10MB collector: #監視対象を設定グループで対象台数分設定を記載 - host-id: xxxxx # mackerelに登録されているホスト固有のID host: XXX.XXX.XXX.XXX # 監視対象IPアドレス # custom-identifier: xxxx # 仮想ホストへデータを送信する際に利用し、host-idの代わりとして指定 # average: true # 平均メトリックのみを送信する場合に利用 # always-send-packetloss: true # packetloss が 0 の状態でも毎回メトリックを送信する場合に利用 - host-id: xxxxx host: XXX.XXX.XXX.XXX # custom-identifier: xxxx # average: true # always-send-packetloss: true
④sabapingdサービスを起動
yamlファイルの修正が発生した際は、サービスの再起動が必要です。
systemctl start sabapingd
実行結果
sabapingdを設定した際の正常時とアラート検知時のmackerelコンソールを以下に示します。
正常時はレスポンスタイムとパケットロス率のグラフが表示されます。
パケットロスが発生したタイミングでレスポンスタイムのメトリックが取得できていないことを図から読み取ることができます。
パケットロス率に対してしきい値を設定して、パケットロスを発生させるとアラートとして検知することができます。
レスポンスタイムにしきい値を設定することで、応答時間の遅延をアラートとして検知することも可能です。
sabapingdを利用してレスポンスタイムやパケットロス率を監視することでネットワーク品質の監視を実現することが可能となります。
まとめ
今回は、mackerelを利用してネットワーク機器の死活監視を実現する方法について紹介しました。
mackerelはエージェント型の監視サービスというイメージが強いため、ネットワーク機器の監視は難しいと思われることがあります。しかし、公式プラグインのcheck-pingやMackerel Labsが提供するOSSのsabapingdを利用することで、エージェントを導入できないルーターやスイッチ、ファイアウォールなども監視対象に含めることができます。
今回の検証を通じて、単純な死活監視であれば設定が容易なcheck-pingが有効であり、応答時間やパケットロス率といったネットワーク品質まで可視化したい場合はsabapingdが有効であることを確認できました。特にsabapingdはメトリックとしてデータを蓄積できるため、障害発生時の状況確認や性能劣化の傾向分析にも活用できると感じました。
また、どちらの方法も監視マネージャーを1台用意するだけで構築できるため、既にmackerelを利用している環境であれば比較的容易にネットワーク機器監視を追加できます。サーバー監視とネットワーク機器監視を同一プラットフォームで管理できる点も大きなメリットだと感じました。
本記事が、mackerelによるネットワーク機器監視の導入や検討を進める際の参考になれば幸いです。
今後はSNMPを利用したトラフィック監視やインターフェース監視についても検証していきたいと思います。
最後までお読みいただきありがとうございました。