syslog 転送設定忘れ『運用・監視の話③』
障害が起きていたが、解析しようにも その障害の手がかりがどこにも無い。
原因は syslog を外部へ転送していなかったこと。
単体保存のまま運用し、機器障害と同時に証跡を失う典型例だ。
冒頭の一言要約
ログは“残す場所”まで設計して初めて意味を持つ。
機器の中にだけあるログは、障害と一緒に消える。
症状（あるある）
再起動後にログが消えている
ネットワーク機器の履歴が追えない
誰が設定変更したか分からない
断続的な通信断の原因不明
メモリ不足でログローテーション消失
監査対応ができない
原因と仕組み（なぜ起きるか）
ローカル保存のみで運用
syslog サーバ未設定
転送先 IP 記載漏れ
UDP 514 の疎通未確認
保存容量の過信
機器障害＝ログ消失
多くの機器は
ログを長期保存する設計ではない。
つまり転送しないと、
トラブル発生時に証跡が残らない。
図：転送なしのログ消失
[ネットワーク機器]
│ ログ保存
▼
再起動/故障
↓
ログ消失
（外部保存なし）切り分け（最短コース）
syslog 設定確認
転送先 IP/ポート
疎通確認
UDP/TCP 514
サーバ側受信確認
受信ログの有無
ログレベル確認
出力レベルが適切か
再起動テスト
ログが残るか
今すぐ効く対処（テンプレ）
◆ 最低限の設定
外部 syslog サーバへ転送
重要機器は必ず二重保存
例（Linux）：
*.* @192.168.1.10※ あくまで例。環境に合わせて調整。
◆ 推奨運用
機器ログは中央管理
保存期間を明確化
恒久対策／再発防止チェックリスト
全機器で syslog 転送設定
受信確認を定期実施
保存期間の要件化
再起動時のログ残存確認
重要イベントの通知化
監査対象ログの整理
新規機器導入時の必須設定
「ローカル保存で十分」を禁止
落とし穴（やりがちミス）
構築直後に設定し忘れる
テストせず完了扱い
IP変更後に未更新
保存容量を過信
障害時に初めて確認
まとめ（行動指針）
ログは、
機器の中ではなく“外”に置くもの。
出す → 受ける → 残す。
この3点を押さえるだけで、
原因不明の障害は大きく減る。
