syslog が届かない・受信できないときの確認手順【チェックリスト】

切り分けの順序 — 上流から下流へ

ログの流れは「機器（送信）→ ネットワーク（経路）→ サーバ（受信・保存・表示）」の一本道です。切り分けもこの順に、上流から下流へ確認していくのが最短です。途中を飛ばして受信側だけいじり続けるのが、最もよくある遠回りです。

一. 送信側を確認する

• 宛先 IP・ポートは正しいか —— タイプミス、別セグメントの旧サーバ宛のまま、といった単純ミスがまず疑われます。
• UDP／TCP の別は合っているか —— 機器は UDP で送っているのにサーバは TCP しか待っていない（またはその逆）という食い違い。
• 送信レベルが厳しすぎないか —— Error（3）以上のみ送る設定だと、平常時は「何も起きないから何も届かない」だけかもしれません。テスト中は Informational（6）まで緩めます。
• 設定は保存・反映されたか —— CLI 機器の保存忘れ、GUI 機器の「適用」押し忘れ。
• テストログを出せるか —— 管理画面へのログイン・ログアウトなど、確実にログが出る操作を意図的に行い、送信のきっかけを作ります。

二. 経路を確認する

• 途中のファイアウォール・ACL —— 機器とサーバの間に FW や L3 スイッチの ACL があるなら、udp/514（および使うなら tcp/514）が許可されているかを確認します。
• そもそも疎通はあるか —— サーバから機器へ ping、TCP を使うなら PowerShell の Test-NetConnection 機器IP -Port 514（※これは TCP の確認で、UDP の到達は確認できません）。
• UDP は「静かに」失われる —— UDP では経路で破棄されてもエラーが出ません。疑わしい場合、サーバ側でパケットキャプチャを取り、514 宛のパケットがサーバまで到達しているかを直接確かめるのが決定打になります。

三. 受信側を確認する

• サービスは動いているか —— syslog サーバのサービスが起動しているか。Windows なら「サービス」画面で確認します。
• 514 番を待ち受けているか —— コマンドプロンプトで次を実行し、514 の待ち受けが見えるか確認します。

  netstat -ano | findstr :514

• 514 番の競合はないか —— 過去に入れた別のログツールが 514 を掴んだままだと、後から入れたサーバは受信できません。上記 netstat の PID からプロセスを特定します。
• Windows ファイアウォールの受信規則 —— 514 の受信許可規則があるか。Yagura の MSI は規則を自動作成しますが、手動構築のサーバやセキュリティソフト併用時は要確認です。

四. 「届いているのに見えない」場合

パケットは届いているのに画面に出ない場合、検索条件（期間・ホスト・重要度）で絞れてしまっているか、メッセージ形式の問題が考えられます。規格から外れた形式のログを黙って捨てる実装だと、この段階の切り分けは困難になります。Yagura は解析に失敗したメッセージも原文のまま「解析失敗」の印付きで保存し、取りこぼしを発生箇所別カウンタで観測できるため、「届いたが解析できなかった」のか「そもそも届いていない」のかをシステム状態画面で区別できます。

再発に備える — 途絶の監視

一度直しても、機器交換や設定の巻き戻りで syslog は再び止まります。そして止まったことには、誰も気づきません。恒常対策として、重要な送信元は途絶検知のウォッチリスト（Yagura では opt-in、既定 24 時間の閾値）に登録し、受信が途絶えたら警告が上がるようにしておきましょう。「届かない」を調査から発見の対象へ変えるのが、このチェックリストの最終項です。