導入：「時刻」と「ログ」がズレると何が起きる？
ネットワーク障害が発生したとき、あなたはまず何をしますか？ほとんどのエンジニアは「ログを見る」と答えるはずです。でも、もしそのログのタイムスタンプが機器ごとにバラバラだったら？ルーターが「14:05:32」、スイッチが「14:03:15」、ファイアウォールが「14:07:01」――障害の前後関係を追おうにも、どの順番でイベントが起きたのかまるで分かりません。
これは決して他人事ではなく、NTP（Network Time Protocol）の設計が不十分な現場では日常的に起きている問題です。そしてSyslogの設計が甘ければ、ログ自体が散逸して調査すらできなくなります。
今回は「NTP」と「Syslog」をセットで取り上げ、設計の考え方から具体的な設定例、現場で使えるベストプラクティスまでまとめて解説します。
概念・仕組みの解説
NTPとは何か
NTPは、ネットワーク上の機器の時刻を同期させるプロトコルです。基準となる時計（NTPサーバ）から階層的に時刻を配信する仕組みで、この階層のことを「ストラタム（Stratum）」と呼びます。
ストラタムのイメージはこうです：
- Stratum 0：原子時計・GPSなど、究極の時刻源（直接ネットワークには繋がらない）
- Stratum 1：Stratum 0と直結したNTPサーバ（インターネット上の公開NTPサーバなど）
- Stratum 2：Stratum 1から同期するサーバ（社内NTPサーバなど）
- Stratum 3以降：社内機器やネットワーク機器がここに位置することが多い
ネットワーク機器はStratum 2〜3のサーバから時刻を受け取り、自分の時計を合わせます。精度は多少落ちますが、現場の運用には十分です。
Syslogとは何か
Syslogは、ネットワーク機器やサーバが出力するログメッセージを集中管理サーバ（Syslogサーバ）に送るための仕組みです。ログにはタイムスタンプ・重大度・メッセージ本文が含まれており、障害調査・セキュリティ監査・変更管理のいずれにも欠かせません。
Syslogの重大度（Severity Level）は0〜7の8段階で定義されています：
| レベル | 名称 | 意味 |
|---|---|---|
| 0 | Emergency | システムが使用不能 |
| 1 | Alert | 直ちに対処が必要 |
| 2 | Critical | 重大な状態 |
| 3 | Error | エラー状態 |
| 4 | Warning | 警告（要注意） |
| 5 | Notice | 正常だが注意が必要な事象 |
| 6 | Informational | 情報メッセージ |
| 7 | Debug | デバッグ情報 |
現場ではSeverity 6（Informational）以上を収集するのが一般的です。Debug（7）は膨大な量が出るため、トラブル時以外は収集しないのが鉄則です。
設定例・コマンド例
Cisco IOS / IOS-XE でのNTP設定
! NTPサーバを指定（複数指定で冗長化）
ntp server 203.0.113.1 prefer
ntp server 203.0.113.2
! タイムゾーンの設定（JST = UTC+9）
clock timezone JST 9
! NTP同期状態の確認
show ntp status
show ntp associations
Cisco IOS / IOS-XE でのSyslog設定
! Syslogサーバへ転送（Informational以上）
logging host 192.168.100.10
logging trap informational
! ログにタイムスタンプを付ける（必須！）
service timestamps log datetime msec localtime
! コンソール出力のレベルも設定
logging console warnings
! バッファにもログを保持（デバッグ用）
logging buffered 16384 debugging
Juniper Junos での設定例
# NTP設定
set system ntp server 203.0.113.1 prefer
set system ntp server 203.0.113.2
set system time-zone Asia/Tokyo
# Syslog設定
set system syslog host 192.168.100.10 any info
set system syslog host 192.168.100.10 explicit-priority
現場での活用・ベストプラクティス
NTP設計パターン：階層型＋冗長構成
現場でよく使われるパターンは、「社内に中間NTPサーバを立てて、そこから各ネットワーク機器が時刻同期する」という2段階構成です。ルーターやスイッチが直接インターネット上のNTPサーバに問い合わせると、セキュリティポリシーの問題やUDP 123番ポートのフィルタリングに引っかかることがあるためです。
- 社内NTPサーバは最低2台用意して冗長化する
- 機器側で
preferキーワードを使ってメインサーバを明示する - NTPの認証（MD5/SHA1）を使うと、なりすまし時刻配信を防げる（大規模環境では特に有効）
Syslog設計パターン：集中収集＋長期保管
Syslogは全機器のログを1か所に集約するのが基本です。個別の機器のCLIをひとつひとつ叩いて確認するのは、障害時には時間的ロスが大きすぎます。
- Syslogサーバにはrsyslogやsyslog-ngを使い、機器別・日付別にログをファイル分割する
- さらにELK Stack（Elasticsearch + Logstash + Kibana）やGrafana Lokiと連携して可視化・検索できると障害対応が格段に速くなります
- ログの保存期間は最低3か月、セキュリティ要件があれば1年以上を目安にしましょう
注意点・よくある落とし穴
タイムスタンプの設定を忘れる
Cisco機器はデフォルトでログにタイムスタンプが付かない設定になっています。service timestamps log datetime msecを入れていないと、「いつ起きたのか分からないログ」が大量に吐き出されることになります。これは設定の最初に必ず確認するクセをつけましょう。
NTPが同期できていないのに気づかない
NTPサーバを設定しても、ファイアウォールでUDP 123番がブロックされていたり、ルーティングが通っていなかったりして実は同期できていないケースが意外と多いです。設定後は必ずshow ntp statusで「Clock is synchronized」であることを確認してください。
SyslogをUDPのみで送っていてログが消える
Syslogの標準はUDPですが、UDPは到達保証がありません。ネットワーク輻輳時にログが消えてしまい、障害の証拠が残らないことがあります。重要な機器についてはTCP（ポート514 or 6514）を使ったSyslog転送も検討しましょう。
ローカルバッファだけに頼る
機器のメモリに保存されるローカルバッファは、リロードすると消えることを忘れないでください。「再起動したら原因の手がかりが消えていた」という事態を避けるためにも、必ず外部サーバへのSyslog転送を設定しておきましょう。
まとめ
NTPとSyslogは、地味に見えて現場の運用品質を大きく左右する設計要素です。時刻が揃っていなければログの相関分析ができず、ログが集中管理されていなければ障害対応のスピードが落ちます。
- NTP：社内中間サーバ経由の2段階構成＋冗長化、設定後は必ず同期確認
- Syslog：タイムスタンプ必須、集中収集サーバへUDP/TCP転送、長期保管の設計も忘れずに
どちらも「設定して終わり」ではなく、定期的に同期状態やログ収集の動作確認をする運用サイクルを回すことが大切です。ぜひ今日の現場から見直してみてください。
```