この記事では、ネットワーク機器が出力するSyslogの重要性と、その具体的な活用方法について、New Relicを使いながら解説します。パフォーマンスデータだけでは見えない障害の予兆や原因を突き止めるための、重要な一歩です。
なぜ今、Syslogが重要なのか？
前回の記事では、PingとSNMPを使った「健康診断」の方法を学びました。これらは、機器のCPU使用率やトラフィック量といったパフォーマンスを定量的に把握するための、いわば「バイタルサイン」です。
しかし、これらの数値だけを見ていても、「なぜ急にメモリ使用率が95%に達したのか？」「なぜトラフィックが突然ゼロになったのか？」といった、現象の裏側にある原因を特定することは困難です。
そこで活躍するのがSyslogです。Syslogは、ネットワーク機器が自身の状態変化や特定のイベントを記録した、いわば「行動ログ」や「つぶやき」のようなものです。
- SNMP（量的データ）: 機器の状態を数値で示す（例：メモリ使用率が95%に高騰）
- Syslog（質的データ）: 機器のイベントをテキストで示す（例：メモリ不足により、重要なプロセスがOSに強制終了された）
この2つを組み合わせることで、私たちは初めて「メモリが高騰したために、プロセスが異常終了した」という因果関係を推測し、可観測性を高めることができるのです。
Syslogの基礎知識
Syslogそのものは古くからある技術ですが、そのメッセージ構造の基本を知っておくことは、ログを読み解く上で非常に役立ちます。最低限、以下の2つの要素は覚えておきましょう。
- ファシリティ (Facility): ログの生成元（どのプログラムやプロセスからのメッセージか）を示します。例えば、OSのカーネル、メールシステム、あるいはネットワーク機器の独自プロセスなどです。
- シビリティレベル (Severity Level): メッセージの重要度・緊急度を示す0から7までの数値です。数値が小さいほど緊急性が高くなります。
| レベル | キーワード | 説明 |
|---|---|---|
| レベル0 | キーワードEmergency | 説明システムが使用不可能な状態 |
| レベル1 | キーワードAlert | 説明ただちに対処が必要な状態 |
| レベル2 | キーワードCritical | 説明危機的な状態 |
| レベル3 | キーワードError | 説明エラー状態 |
| レベル4 | キーワードWarning | 説明警告状態 |
| レベル5 | キーワードNotice | 説明通常だが重要な状態 |
| レベル6 | キーワードInformational | 説明情報メッセージ |
| レベル7 | キーワードDebug | 説明デバッグ用メッセージ |
【実践】New RelicでSyslogを収集・可視化する
ガイド付きインストールとの違いについて New RelicのWeb UIには、
ktranslateエージェントを簡単に導入するための「ガイド付きインストール」機能が用意されています。これは、基本的な設定を素早く試すのに非常に便利です。一方、この記事では、本番環境での安定運用やカスタマイズを想定した、より実践的な手動での設定方法を解説します。ここで紹介する方法は、SNMPとSyslogのプロセスを明確に分離するなど、ガイド付きインストールよりも一歩進んだ構成となっており、
ktranslateの動作原理を深く理解することにも繋がります。
それでは、実際にktranslateエージェントを使って、ネットワーク機器からのSyslogをNew Relicに転送し、SNMPデータと正しく紐付けましょう。
収集アーキテクチャ：役割の完全な分離
安定したデータ収集のため、ktranslateはSNMPポーリング用とSyslog受信用でプロセスを分離することが仕様として定められています。
公式ドキュメントに記載されていますが、SNMPデータとSyslogデータを正しく紐付けるには、device_nameが一致する必要があります。しかし、SNMP用の設定ファイルをそのままSyslogコンテナで使うと、意図しないポーリング動作を引き起こす可能性があります。
そこで、私たちは2種類の役割を限定した設定ファイルを用意するアプローチを取ります。
snmp-base.yaml: SNMPポーリングに必要な全ての情報（ポーリング間隔、MIB、デバイスリスト等）を記述した、完全な設定ファイル。syslog-devices.yaml:device_ipとdevice_nameのみを記述した、SyslogのIPマッピング専用のシンプルな設定ファイル。
この構成により、Syslog用コンテナはポーリングなどの余計な動作を起こさず、「IPアドレスとデバイス名を紐付ける」という役割だけに専念させることができます。
設定ファイルの準備
まず、snmp-base.yamlを元に、IPとデバイス名のマッピングに特化したsyslog-devices.yamlを作成します。
snmp-base.yaml (SNMP用・抜粋)
global:
poll_time_sec: 60
# (中略)
devices:
your-router-01:
device_ip: 192.168.1.1
snmp_comm: public
mib_profile: cisco-router.yml
your-switch-01:
device_ip: 192.168.1.2
snmp_comm: public
mib_profile: cisco-switch.yml
# (以下略)syslog-devices.yaml (Syslog用)
# IPアドレスとデバイス名をマッピングするためだけのシンプルな設定
devices:
your-router-01:
device_ip: 192.168.1.1
# mib_profileやsnmp_commなどの余計な情報は含めない
your-switch-01:
device_ip: 192.168.1.2【ヒント】設定ファイルの同期を自動化する 💡
snmp-base.yamlを更新するたびにsyslog-devices.yamlを手動で修正するのは大変です。そこで、yqというコマンドラインツールを使って、この作業を自動化しましょう。前提:
yqがインストールされている必要があります。（pip install yqなどでインストール可能です）スクリプト: 以下の1行のコマンドを実行するだけで、
snmp-base.yamlからdevice_ipとdevice_nameの情報だけを抜き出したsyslog-devices.yamlを自動生成できます。
yq '.devices | with_entries(.value |= {"device_ip": .device_ip})' snmp-base.yaml > syslog-devices.yamlsnmp-base.yamlに新しいデバイスを追加した際は、このコマンドを一度実行するだけで、Syslog用の設定ファイルも安全に更新できます。
自動検出（Discovery）と組み合わせる場合 -snmp_discovery_minフラグなどを用いてsnmp-base.yamlを定期的に自動更新している場合は、上記のyqコマンドも追随して定期実行する必要があります。cronジョブとして登録するのが最も簡単な方法です。
例えば、毎時0分にyqコマンドを実行してファイルを同期させるには、crontab -eで以下のように記述します。
# 毎時0分に、snmp-base.yamlからsyslog-devices.yamlを再生成する
0 * * * * /usr/local/bin/yq '.devices | with_entries(.value |= {"device_ip": .device_ip})' /path/to/your/snmp-base.yaml > /path/to/your/syslog-devices.yaml注意: cronで実行する場合、yqコマンドや設定ファイルのパスは、環境変数に依存しない絶対パスで指定してください。
docker-compose.yml の設定
2つの設定ファイルを、それぞれのコンテナにマウントします。
version: '3'
services:
# ① SNMPポーリング用のktranslateコンテナ
ktranslate-snmp:
image: kentik/ktranslate:v2
container_name: ktranslate-snmp
restart: unless-stopped
command:
- "-snmp=snmp-base.yaml" # 完全版のYAMLを参照
- "-nr.account_id=YOUR_NEWRELIC_ACCOUNT_ID"
environment:
- NEW_RELIC_API_KEY=YOUR_NEWRELIC_LICENSE_KEY
volumes:
- ./snmp-base.yaml:/snmp-base.yaml # 完全版をマウント
- ./mibs:/mibs
networks:
- ktranslate-net
# ② Syslog受信用（リスナー）のktranslateコンテナ
ktranslate-syslog:
image: kentik/ktranslate:v2
container_name: ktranslate-syslog
restart: unless-stopped
ports:
- "5140:5140/udp"
command:
- "-snmp=syslog-devices.yaml" # マッピング専用のYAMLを参照
- "-syslog.listen=0.0.0.0:5140"
- "-nr.account_id=YOUR_NEWRELIC_ACCOUNT_ID"
environment:
- NEW_RELIC_API_KEY=YOUR_NEWRELIC_LICENSE_KEY
volumes:
- ./syslog-devices.yaml:/syslog-devices.yaml # マッピング専用のYAMLをマウント
networks:
- ktranslate-net
networks:
ktranslate-net:New Relic UIでの確認
設定完了後、New RelicのLogs画面で、source: 'syslog' AND device_name: 'your-router-01' のようにクエリを実行すれば、特定のデバイスからのSyslogだけを正確に絞り込むことができます。
まとめ
今回は、ネットワーク機器の"つぶやき"であるSyslogを収集し、SNMPデータと正しく紐付ける方法を学びました。
- SNMP（状態）とSyslog（イベント）はセットで監視することで、障害の因果関係の調査が飛躍的に効率化します。
- 安定運用と正しいデータ紐付けを両立するため、役割を限定した2種類の設定ファイルを用意し、
ktranslateプロセスを分離するのがベストプラクティスです。 yqとcronを組み合わせることで、設定ファイルのメンテナンスを自動化・効率化できます。
これまでは、ネットワーク機器という「点」の状態を様々な角度から見る方法を学んできました。
次回は、いよいよ視点を変え、機器と機器の間を流れる通信そのものに焦点を当てます。応用編の第一歩、「Flow分析」の世界に飛び込み、ネットワークが重い"真犯人"を突き止める理論を学びましょう。ご期待ください！
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
