こんにちは。SCSKの嶋谷です。
今回もMackerelに関する記事を投稿します。
弊社が提供している監視サービスではNW機器の監視をしたいというお客様が一定数います。
Mackerelはエージェント型の監視サービスであるため、NW機器のようなエージェントをインストールすることができない機器の監視はどのように実現すると思いますか？
例えば、NW機器の死活監視(Ping監視)を実現する機能があります。しかしこの機能だけでは不足おり、一例としてSNMP(特にTrap監視)での監視が挙げられます(後述)。そのため、お客様に対してMackerelを利用した監視サービスを提供する場合、Mackerelの標準機能ではSNMP監視を提供することが難しいです。
どうにかしたいなとMackerelのドキュメントを読み漁っていると、SNMP Get監視についてはプラグインが提供されていることを発見しました。しかし、SNMP Trap監視の機能については発見することができませんでした。そこで、SNMP Trap監視についてはTrapをログファイルに出力してMackerelのログ監視機能で代替できるのではないかと考え、実装してみました。
MackerelでのSNMP監視
Mackerelでは、メトリックプラグインを利用してSNMP Get監視を実現することが可能です。
こちらのプラグインはSNMP v2cに対応しております。
SNMP Trap監視はMackerelの機能としてはサポートされておりません。
そのため、SNMP Trap監視については監視不可能だと考えていました。
部署の先輩に相談すると、「Trapをログファイルに出力して、ログ監視で実現できそう」と助言をいただき、代替できそうと考え実装することにしました。
今回はSNMP GetのプラグインとSNMP Trapのログ監視を検証してみました。
機器構成
今回は検証機器の都合上NW機器をサーバで代替して検証を実施しました。それぞれのサーバの役割・機能については下記に示しております。
サーバA：監視マネージャー(ポーリングによる値取得、SNMP Trap受信)
サーバAはsnmptrapdサービスとmackerel-agentがインストールされており、取得したSNMP監視に関するデータをMackerelに送信します。
サーバB(NW機器)：監視エージェント(SNMP Trap送信)
サーバBはSNMPサービスがインストールされており、TrapデータをサーバA(監視マネージャー)に送信します。
SNMP Get監視
SNMP Get監視はMackerelのメトリックプラグインを利用することで実現することができます。
実装方法を以下に示します。(監視マネージャーにmackerel-agentがインストールされていることとファイアウォールでの通信が許可されていることを前提とします。)
① 監視エージェントにSNMPサービス(Linuxではsnmpd)をインストール
監視マネージャーからのポーリングに応答するためにインストールする必要があります。
② SNMPサービスをインストール後、コミュニティ名、ポーリングを許可するIPアドレスを設定します。
(検証では監視エージェントをWindows Serverで構築しています)
③ 監視マネージャー側のmackerel-agentのコンフィグファイルに設定を追記
プラグイン名、メトリック名は任意で設定可能です。
コミュニティ名は監視エージェントで設定した名前を設定します。
[plugin.metrics.プラグイン名] command = ["mackerel-plugin-snmp", "-name", "グラフ名", "-community", "コミュニティ名", "OID:メトリック名"]
④ mackerel-agentを再起動
sudo systemctl restart mackerel-agent
SNMP Trap監視
SNMP Trap監視はTrapをログファイルに出力してMackerelのログ監視で代替します。
実装方法を以下に示します。(ファイアウォールでの通信が許可されていることを前提とします)
① 監視マネージャーにnet-snmpをインストール
これにより、snmptrapdサービスを利用することが可能となります。
② snmptrapdのコンフィグファイルに以下を追記
コミュニティ名からのTrap受信を許可するための記述です。
authCommunity log, execute, net コミュニティ名
③ snmptrapd.serviceに以下を追記
受信したログを指定したファイルに出力するための記述です。
ExecStart=/usr/sbin/snmptrapd -Lf ログファイルパス
④ snmptrapdサービスの永続化・再起動
下記コマンドを実行します。
systemctl daemon-reload systemctl enable --now snmptrapd systemctl restart snmptrapd
実行結果
SNMP Get監視
今回は検証としてCPU使用率を取得してMackerelに連携してみました。
SNMP標準のCPU使用率はコアごとのCPU使用率となっており、全体としての使用率ではありません。
実施方法を以下に示します。
① コアごとのCPU使用率を確認
snmpwalk -v 2c -c コミュニティ名 IPアドレス .1.3.6.1.2.1.25.3.3.1.2
② コアごとのOIDをmackerel-agentのコンフィグファイルに設定してデータを取得
プラグイン名、グラフ名、メトリック名は任意で設定可能です。
コミュニティ名は監視エージェントで設定した名前を設定します。
[plugin.metrics.プラグイン名] command = ["mackerel-plugin-snmp", "-name", "グラフ名", "-community", "コミュニティ名", ".1.3.6.1.2.1.25.3.3.1.2.1:メトリック名"]
③ mackerel-agentを再起動
④ Mackerelのコンソールにグラフが表示される
今回対象としたサーバのコア数は2つであったため、2つの値を同じグラフに可視化しています。
値を取得してグラフに表示することは簡単にできましたが、取得したい値のOIDを調査することに苦戦しました。
SNMP Trap監視
今回は検証のため、snmptrapのテストコマンドを監視エージェントで実行し、監視マネージャーのログファイルに出力されるかを確認しました。確認後にMackerelでログ監視の設定を行い、検知可能かを確認しました。
実施方法を以下に示します。
① 監視エージェントでテストコマンド実施
今回はlinkDownを疑似的に発生させました。
snmptrap -v 2c -c コミュニティ名 IPアドレス "" IF-MIB::linkDown IF-MIB::ifIndex i 1
② ログファイルに出力されているかを確認
ログファイルにTrapが出力されていることを確認しました。Trapの内容を下記に示します。
NET-SNMP version 5.9.3 2025-08-25 09:52:51 ホスト名 [UDP: [送信元IPアドレス]:50163->[送信先IPアドレス]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (29120791) 3 days, 8:53:27.91 SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkDown IF-MIB::ifIndex = INTEGER: 1
③ Mackerelでログ監視の設定を実装
今回はlinkDownを検知文字列としてコンフィグファイルに設定を追記しました。追記した内容を下記に示します。
Mackerelのログ監視の仕様については下記をご参照ください。
チェックプラグイン – check-log – Mackerel ヘルプ
[plugin.checks.snmptraplog] command = ["check-log", "--file", "/var/log/snmptrapd.log", "--pattern", "linkDown", "--return", "--check-first"]
④ mackerel-agentを再起動
⑤ アラートの確認
linkDownが含まれているログを検出し、アラートとして検知できました！
ここで1点注意点があります。
Mackerelのログ監視は1分間隔で監視を実施し(実行間隔については調整可能です)、1分間の間にログファイルへ出力されたTrapを対象とします。1分間に大量のTrapが出力され、ログ監視の実行間隔内で処理が完了できないとエラーが出力されます。
ログ出力の条件や実行間隔の設定も柔軟に行うことが必要かもしれません。
課題
SNMP Get、SNMP Trapともにデータの取得からMackerelへの連携やアラート検知を実装することができました。
今回の検証では標準のOIDを利用しており、ベンダー固有のOIDについては検証していません。
今後の検証を通して、標準情報だけでなくベンダー固有の情報もMackerelで監視可能か確認する必要があります。
ただ、MackerelでSNMPの監視を実現する第一歩になったと感じています。
まとめ
今回はMackerelのプラグインとログ監視の機能を用いて、SNMPの監視を実装することができました。
SNMP監視については触れたことがない領域だったため、概念を学習してから環境を構築する必要があったため時間がかかりました。
時間がかかった分、Mackerel上でグラフの可視化やアラートを検知できたときは感動しました！
今後は、ベンダー固有のOIDでも監視が可能か検証することが必要と考えています。
最後までご覧いただきありがとうございました！