ログ設計とは何か

ルーターやスイッチ、ファイアウォールなどの機器では、 稼働中にさまざまなイベントが発生します。

• インターフェースがDownした
• OSPFやBGPのネイバーが切断した
• VRRPなどの冗長状態が変化した
• 管理者がログインした
• ログイン認証に失敗した
• コンフィグが変更された
• VPNトンネルが切断した
• ファイアウォールで通信が拒否された
• 電源・ファン・温度などに異常が発生した

こうした情報が機器本体にしか残っていないと、 再起動やログの上書きによって必要な情報を失う可能性があります。

そのため実務では、 複数機器のログを中央のログサーバーなどへ転送し、 後から時系列で検索できる構成を検討します。

監視設計とログ設計の違い

監視とログは関連していますが、目的は同じではありません。

例：回線障害が発生した場合

このように、 監視情報とログを組み合わせることで障害の流れを時系列で再現できます。

ログ収集の全体構成

ログ設計では、まず 「どの機器から、どの経路を通って、どこへログを送るのか」を整理します。

ログ転送経路もネットワーク設計の一部

ログサーバーへ到達できなければログは転送できません。 そのため、次の項目も確認します。

• ログサーバーのIPアドレス
• 管理ネットワークからの到達性
• ログ送信時の送信元インターフェース
• 管理VRFを利用するか
• ファイアウォールで必要な通信が許可されているか
• ログ収集サーバーが複数ある場合の転送方式
• サーバー障害時にローカルログを保持できるか

どのログを収集するか

「全ログを保存する」と決めるのは簡単ですが、 ログ量・保存容量・検索負荷・運用コストが増えます。

反対に絞りすぎると、 障害発生時に必要な情報が残りません。

まず、ログを利用目的ごとに分類します。

「原因調査に必要か」で考える

収集対象を決めるときは、 「このログが出るから保存する」のではなく、 どのような障害・インシデントを調査するために必要なのか を考えます。

Syslog Severityをどう決めるか

Syslogでは、メッセージの重要度をSeverityで表します。

重要度が高いログだけでは足りない

「Error以上だけ保存すればよい」と考えると、 調査に必要なイベントを失う可能性があります。

たとえば、管理者のログインや設定変更は、 必ずしもCriticalやErrorとして記録されるとは限りません。

Debugを常時有効にしない

Debugログは詳細な情報を確認できる一方、 大量のメッセージが発生する場合があります。

そのため一般的には、 通常運用で常時取得するログと、 障害調査時に一時的に取得するDebugログを分けて考えます。

ログ設計では時刻同期が重要

複数機器のログを調査するとき、 時刻がずれているとイベントの順番を正しく判断できません。

例：実際の出来事

1. 10:00:01　回線がDown WANルーターで物理リンクが切断します。
2. 10:00:02　OSPFネイバーDown 隣接ルーターとのOSPFが切断します。
3. 10:00:04　経路が切り替わる バックアップ経路へ通信が切り替わります。
4. 10:00:10　監視システムが障害を検知 運用担当へアラートが通知されます。

この順番が分かれば、 「OSPF障害が原因ではなく、その前に発生した物理リンク障害が起点」 と判断できます。

しかし、機器ごとに時計が数分ずれていれば、 原因と結果を逆に判断する可能性があります。

時刻設計で決める項目

• 使用するNTPサーバー
• NTPサーバーの冗長化
• 各機器の参照先
• NTP通信の経路
• タイムゾーン
• ログ上の時刻表記
• NTP同期状態の監視方法

ログ保存期間をどう決めるか

ログ保存期間は、 「一般的には○日」と決めるのではなく、 何のためにそのログを利用するかから決めます。

保存期間を決める質問

• 障害発生から何日後まで調査する可能性があるか
• セキュリティ部門から保存期間の指定があるか
• 社内規程・顧客規程・監査要件があるか
• 機器ログと通信ログで保存期間を分けるか
• オンラインですぐ検索できる期間はどれだけ必要か
• 長期保管データを別ストレージへ移すか
• 保存容量・コストの上限はどの程度か

ログ容量を考える

保存期間だけ決めても、 ストレージ容量が足りなければログを保持できません。

基本的には次の流れで見積もります。

1. 機器ごとのログ発生量を確認する 平常時だけでなく、障害時や高負荷時の増加も確認します。
2. 対象機器数を確認する 現在だけでなく、将来追加される機器も考慮します。
3. 保存期間を掛け合わせる 日次のログ量と保存期間から必要容量を見積もります。
4. 余裕を確保する 障害時の急増、機器増設、索引情報などを考慮します。
5. 長期保存方式を検討する 必要に応じて短期検索領域と長期保管領域を分けます。

ログのセキュリティを設計する

ログには、ネットワーク構成・IPアドレス・利用者情報・通信履歴など、 運用上重要な情報が含まれる場合があります。

そのため、ログは「集めれば終わり」ではありません。

確認する項目

• 誰がログを閲覧できるか
• 誰がログを削除できるか
• 管理者権限をどこまで与えるか
• ログサーバーへの管理アクセス経路
• ログデータのバックアップ
• ログの改ざん・削除対策
• 機密情報をログへ記録してよいか
• ログ転送経路を保護する必要があるか

特に設定変更ログを重視する

ネットワーク障害では、 機器故障ではなく設定変更が原因になる場合もあります。

そのため可能であれば、 次の情報を追跡できる状態を目指します。

• 誰がログインしたか
• いつログインしたか
• どの機器へアクセスしたか
• 設定変更が行われたか
• 変更前後の設定を確認できるか

ログだけでなく、 AAAや設定バックアップ・Gitなどの設定管理と組み合わせると、 より追跡しやすくなります。

ログサーバー障害時も設計する

ログサーバー自体が停止する可能性も考えなければなりません。

たとえば、ネットワーク障害と同時にログサーバーへの経路も切断すると、 最も必要な障害発生中のログを失う可能性があります。

確認しておきたいポイント

ログ設計書には何を残すのか

ログ設計では、 後から別の担当者が見ても設定・試験・運用へ落とし込める形で パラメータを整理します。

機器単位だけでなくログ用途を残す

設計書へ単に 「Syslogサーバー：192.0.2.10」 とだけ記載しても、 その設計理由は分かりません。

次のように目的まで関連付けると、 レビューや運用引き継ぎがしやすくなります。

ログ設計では試験まで考える

設計したログが実際に取得できるかは、 構築後の試験で確認します。

代表的な試験項目

ログ設計でよくある失敗

顧客・上司へログ設計をどう説明するか

技術に詳しくない相手へ 「Syslog SeverityをInformationalまで取得します」 と説明しても、必要性は伝わりにくいでしょう。

ログ設計は、 障害対応時間・セキュリティ・監査リスク へ変換して説明します。

技術を業務影響へ変換する

ログ設計で使われる英語表現

よく使われる単語

設計・ヒアリングで使える表現

自分の言葉で説明する課題

後輩エンジニアから次のように質問されました。