◆ コンソール接続で出力されるログ
グローバルコンフィグモードから、特権EXECモードへの移行時に出力されるリアルタイムのログや、
システムエラー発生時に出力されるリアルタイムのログはデフォルトではコンソールにのみ送信します。

上図を例に考えてみましょう。例えば、下図のR1はコンソール接続されたCiscoデバイスなので、R1でexit
コマンドで特権EXECモードに戻った場合、システムログメッセージがコンソールに送信されて出力されます。
【 画面 1 】

それでは次に、管理者AさんがR1からtelnet接続でR2にログインしたとします。先と同じようにR2でexit
コマンドで特権EXECモードに戻っても、今度は何もログが出力されません。これはtelnet接続だからです。
【 画面 2 】

次に、以下も理解しましょう。コンソール接続した状態のR1でインターフェース(FastEthernet 1)
をdownさせます。当然ながら、この結果はR1のコンソール画面でログが出力されることになります。

【 画面 3 】

それでは以下の場合はどうでしょうか。コンソール接続したR1からR2にtelnet接続を行います。CLIの画面は
R2のtelnet接続された画面となります。この状態で先と同様にR1でインターフェースをdownさせます。結果
その内容がR2のtelnet画面上で表示されます。R2のCLI画面であるにも関わらず、R1のログが表示されるのは
そもそもR1にコンソール接続しているからです。そして、そこからR2にtelnet接続しているからです。これを
理解していないと R2 のインターフェースがdownしてしまったと勘違いし障害ではないかと焦ってしまいます。
【 画面 4 】

これさえ知っておけば、R2をtelnet接続で操作していて何かメッセージが出力されても慌てなくて済みます。
このメッセージは、現在操作しているR2で発生したメッセージではなく、コンソール接続されたR1から発生
したものであると落ち着いて静観できます。
◆ telnet接続でもメッセージを表示させる ( = terminal monitor )
telnet接続している状態では、telnet接続先の機器で発生するシステムログメッセージを見ることができない
のは、先に紹介した「画面 2」の通りです。例えば、このルータで設定変更を実施している場合に問題となる
ログが発生していてもリアルタイムには確認できないので、問題発生時の検知が遅れる可能性があります。
そこで以下のように、telnet接続先の機器でterminal monitorと入力すれば、telnet接続先の機器においても
コンソール接続しているのと同じようにシステムログメッセージをリアルタイムに出力されるようになります。

◆ ログメッセージのタイムスタンプ表示の設定
システムログメッセージやデバッグメッセージの表示ログの最初には、日付と時刻が表示されるパターン、
または起動時間が表示されるパターンがありますが、これはservice timestampsコマンドが影響しています。
以下のとおり、service timestamps log uptimeと設定した場合、Ciscoデバイスが起動してからの経過時間を
システムログメッセージの表示の最初にスタンプします。以下は起動してから3時間42分30秒だと分かります。

一方で以下の通り、service timestamps log datetimeと設定した場合、このシステムログメッセージが発生
した時間を「月/日/時/分/秒」の順番でシステムログメッセージに表示されます。Cisco機器が起動してから
の経過時間のログよりも、以下のとおり、いつ、そのログが発生したのかを正確に知るためには、以下の設定
の方が望ましいこと分かると思います。従って、一般的には「datetime」で設定することが推奨されています。

この datetime 設定コマンドの後には、オプションとして「msec、localtime、show-timezone」という値が
あります。ログメッセージをミリ秒まで表示させるには「msec」、機器本体のローカルタイムゾーンを時刻に
反映させるためには「localtime」、タイムゾーンを表示させるためには「show-timezone」を入力します。
内容から考えると、これらの全てのオプション値を入力した方がより正確にログに対してタイムスタンプできる
ことが分かります。という訳で当方が設定する timestamps の設定は基本的に以下のコンフィグとしています。

今回はservice timestamps logコマンドを紹介しましたが、これらの考え方やパラメータ値については、
デバッグメッセージを表示させる際のタイムスタンプである service timestamps debug コマンドにも
該当します。従って、service timestamps debug datetime msec localtime show-timezone
とします。
ところで、タイムスタンプに右側にある「%SYS-5-CONFIG_I」の“5”というのは、ログの緊急度レベルを
表すのですが、レベルについては以下のとおり0〜7まであります。重大度の高いものほど若い番号です。
「%SYS-5-CONFIG_I」のメッセージは、コンフィグレーションモードから特権EXECモードに移行する際に
発生するログなので、レベルは5で「問題ありませんが設定変更が発生しているのでは?」と出力されます。
levelキーワード |
レベル |
説明 |
emergencies |
0 |
システムが不安定 |
alerts |
1 |
直ちに対処が必要な状態 |
critical |
2 |
クリティカルな状態 |
errors |
3 |
エラー |
warnings |
4 |
警告 |
notifications |
5 |
正常だが注意を要する状態 |
informational |
6 |
通知メッセージ |
debugging |
7 |
デバッグメッセージ |
|