朝8時15分、リモートワーク前に一杯のコーヒーを飲もうとデスクの上にカップを置こうとした瞬間、普段この時間には鳴るはずのない会社用スマホの呼び出し音が……。
急いで電話を取ると、相手は先日ネットワークの構築を行ったお客様のMさん。何とネットワークが全断して動かなくなったとの内容でした。
一瞬ドキリとしつつ、落ち着いて現地状況を確認したものの、その時点では原因は分からず。
急ぎ Meraki Cloud のダッシュボードを開いて確認してみると、ネットワークが落ちた時間は昨夜の 21時2分。そして、障害が発生しているのはおそらく コアSW（L3SW） ではないか、というところまでは見えたものの、そこから先の決め手がなく、原因ははっきりしませんでした。
そんな状況の中、Mさんから「コアSW（L3SW）を、手持ちの通常のL2SWに差し替えてみてもよいか」と提案がありました。
今回、障害発生の可能性があるL3SWは、実は特にルーティングやVLAN分けなどは行っておらず、L2レベルの通信でしか使っていませんでした。
そのため、Mさんの提案通り差し替えたところ、通信速度はやや落ちたものの、何とか復旧。急場しのぎではありますが、無事に使える状態には戻りました。
障害発生の原因は明確ではありませんが、機器の電源ランプや作動音がしていないことから、恐らく電気的な故障ではないかと考えられます。
ひとまず業務を止めないことを優先しつつ、機器交換の依頼をMさんからベンダーへ出してもらうことになりました。
朝からかなりバタバタした一日でしたが、CCNAの学習はいつも通り進めます。
しかも本日からは、今回の事象にもかなり関連のある Syslog の学習です。
Syslog とは何か
Syslog は、機器の出来事を記録するためのログの仕組みです。
ネットワーク機器では、インターフェースの up/down、設定変更、エラー、警告、障害の発生など、いろいろな出来事が発生します。Syslog は、それらを記録して、あとから確認しやすくするための基本的な仕組みです。
なぜ Syslog を使うのか
Syslog を使う目的は、主に次の3つです。
- 障害調査
- 運用監視
- 変更追跡
Cisco の資料でも、Syslog は 通常のトラブルシュート、インシデント対応、運用管理 に役立つと説明されています。
今回のように「昨夜の21時2分に何かが起きていた」という情報が見えるだけでも、調査の出発点としてかなり助かります。
もしログがまったく残っていなければ、いつ・どこで・何が起きたのかを追うこと自体が難しくなります。
Severity とは何か
Syslog でまず大事なのが severity です。
severity は、そのメッセージがどれくらい深刻かを表すものです。
Syslog の severity は 0〜7 の8段階で整理されていて、0 が最も深刻、7 が最も軽いという並びになっています。
つまり、
- 数字が小さいほど深刻
- 数字が大きいほど情報レベルに近い
と考えると分かりやすいです。
Severity level の基本
今回のキャプチャでは、severity level が次のように整理されています。
この一覧は、初心者のうちはかなり覚えやすいと思います。
特に大事なのは、**「0 に近いほど深刻」**という感覚です。
Facility とは何か
もう1つの基本が facility です。
facility は、そのログがどこから出てきたものか、どの種類の機能・プロセスに関するものかを表す分類です。
難しく考えすぎず、まずは
Severity = 深刻度
Facility = 発生元の分類
と整理しておけば十分です。
NTP が大事になる理由
Syslog を考えるうえで、NTP はかなり大事です。
なぜなら、ログは時刻がそろっていて初めて意味を持ちやすいからです。
たとえば、ある機器のログでは 21:02 に障害、別の機器では 20:57 に復旧、と記録されていたとしても、時刻がずれていたら正しい前後関係が分かりません。
そのため、NTP は Syslog の時刻整合性の土台と言えます。
今回の実体験でも、「昨夜の21時2分にネットワークが落ちた」という時刻情報が見えたからこそ、状況を追いやすくなりました。
逆に言えば、時刻がずれていると、せっかくログがあっても調査しづらくなってしまいます。
今回のまとめ
今回は Syslog の入口として、
- Syslog = 機器の出来事を記録するログの仕組み
- 目的 = 障害調査 / 運用監視 / 変更追跡
- Severity = 深刻度
- Facility = 発生元の分類
- Severity は 0〜7
- 数字が小さいほど深刻
- NTP は Syslog の時刻整合性の土台
という基本を整理しました。
今回のような障害対応を考えても、Syslog は「あとで見るログ」ではなく、原因調査の出発点になる大事な情報だと改めて感じます。
次回は、実際に Syslog の設定や確認コマンド を見ながら、もう少し具体的に整理していくと理解が深まりそうです。
コメント