はじめに
最近、お客様から立て続けに同じご質問をいただきました。
EasyBlocks Syslogでログが取れていなかったら、何か分かる方法はないですか？
ログを集める装置なのに、ログが集まっていないことに気づけない。
言われてみれば、確かにそのとおりです。
EasyBlocks Syslogには自身のプロセス監視があり、AirManageと連携していれば管理者にメールを送信することもできます。ただしそれで分かるのは、Syslogサーバー自身のプロセスに異常が起きた場合です。
必要なプロセスがダウンしていればログが取得できていないという現象につながる可能性はもちろんありますが、サーバーは元気に動いている。Web UIも開く。でも、ある機器からのログだけが3日前から届いていない。送信側の設定が変わった、機器が交換された、経路のフィルタが変わった。よくある話です。
そして気づくのは、インシデント対応で「あの日のログを見せてください」と言われたときです。最も必要なタイミングで、ログが存在しない。
今回は、この「特定の機器からログが届かなくなった」状態を検知する仕組みを作ってみます。
なぜ外部から監視するのか
Syslogサーバー自身に「ログが来ていないこと」を検知させるのは、実は難しい話です。
来ていないことを知るには、来るはずのものを知っていなければなりません。機器が何台あって、それぞれどのくらいの頻度でログを出すのか。
それはSyslogサーバーの本来の仕事ではありません。
そこで今回は、EasyBlocks 監視シリーズから、EasyBlocks Syslogを外から監視する構成にしました。
EasyBlocks Syslogには蓄積したログをCSVで取り出すエクスポートAPIがあるので、これを活用して「指定した送信元のログが、直近◯分の間に届いているか」を確認します。
標準の監視コマンドにそんな項目はありませんが、これまでも標準にない監視は追加プラグインで足してきました。今回もその方式で、プラグインはAIに作成してもらいます。
「何分の沈黙なら異常か」問題
作り始める前に、ひとつ決めなければならないことがあります。
何分ログが来なければ異常とみなすのか、です。
これが思ったより厄介でした。検証環境のSyslogに届いていたログを、送信元ごとに1日分集計してみます。
| 送信元 | 1日の件数 | 平常時の間隔 | パターン |
|---|---|---|---|
| ルーター | 117,910 | 約0.7秒 | 大量連続 |
| Syslog機自身 | 15,233 | 約5.7秒 | 大量連続 |
| 機器A | 287 | 5分 | 定期送信 |
| 機器B | 192 | 7.5分 | 定期送信 |
| センサー機器 | 49 | 30分 | 定期送信 |
同じ環境の5台で、平常時の間隔が約2,400倍違います。
仮に「10分間ログが無ければ異常」という一律のルールにすると、ルーターの障害は検知できますが、30分間隔のセンサー機器は毎日誤検知することになります。
では「1日無ければ異常」にすればいいかというと、今度は毎秒ログを吐いていたルーターが丸一日沈黙していても気づけません。11万件のログが届かなくなっているにもかかわらず、検知されないのです。
さらに、時間帯別に見ていて気になるものがありました。5分間隔で定期送信している機器が、18時台だけ1件少なかったのです。
12件 2026-08-23 16時
12件 2026-08-23 17時
11件 2026-08-23 18時 ← 1件足りない
12件 2026-08-23 19時
きっちり定期送信している機器でも、たまに1件落ちます。ネットワークの瞬断か、送信タイミングのずれか・・・。原因はともかく、この機器に「5分無音で異常」と設定していたら、その日は誤検知が出ていたはずです。
つまり平常時の間隔をそのまま閾値にしてはいけない、ということです。倍以上の余裕を持たせる必要があります。前回の証明書の記事でも「残り30日」という一律の閾値が対象によって意味を変える話を書きましたが、今回も構造は同じでした。
AIに指示した内容
方針が決まったので、プラグインを作ります。
標準出力は1行、終了コードは0〜3、引数は $HOSTADDRESS$ と $ARG1$ 以降で受け取る。この作法と、既存の自作プラグインと書き方を揃える点は前回と同じなので省略します。
今回ならではなのは、APIの仕様です。ここは事前に実機で叩いて、応答の実際を確認してから渡しました。
- ログがある場合は text/csv でCSVが返る（ヘッダー行なし、時刻の昇順）
- 該当ログが無い場合も text/csv だが、0バイトで返る
- 認証やテーブル指定を誤ると application/json でエラーが返る
- テーブルは日次と月次を選べるが、今回は月次テーブルを使う
- 月をまたぐ範囲を見る場合は、月次テーブルを2つ配列で指定する
そして判定ロジックです。
- 直近5分の範囲に、対象ホストのログがあるか問い合わせる（limit:1）
- あれば OK(0)
- 無ければ、直近15分の範囲を問い合わせる
- あれば WARNING(1)、無ければ CRITICAL(2)
- 接続失敗・タイムアウト・APIエラーは UNKNOWN(3)
5分・15分の部分は監視対象ごとに指定できるようにしました。この後で出てきますが、大量にログを出す機器と30分に1回しか送らない機器とでは、まったく違う値を設定することになります。
ここで重要なのが、「ログがゼロ件」と「API呼び出しの失敗」を区別することです。どちらも結果としては何も返ってきませんが、意味はまったく違います。認証情報の書き間違いを「ログが届いていない」と判定してしまっては、監視として成立しません。
幸い、実機で確認したところ両者はContent-Typeで見分けられました。ログがゼロ件なら text/csv で0バイト、エラーなら application/json。この違いを判定の根拠にしています。
なお存在確認はlimitを1にしているので、平常時は1件だけ取得して終わりです。11万件出しているルーターが相手でも負荷になりません。
出力結果
182行のプラグインが出てきました。
APIの応答を模したテスト用サーバーを立てて、ログがある場合・ゼロ件の場合・認証エラー・タイムアウトをひととおり確認してから実機に持っていきましたが、修正なしでそのまま動きました。
EasyBlocks Syslog側の準備
プラグインはCSVエクスポートAPIを使うので、EasyBlocks Syslog側でこの機能を有効にしておきます。
EasyBlocks 監視に登録する
「追加ファイル管理」で管理対象ファイルに「監視コマンドプラグイン」を選び、作成したファイルをアップロードします。実行引数設定はこう指定しました。
-h $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
「変数情報取得」の「取得」を押すと動作確認用の入力欄が現れるので、その場で試せます。まずはログが届いている機器を対象にしてみます。
返り値0。直近5分以内にログを受信していることが確認できました。
続いて、ログが届いていない状態も確認します。Syslogに一度もログを送っていないアドレスを指定してみます。
返り値2でCRITICAL。「直近15分間、このホストからのログが無い」と判定されました。ゼロ件を正しく検知できています。
監視対象と監視パターンを作る
動作確認が通ったので保存し、監視の設定に進みます。今回は性格の違う3台を登録しました。
メモ欄に平常時の流量を書いておくと、後で閾値を見直すときに助かります。
次に監視パターンです。ここが今回の肝で、同じプラグインでも対象によって閾値を変えます。
大量にログを出すルーターは、5分の沈黙で警告、15分でCRITICAL。
30分間隔で定期送信している機器は、90分の沈黙で警告、180分でCRITICAL。
同じ監視コマンドを使いながら、変数指定は 5!15 と 90!180。
18倍の開きがあります。対象の性格に合わせて閾値を変えられるようにしておいて正解でした。
監視状況を確認する
保存すると、監視状況一覧に結果が並びます。
ルーターはOK。直近5分以内にログが届いています。
センサー機器もOK。こちらは90分の基準で判定しています。
そして、ログが届いていない機器は。
CRITICALで赤くなりました。「直近15分間、この機器からのログが届いていない」ことが一目で分かります。
Syslogサーバー自身は正常に動いていて、他の機器からのログは問題なく届いている。その状態でも、特定の機器の沈黙だけを拾えるようになりました。
この監視でできること、できないこと
検知できるのは「ログが届いていない」という事実だけです。原因までは分かりません。
送信側の設定が消えたのか、機器そのものが停止したのか、経路のどこかで遮断されているのか。そこは人間が切り分けることになります。
それでも、気づけるかどうかは大きな違いです。3日後にインシデント対応で気づくのと、15分後に監視画面が赤くなるのとでは、打てる手がまったく変わってきます。
まとめ
「ログが取れていなかったら分かる方法はないか」というご質問に対して、EasyBlocks 監視から外側で監視する形で答えを作ってみました。
作ってみて改めて思ったのは、閾値の設計が本題だったということです。プラグイン自体はAPIを叩いて件数を見るだけですが、何分の沈黙を異常とみなすかは、対象を実際に測ってみないと決められませんでした。
ログを集める仕組みは導入して終わりではなく、集まり続けていることを確かめる仕組みまでを含めて運用なのだと思います。
今後もEasyBlocksシリーズとAIを組み合わせた検証があれば、引き続き記事でご紹介していきます。