SNMPは数十年前から存在していますが、CPUやメモリ使用量といった標準的なメトリクスの取得には優れていますが、ログファイルのサイズや特定のサービスが稼働しているかどうかを知るためには設計されていませんでした。しかし、あまり知られていないsnmp extendという機能を使えば、SNMPデーモンにこれらの質問に答える機能を与えることができます。
このガイドでは、カスタム スクリプトを SNMP に接続し、セットアップをテストし、その周りに軽量の DataSource を構築して、実際に重要なエッジ ケースを監視できるようにする方法を説明します。
snmp extendは古いものを与えるようなものです SNMP 犬にスリッパを持ってきたり、メールをチェックしたりするように教えるなど、ちょっとしたトリックをいくつか設定できます。これは、SNMPが標準では理解できないような情報をレポートできるように、独自のカスタムスクリプトをプラグインする簡単な方法です。
デフォルトでは、SNMPは事前に定義された質問（CPU使用率、ネットワーク統計、メモリ負荷）に回答しますが、「この特定のファイルのサイズはどれくらいですか？」や「Nginxは動作していますか？」といった質問をすると、SNMPは何も答えません。そこでextendの出番です。
SNMP では、ログ ファイルの大きさを教えない限り、ログ ファイルの大きさを知らせることはできません。
snmp extend を使うと、SNMPデーモンの設定ファイルに独自のコマンドやスクリプトを組み込むことができます。設定が完了すると、他のSNMPオブジェクトと同様に、それらのスクリプトをリモートからクエリできるようになります。確かに古風な方法ですが、それでも非常に便利です。特に以下のような場合に便利です。
派手な機能ですか？いいえ。でも、ちゃんと機能します。そして、慎重に使用すれば、snmp extend は、環境にとって何が重要かを、強力かつ簡単に可視化してくれます。
snmp extend の本質は、Net-SNMP デーモン (snmpd) に組み込まれた巧妙なハックです。シェルスクリプト、バイナリ、あるいは du のようなシンプルなコマンドなど、実行するコマンドを指定すると、出力は特別な SNMP OID を通じて公開されます。たったこれだけです。
フローは次のようになります。
次のような行を追加します。extend file-check /usr/bin/du /var/log/syslog
これは snmpd に次のように伝えます: 「誰かがこの SNMP オブジェクトにクエリを実行したら、du /var/log/syslog を実行して出力を返します。」
これにより、新しい構成が適用されます。
sudo systemctl restart snmpd
すべての拡張エントリは .1.3.6.1.4.1.8072.1.3.2.x にマッピングされます。
心配しないでください。覚える必要はありません。出力がここに保存されるということだけ覚えておいてください。
配置が完了したら、他の SNMP メトリックと同様に OID をクエリできます。snmpwalk -v2c -c public myserver .1.3.6.1.4.1.8072.1.3.2
SNMP では次のいずれかが提供されます。
つまり、SNMPは基本的に、実行を指示したコマンドのラッパー（丁寧な仲介役）として機能します。これにより、新しいツールやエージェントを導入することなく、他の方法では実現できないあらゆる種類の監視が可能になります。
PROヒント： これらのコマンドは、snmpd（通常はsnmp）を実行しているユーザーと同じユーザーとして実行されます。そのため、スクリプトが権限、環境変数、またはパスに依存している場合は、それに応じてテストしてください。
snmp extend はスクリプトをSNMPメトリックに変換します。エージェントも手間もかかりません。
snmpd.conf を初めて触る場合でも、心配はいりません。extend エントリの追加は驚くほど簡単です。フォーマットは以下のとおりです。
extend <name> <path_to_command> [optional_arguments]
これを平易な英語で表すと次のようになります。
extend logsize /usr/bin/du /var/log/syslog
syslogファイルのディスク使用量を返します。ディスクを消費する前に、サイズが大きすぎるログを見つけるのに役立ちます。
extend nginx-status /bin/systemctl is-active nginx
これは「アクティブ」または「非アクティブ」を返します。SSH 接続せずにサービスの健全性を確認するのに最適です。
extend custom-health /usr/local/bin/check_health.sh
ディスク容量、メモリ、API 応答をテストするスクリプトを作成しましたか? これを SNMP 経由で公開する方法は次のとおりです。
extend mtime /usr/bin/stat -c %Y /etc/nginx/nginx.conf
ファイルの最終更新日時のUnixタイムスタンプを出力します。設定のドリフト検出に便利です。
設定がうまくいったかテストしたいですか？以下を試してください:
snmpwalk -v2c -c public localhost .1.3.6.1.4.1.8072.1.3.2
これにより、監視可能なすべてのカスタム コマンドと出力が表示されます。
長年のお客様の一人である AppFolioは、私たちに「LogicMonitorを使ってLinuxサーバー上の特定のファイルのサイズを監視できますか？」という、一見簡単なリクエストをしてきました。しかし、標準的な SNMP? 完全ではありません。
LogicMonitorは通常、Linuxシステムの監視にSNMPを使用します。つまり、各サーバーに追加のソフトウェアをインストールする必要がありません。これは大規模環境では大きなメリットです。ただし、SNMPは定義済みのOID（SNMPが回答できる質問のようなもの）のみを公開します。CPU負荷やメモリ使用量は確かにわかりますが、「/var/log/myfile.logのサイズはどれくらいですか？」という質問は、SNMPにあらかじめ用意されている回答ではありません。
コレクターをエージェントとしてデプロイし、スクリプトベースのデータソースを実行してファイルサイズを直接取得することもできますが、これは別のアプローチです（これについては別のブログ記事で詳しく説明します）。今回は、軽量化を図り、SNMPのみを使用することにしました。そこで、あまり知られていないものの強力な機能であるsnmp extendを採用しました。
ここからが楽しいところです。ほとんどのLinuxシステムはNet-SNMPデーモン（snmpd）を使用していますが、嬉しいことにこれは拡張可能です。つまり、特定のファイルのサイズを報告する方法など、新しい機能を追加できるということです。
例えば、/var/spool/rsyslog のサイズを監視したいとします。snmpd.conf ファイルに次の行を追加するだけです。
extend lm-rsyslog-size /usr/bin/du /var/spool/rsyslog
次に、SNMP デーモンを再起動します。
sudo systemctl restart snmpd
これは SNMP に次のように指示します: 「誰かが正しい OID を照会したら、du /var/spool/rsyslog を実行して出力を渡します。」
舞台裏では、SNMPは.1.3.6.1.4.1.8072.1.3.2ツリーに新しいエントリを作成します。しかし、生成されるOIDインデックスの正確な値は少々…分かりにくいです。各拡張エントリは、指定した名前のASCII値に対応するXNUMX進数の長い文字列としてエンコードされます。
拡張されたコマンドを確認するには、次のコマンドを使用します。
snmpwalk -v2c -c public servername .1.3.6.1.4.1.8072.1.3.2.2.1.2
出力例
14.114.97.98.98.105.116.109.113.45.114.101.97.100.121 => /usr/sbin/rabbitmqctl
15.108.109.45.114.115.121.115.108.111.103.45.115.105.122.101 => /usr/bin/du
あの長いドット付きの文字列は？これは「lm-rsyslog-size」というカスタムラベルをエンコードしたバージョンです。
インデックスがわかったので、SNMPを使って実際に出力をクエリできます。出力の最初の行を取得する方法は次のとおりです（通常はこれで十分です）。
snmpget -v2c -c public servername \
.1.3.6.1.4.1.8072.1.3.2.3.1.1.15.108.109.45.114.115.121.115.108.111.103.45.115.105.122.101
そして、その代わりに次のようなものが得られます:
1025360 /var/spool/rsyslog
du コマンドは3.1.2行しか出力しないため、.XNUMX（フル出力）を使用しても同じ結果が得られます。ただし、複数行の出力を生成するスクリプトでは、この区別が重要になります。
snmpd を拡張してファイル サイズを報告できるようにしたので、そのデータを LogicMonitor に取り込んで視覚化し、アラートを発し、時間の経過に伴う傾向を追跡できるようにします。
フリートを管理している場合は、次のような方法でsnmpd.confの変更をすでに展開している可能性があります。 人形、シェフ、または Ansible（そうでない場合は、自動化に最適なケースです。）
「設定」→「データソース」に進み、「新しいデータソース」をクリックします。
ここで、「1 つのファイルだけを監視するのに、なぜ Active Discovery を使用するのか」と疑問に思うかもしれません。
いい質問ですね。答えは、すべてのLinuxサーバーにこの機能があるとは限りません。 OID 利用可能です。拡張機能が展開または有効化されていない場合もあります。そのため、Active Discovery を使用して拡張機能の存在をテストします。
コツは、ディスカバリOIDは、先ほどsnmpgetで使用したインデックス全体よりも1セグメント短くすることです。これは、Active Discoveryが直接snmpgetではなくsnmpwalkを実行するため、インスタンスを作成するためにそのパスの下にある少なくとも1つの結果を確認する必要があるためです。
検出が設定されたら、実際の値（この場合はファイルサイズ）を取得するための標準データポイントを追加します。
SNMP出力には番号とファイルパス（例：1025360 /var/spool/rsyslog）の両方が含まれるため、番号のみを取得するには正規表現が必要です。例えば、以下のようになります。
^(\d+)
これは行頭の数字だけを取得します。まさに監視に必要な機能です。
ここから、次のことができます。
つまり、LogicMonitor に期待されるすべての機能が、シンプルな SNMP 拡張機能によって実現されています。
snmp extendを使用する場合、スクリプトは監視パイプラインの一部となります。そのため、スクリプトは予測可能で、高速かつクリーンである必要があります。拡張機能を堅牢に保つためのベストプラクティスをいくつかご紹介します。
SNMPは、乱雑な出力や冗長な出力の処理には適していません。スクリプトは、解析しやすい1行（または予測可能な複数行形式）を返す必要があります。
良い出力の例:
1025360 /var/spool/rsyslog
悪い出力の例:
File size is currently: 1025360 bytes
Analyzed at: 2024-12-01 10:45:00
snmpdがbash、du、python3の場所を知っていると想定しないでください。参照するコマンドはすべてフルパスで指定してください。
#!/bin/bash
/usr/bin/du /var/log/syslog
SNMP拡張機能は、snmpdサービス（多くの場合snmp）を起動するユーザーと同じユーザーとして実行されます。このユーザーの権限は制限されている場合があります。スクリプトは必ず次のようにテストしてください。
sudo -u snmp /path/to/your/script.sh
SNMPのタイムアウト時間は短くなっています。スクリプトの実行時間が数秒を超えると、SNMPが処理を中断したり、最悪の場合、監視ワークフロー全体の速度が低下したりする可能性があります。
絶対に必要な場合を除き、ループ、スリープ、または大きな出力は避けてください。
複雑な場合は、結果を一時ファイルにキャッシュし、スクリプトで即座に結果を返すことを検討してください。
ファイルの不足や権限の問題など、何か問題が発生した場合でも、スクリプトは出力行（場合によっては終了コード）を返す必要があります。そうすることで、失敗を捕捉し、ウォーク全体の中断を回避できます。
読み取り、ユーザー入力、パスワードプロンプトはありません。スクリプトは手動による介入を必要としません。
LogicMonitorがフォーマット、グラフ化、アラート出力を行います。あなたの仕事は、正しい数値やステータスを返すことだけです。
テスト中は、何が起こっているかを確認するために一時ファイルにログを記録すると役立ちます。
echo "$(date) :: Ran extend script" >> /tmp/snmp-extend-debug.log
ただし、本番環境では使用しないでください。特に5分ごとに実行される場合は注意が必要です。
snmp extend は昔の回避策のように思えるかもしれませんが、Linux サーバーからカスタムメトリクスを取得できる信頼性の高い方法であり、エージェントは不要です。設定に数行追加し、スクリプトを少し追加するだけで、環境にとって重要な情報を正確に可視化できます。
LogicMonitor にデータが取り込まれたら、グラフ化したり、アラートを生成したり、傾向を分析したりして、日々の業務を続けることができます。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
