はじめに
EasyBlocks SyslogのZabbix連携機能をご利用中のお客様より、こんなご相談をいただきました。
Zabbixトラッパー連携条件設定の上限300件では足りない！
EasyBlocks Syslogでは、特定条件に一致したログをZabbixサーバーへ転送し、Zabbix側でログ監視を行う構成が可能です。
しかし、Zabbixトラッパー連携条件として設定できる件数には300件という上限があり(ファームウェアバージョン1.2.1時点)、監視対象ホスト数が多い環境では不足するケースが発生します。
そこで今回は、この300件という制約に対し、アプライアンス側の機能拡張ではなく、ネットワーク機器側の設定や運用の工夫で解決できないかを検証してみました。
その過程で試行した内容と、得られた知見についてご紹介します。
Zabbix連携の構成概要図
Zabbixへのログ転送機能について、構成の概要図は以下のとおりです。
また本機能については、以前に解説記事を公開しております。
本機能の概要や設定方法について詳しくまとめておりますので、まだご覧になっていない方はまず最初にお読みいただくことをおすすめします。
背景：レンジ指定では解決できなかった理由
設定上限300件に関して、当初ご案内したのは送信元ホストを個別登録するのではなく、「192.168.1.1–192.168.1.100」のようなレンジでまとめて設定し、Zabbix側で分配する構成にできないか？という方法でした。
しかし実際に試してみると、
・Zabbix側に届くのは「ログ本文のみ」
・どの機器から送られたログなのかが判別できない
・結果としてホスト単位の監視ができない
という課題が発生しました。
発想の転換：送信元情報をログに付加できないか？
EasyBlocks Syslogのログ表示画面では、
日時/ホスト/Facility/Priority/プログラム/メッセージ
といったフィールドで表示されています。
以下が実際のログ表示画面です。
つまり、EasyBlocks Syslog内部では送信元IPアドレスを保持しているということになります。
であれば、送信元IPやホスト名をログ本文の先頭に付加することができれば、Zabbix側で分配可能になるのではないか？と考えました。
しかし、EasyBlocks Syslog側でログ本文を書き換えるのは開発が発生するため、現状今すぐにはできません。なので今回は、ネットワーク機器側で情報を付加できないかを検証しました。
Cisco Catalyst 2960での検証
検証に使用したのはCisco Catalyst 2960 です。Cisco機器には以下の設定があります。
「logging origin-id ip」
この設定により、Syslogに送信元IPを付加できます。
期待したのは、<PRI> timestamp hostname: 172.16.7.206: message のように、message本文の先頭にIPが入ることでした。
tcpdumpでの生ログ確認
EasyBlocks Syslog側でtcpdumpを実行し、実際に送信されているパケットを確認しました。取得できたログは以下の通りです。
<189>22: 172.16.7.206: Feb 26 15:09:10.357: %SYS-5-CONFIG_I: Configured from console by plathome on console
ここで重要なのは「22: 172.16.7.206:」の部分です。
これを踏まえて、
・IPアドレスはメッセージ部分ではない
・Cisco独自のヘッダ部に追加されている
ということが分かりました。
EasyBlocks Syslog側でのパース結果
EasyBlocks Syslog側では以下のように表示されています。
| フィールド | 値 |
| ホスト | 172.16.7.206 |
| プログラム | 172.16.7.206 |
| メッセージ | Feb 26 15:09:10.357: %SYS-5-CONFIG_I: … |
origin-idで付加されたIPは「プログラム(TAG)」として扱われるという結果になりました。
以下はEasyBlocks Syslogで実際に確認したログ表示画面です。
なぜメッセージ欄に入らないのか？…CiscoのSyslog形式はRFC準拠の構造になっています。
基本構造は以下の通りです。
<PRI> timestamp HOSTNAME TAG: message
logging origin-id ipは「HOSTNAME」もしくは「TAG(プログラム)」に値を入れるものであり、メッセージフィールドを書き換えるものではないという仕様のようです。
今回の検証は「失敗」なのか？…結論から言うと、目的(メッセージ先頭へのIP付加)は達成できませんでした。
しかし、CiscoのSyslog構造とEasyBlocks Syslog側のフィールド解釈を具体的に可視化できたことで、今後の連携設計や別アプローチの検討に活かせる土台を得ることができたと思います。
実は使い道があるのでは？
今回の検証では、logging origin-id ipを設定すると、付加された情報はメッセージではなくプログラム(TAG)フィールドに入ることが分かりました。
一見すると「目的には使えなかった」という結果ですが、ここで少し視点を変えてみると、Cisco Catalyst 2960をはじめとするCisco機器では、logging origin-id にhostname、ip、ipv6、stringのオプションがあります。
特に注目したのがstringオプションです。
例えば、「logging origin-id string TOKYO-DC」のように拠点名や環境名を設定した場合、その文字列はプログラムフィールドに格納されます。
活用例①：拠点単位でのログ抽出
EasyBlocks Syslogにはログフィルタリング機能があります。
origin-id に拠点名を設定しておけば、
・プログラム = TOKYO-DC
・プログラム = OSAKA-DC
といった条件でフィルタリングが可能になります。
これにより、送信元IPに依存せず、論理的な単位(拠点・環境・用途)でログを抽出するといった運用が可能になります。
活用例②：マルチテナント環境での識別
複数拠点や複数顧客を1台のEasyBlocks Syslogで収容している場合、origin-id string に
・CUSTOMER-A
・CUSTOMER-B
・LAB
・PRODUCTION
などを設定しておくことで、
・ログ閲覧時の誤認防止
・フィルタリング条件の簡略化
といった活用も考えられます。
今回の検証から見えたこと
当初の目的であった「メッセージ本文への送信元付加」は実現できませんでしたが、
・origin-idはプログラムフィールドに入る
・プログラムフィールドはフィルタリング可能
という挙動を確認できたことで、ネットワーク機器側で「論理ラベル」を付与するという設計が現実的な選択肢として見えてきました。
これは今回の課題とは別の文脈でも、十分に活用できる可能性があります。
まとめ
今回の検証は、Zabbix連携条件の300件制限をきっかけに、ネットワーク機器側の設定で対応できないかを試した取り組みでした。
当初の目的は達成できませんでしたが、Syslogフォーマットの構造やパーサーの挙動を整理できたことは、今後の設計や機能改善を検討するうえでの重要な前提確認となりました。
今回の内容をEasyBlocks Syslog側でどのように実装・機能化していくかは現時点では未定ですが、今後もご利用いただいている皆様の運用に寄り添い、より使いやすい製品となるよう継続的な改良を進めていければと思います。
今後のアップデートにもぜひご期待ください。