トップ > 技術 > JANOG57 NOCでログ班として活動していました

JANOG57 NOCでログ班として活動していました

技術 イベント

こんにちは。id:taiseiueです。 2/11~13に大阪で開催されていた、「JANOG57」にNOCとして参加していました。

私はサーバーチーム所属でログ班として、主にログの収集分析を担当していました。 この記事ではログ班の活動の様子を書いていきます。

構成

今回の構成は以下のような感じです。

ログの配送構成図

左側が受信形式、右側が配送先、中央がルーティングを行っている部分となります。

配送先にはGrafanaでアラートを発報したりダッシュボードを表示するためのGrafana Lokiに加え、OpenRoamingおよびeduroamを提供するにあたってのログ保存義務を全うするためにさくらのクラウドにあるさくらのログストレージに配送し、ログを保存しています。

また、Ciscoさまより提供いただいたSplunkにも配送することで、ログ分析を行いました。

様々なsyslog

今回、ログ配送にはGrafana Alloyを使用することにしました。 これは、promtailの後継として開発され、標準的な"整理された"syslog形式であるRFC5424を処理できます。また、ログのパースやラベル付けも可能です。

しかし、世間には様々なsyslogの形式があります。 今回のJANOGでは、以下のような形式のsyslogを受け取りました。

RFC3164: <PRI>TIMESTAMP HOSTNAME TAG: MSG
RFC5424: <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [STRUCTURED-DATA] MSG
YAMAHA: <PRI>MSG

RFC3164

RFC3164(BSD Syslog)は古くから存在するsyslogの形式です。 ネットワーク機器などでは、デフォルトでこれを送信するものが存在し、このためGrafana Alloyに直接送信させず、rsyslogで受け取りそれをrsyslogからGrafana Alloyに配送することで、RFC3164->RFC5424の変換を行いました。

具体的には、PRIの次のセクションに、TIMESTAMPが来るかVERSIONが来るかでsyslogの種類を識別し、正規表現の置換を使ってそれぞれを再配置していきました。

具体的には、以下のような処理を書いています。

janog57-noc/janog57-infra/ansible/roles/log/templates/rsyslog/20-generic.conf#L25-L38

YAMAHA形式

今回使用したYAMAHA製のルーターは、デフォルトではYAMAHA形式という独自のsyslog形式でログを送信するようでした。このため、こちらもrsyslogに一度送信し、YAMAHA->RFC5424の変換を行いました。

# YAMAHA形式(再掲)
<PRI>MSG

YAMAHA形式は、このようにVERSIONやTIMESTAMPがなくそのままメッセージセクションで始まるのが特徴です。このため、VERSIONもTIMESTAMPもない場合にYAMAHA形式として処理を行うようにしました。

具体的には、以下のような処理を書いています。

janog57-noc/janog57-infra/ansible/roles/log/templates/rsyslog/20-generic.conf#L39-L54

ログストレージ送信時のレート制限対策

次に、ログの送信先についてです。 先述の通り、今回はOpenRoamingおよびeduroamを提供するにあたってのログ保存義務を全うするためにさくらのクラウドにあるさくらのログストレージに配送していますが、さくらのログストレージには1000行/secのレート制限が存在します。 仮に5000台のクライアントが接続していて、同時にDHCP割り当てが起きた場合、余裕でレート制限に到達してしまう換算です。(このシナリオはDHCPサーバーの障害などで再割り当てを実行する必要があるときなどにありうる)

このため、一度ログをキューに保存し、1秒毎(実際には念のため1100ms)に1000行を上限にバッチ送信する作戦をとりました。キューは6000行設定しています。キューが溢れた分のログは破棄されます。

この値は負荷試験を実施して得ましたが、今考えると参加登録人数が6000人超で、ひとり2台(PC+スマホ)、1000行は処理できることを考えると、6000 * 2 -1000 = 11000、1万1000行程度は確保できるとよかったのかなと思います。

この部分は以下のコードのように定義しています。

janog57-noc/janog57-infra/ansible/roles/log/templates/alloy/config.alloy#L142-L172

ダッシュボード

前述の通りログのキューがあふれるとログの破棄が起きてしまい問題となるため、Grafana Alloyのメトリクスをscrape可能にし、メトリクス班のid:nekoy3さんがダッシュボードを作成してくださりました。

Grafana Alloyのダッシュボード

心配していたAlloyのキューですが、会期中は一度もあふれることなく、使用率も1%以下になっていました。

Alloyの送信キュー推移

定期的にスパイクしている箇所に朝が多いことから、接続時にDHCP割り当てなどのログが増加していることが推測できます。

障害対応フロー

ログが保存できていないことが発覚した場合、OpenRoamingとeduroamを復旧するまで停波してもらう必要があるため、ログ班では障害対応フローを策定しました。ちょっと長いですがこんな感じです。

#j57-noc-server で共有する > みんな

@channel ログで障害が発生中です。${その時点でわかっていることをここに書く}。

担当者は {障害対応フローへのリンク} を確認して対応にあたりましょう。

チームリーダー> @チームリーダー

ログ班> @ログ班

トリアージ > ログ班

各種状態確認

AlloyのGrafanaダッシュボード / Loki / さくらのログストレージ / Splunk (それぞれのリンク)

以下のどれか

  1. ログの受信ができていない

  2. ログの受信はできていて、Lokiとさくらのストレージのどちらにも送信できていない

    =>ログの収集が停止している

    eduroam,OpenRoamingを停波してもらう必要がある

  3. ログの受信はできていて、さくらのストレージまたはSplunkにログが送信できていない

    => ログの収集はできている

エスカレーション

eduroam,OpenRoamingを停波してもらう必要があるとき実施

全体周知

@channel サーバーチームのログ担当です。

ログが受信/保存できなくなっている疑いがあり対応中です。 この後ログの保存が必要なeduroamとOpenRoamingを停波していただきます。

会場: ${ここにスレッドのリンク}

APチーム

@channel サーバーチームのログ担当です。

ログが受信/保存できなくなっている疑いがあり、eduroamとOpenRoamingを一時的に停波していただきたいです。

会場: ${ここにスレッドのリンク}

告知 > 大人と相談

障害が起きはじめた時間を特定する

AlloyのGrafanaダッシュボード を見て決める

リーダーに続報を報告

復旧したら

eduroamとOpenRoamingを再開してもらう必要があるため、APチームに連絡する

会期後

logcliを使ってさくらのストレージに送れなかったログを調べる必要があるため、本番サーバーで下記コマンド実行

docker run --rm -it \
  --network monitoring_network
  -e LOKI_ADDR="http://loki:3100" \
  grafana/logcli:latest query '{job="syslog"}' --limit=0 --output=jsonl \
  --from="2026-02-09T00:00:00+09:00"  --to="2026-02-09T01:00:00+09:00"

開発環境改善

今回、Grafana Alloyとrsyslogの設定ファイルを書く機会が非常に多かったため、コードレビュー前に気付き、レビュー漏れをなくすためにCIとしてGitHubActions上で設定ファイルをdry-runするようにしました。

GrafanaAlloyはalloy validateという専用コマンドを、rsyslogは-N1という検証用のオプションを付けて実行しています。

最後に

チーム結成から会期中まで、学生リーダーのid:crashrtさんを始めチームのみなさんに非常にお世話になりました!特に最初の頃はAnsibleまったくわからんところから始まり、様々お手伝いしていただいたり沢山コードレビューをお願いしていました。 今回得た学びは今後のNOC活動にぜひ活かしていきたいと思います。