show logging / Device Logs

このページのゴール

装置内部に記録されたシステムメッセージをshow loggingで確認し、発生した出来事、重大度、時刻、記録順序を読み取れるようにします。

ログを見るときに重要なのは、

ログに何が記録されたか
↓
いつ記録されたか
↓
どの程度の重大度か
↓
記録条件に制約がないか
↓
現在の状態と一致しているか

という順序で確認することです。

ログは障害発生前後の状態変化を知るための重要な証拠ですが、1つのログだけで根本原因を確定するものではありません。

このページで学ぶこと

• show loggingを選ぶ場面
• Ciscoのシステムメッセージの基本構造
• 発生元カテゴリ、重大度、識別名の意味
• 重大度0〜7の方向
• タイムスタンプの有無を確認する方法
• 稼働時間形式形式と日時形式形式の違い
• シーケンス番号の使い方
• 装置時刻の信頼性を確認する理由
• logging bufferedとバッファ条件
• 重大度フィルタがログ不在へ与える影響
• 過去イベントと現在状態を分ける考え方
• ログと現在のshow出力を相関する方法

最初にshow loggingを選ぶ

装置内部に保持されたシステムメッセージを確認したい場合、基本となるコマンドは、

show logging

です。

現在のインターフェース状態だけでなく、

少し前にリンクが落ちた
設定変更後に状態が変わった
再起動後に異常が出た
一時的な障害が発生した

といった過去の出来事を確認したい場合に役立ちます。

show loggingは現在設定だけを見るコマンドではない

たとえば、

show running-config | include logging

はロギング設定を確認するための方法です。

一方、

show logging

は装置に記録されているシステムメッセージを確認するために使います。

確認したいものが、

ロギング設定

なのか、

記録されたイベント

なのかを分けます。

インターフェースダウンの発生時刻付近を確認する

症状：

1時間前にインターフェースがダウンしたらしい

確認候補：

show logging

ログから、

リンク状態変化
回線プロトコル状態変化
設定関連イベント
再起動関連イベント

など、発生時刻付近の記録を探します。

現在状態だけでは過去の一時障害が見えないことがある

現在：

インターフェース
→ up

回線プロトコル
→ up

でも、過去に一時的なダウンが発生していた可能性があります。

その場合、現在のshow interfacesだけでは、

今はup/up

という状態しか分かりません。

過去の状態変化を確認するためにログを利用します。

システムメッセージの基本構造

Cisco IOS系のシステムメッセージは、正式には次の構造で表されます。

%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: Message-text

SUBFACILITYが表示されないメッセージもあります。その場合は、次のように見えます。

%FACILITY-SEVERITY-MNEMONIC: Message-text

例：

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

この1行をまとめて眺めるのではなく、表示されている構成要素へ分けます。

発生元カテゴリはメッセージの発生元カテゴリ

例：

%LINK-3-UPDOWN

の、

LINK

が発生元カテゴリです。

発生元カテゴリは、どの機能やサブシステムに関係するメッセージかを判断する手掛かりになります。

SUBFACILITYは追加の分類情報

一部のシステムメッセージでは、発生元カテゴリの後ろにSUBFACILITYが付きます。

%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: Message-text

SUBFACILITYは、発生元カテゴリ内をさらに分類するための情報です。

ただし、すべてのメッセージに表示されるわけではありません。

%LINK-3-UPDOWN

のようにSUBFACILITYがない形式もあります。

重大度は重大度

例：

%LINK-3-UPDOWN

の、

3

が重大度です。

重大度はシステムメッセージの重大度を示します。

識別名はメッセージ種別の識別子

例：

%LINK-3-UPDOWN

の、

UPDOWN

が識別名です。

識別名は、

どの種類のイベントか

を識別する手掛かりです。

message-textは具体的な内容

例：

Interface GigabitEthernet0/1, changed state to down

の部分が具体的なメッセージ本文です。

ここから、

対象インターフェース
状態変化
変更後の状態

などを読み取ります。

発生元カテゴリと重大度と識別名を一括で読まない

例：

%LINK-3-UPDOWN

を、

LINK-3-UPDOWNという1つの名前

として暗記するのではなく、

発生元カテゴリ
→ LINK

重大度
→ 3

識別名
→ UPDOWN

と分けて読みます。

重大度は0から7まで

Syslogの重大度は0〜7で表します。

0
1
2
3
4
5
6
7

重要なのは、数値の方向を正しく理解することです。

重大度は数値が小さいほど重大度が高い

基本方向：

0
↓
最も重大

7
↓
最も低い重大度

したがって、

重大度 2

と、

重大度 6

を比べる場合、一般に重大度 2の方が重大度は高くなります。

重大度 0が最も重大

重大度 0は最も高い重大度です。

試験では、

7が最も重大

と逆に覚えないことが重要です。

重大度 7が最も低い

重大度 7は0〜7の中で最も低い重大度です。

数値が大きい
=
重大度が高い

ではありません。

重大度の代表名称

一般的な重大度名称は次のとおりです。

0 emergency
1 alert
2 critical
3 error
4 warning
5 notification
6 informational
7 debugging

一方、logging bufferedなどのCisco IOSコマンドでは、次のキーワードを使います。

emergencies
alerts
critical
errors
warnings
notifications
informational
debugging

たとえば一般名称のwarningに対応するコマンドキーワードはwarningsです。

試験では特に、

数値が小さいほど重大度が高い

という方向を確実に判断できるようにします。

重大度番号だけで原因を決めない

例：

%LINK-3-UPDOWN

を見ても、

重大度 3
→ ケーブル断確定

とは判断しません。

重大度は重大度であり、物理原因そのものを表す番号ではありません。

識別名だけで原因を決めない

UPDOWNという識別名から、

状態変化が起きた

ことは読み取れます。

しかし、

ケーブル不良
トランシーバ故障
対向装置停止
管理操作

のどれが原因かは、ログ1行だけでは確定できません。

ログはイベントを示す

ログから直接確認しやすいのは、

何らかのイベントが記録された

という事実です。

根本原因を確定するには、

現在状態
設定状態
インターフェースカウンタ
他の関連ログ

などと相関します。

タイムスタンプの有無を確認する

ログを見るときは、メッセージ本文だけでなくタイムスタンプが付いているか確認します。

例：

00:35:14: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

または、

Sep 24 12:35:14.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

のような形式があります。

タイムスタンプがないログもある

例：

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

この場合、

メッセージ内容

は確認できますが、

絶対時刻

をその出力だけから判断できません。

タイムスタンプなしをログ破損と決めない

タイムスタンプがないからといって、

ログ破損

とは限りません。

タイムスタンプ表示の設定条件によって、時刻が付かない場合があります。

タイムスタンプなしをイベント未発生と決めない

メッセージ自体が存在するなら、イベント記録は存在します。

タイムスタンプがないことと、

イベントが発生していない

ことは別です。

タイムスタンプがないと絶対時刻比較に制約がある

複数ログを、

12:00
12:05
12:10

のような絶対時刻で並べたい場合、タイムスタンプが必要です。

タイムスタンプがなければ、

いつ発生したか

の比較に追加情報が必要です。

稼働時間形式形式のタイムスタンプ

例：

00:35:14: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

このような表示が装置起動後経過時間として使われている場合、カレンダー日時とは意味が異なります。

稼働時間形式は絶対日時ではない

稼働時間形式形式では、

00:35:14

を、

今日の00時35分14秒

と決めつけません。

装置起動後の相対時間として扱います。

稼働時間形式は再起動の影響を受ける

装置が再起動すると、起動後経過時間は新しい起点から始まります。

したがって、異なる起動期間の稼働時間形式値を単純に連続した絶対時刻として扱わないことが重要です。

日時形式形式のタイムスタンプ

例：

Sep 24 12:35:14.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

日時形式形式では、装置時刻に基づく日時を使います。

日時形式と稼働時間形式は意味が違う

比較：

稼働時間形式
→ 装置起動後の相対時間

日時形式
→ 装置時刻に基づく日時

この2つを同じ時間基準として扱いません。

タイムスタンプ形式を先に確認する

ログ比較前：

このタイムスタンプは稼働時間形式か
このタイムスタンプは日時形式か

を確認します。

同じ見た目の数字が並んでいても、時間基準が違えば解釈も変わります。

タイムスタンプ設定を確認する

Cisco IOS系では、ログタイムスタンプに関する設定として次のような形式があります。

service timestamps log uptime

または、

service timestamps log datetime

環境によって追加オプションが付く場合があります。

service timestamps log uptime

例：

service timestamps log uptime

この設定ではログタイムスタンプに稼働時間形式を使用します。

絶対日時ではなく、

装置起動後の経過時間

として読みます。

service timestamps log datetime

例：

service timestamps log datetime

この設定では装置時刻に基づく日時をログタイムスタンプとして使用します。

ただし、装置時刻自体が正しいことが重要です。

日時形式があっても装置時刻を無条件に信用しない

例：

Sep 24 12:35:14

と表示されていても、

装置時刻が30分ずれている

なら、外部の障害監視時刻と単純に一致させられません。

show clockで現在時刻を確認する

装置時刻を確認する代表コマンド：

show clock

例：

R1# show clock
12:40:21.123 JST Thu Sep 24 2026

ログの日時形式と外部時刻を照合する前に、装置時刻の妥当性を確認します。

複数装置のログ比較では装置時刻が重要

装置A：

12:00:05

装置B：

12:00:06

と表示されていても、

装置Aの装置時刻が5分進んでいる

なら、見た目の順序をそのままイベント順序として扱えません。

タイムゾーンも確認する

異なる装置間で日時形式を比較する場合、

装置時刻
タイムゾーン

の両方が重要です。

同じ実時刻でもタイムゾーン表記が違えば表示時刻は異なります。

装置時刻がずれていてもメッセージ内容は使える

装置時刻が不正確でも、

%LINK-3-UPDOWN

というイベント内容そのものが無効になるわけではありません。

区別するのは、

イベント内容

と、

外部時刻との正確な照合

です。

装置時刻ずれは絶対時刻比較の信頼性を下げる

装置時刻が大きくずれている場合、

イベント種別
状態変化

は利用できますが、

監視システムの12:05と完全一致

のような判断には注意が必要です。

シーケンス番号は記録順序の手掛かり

ログにシーケンス番号が付いている場合、メッセージの順序を確認する手掛かりになります。

例：

101: Sep 24 12:35:14.100: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
102: Sep 24 12:35:15.200: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

シーケンス番号は時刻ではない

例：

101
102

というシーケンス番号を、

1秒差

とは解釈しません。

シーケンス番号はメッセージ順序の手掛かりであり、実時刻差そのものではありません。

シーケンス番号の差を秒数へ変換しない

例：

シーケンス番号
→ 101

次のシーケンス番号
→ 105

だからといって、

4秒後

とは判断できません。

実時間差はタイムスタンプを確認します。

シーケンス番号はUNIXエポックではない

シーケンス番号を、

UNIXエポック秒

として扱いません。

番号と絶対時刻は別の情報です。

シーケンス番号設定の例

Cisco IOS系では、システムメッセージへシーケンス番号を付ける設定として、

service sequence-numbers

を利用できます。

ログを時系列に並べる補助情報として使います。

シーケンス番号とタイムスタンプを組み合わせる

理想的には、

シーケンス番号
タイムスタンプ
発生元カテゴリ
重大度
識別名
メッセージ本文

をまとめて読みます。

シーケンス番号は順序、タイムスタンプは時間、メッセージ本体はイベント内容を補います。

ログバッファは有限

装置内部のログバッファには容量があります。

大量のメッセージが継続すると、古いメッセージが保持され続けるとは限りません。

show loggingに過去イベントがない理由は1つではない

目的の過去メッセージが見つからない場合、

イベントが発生していない

だけを候補にしません。

ほかにも、

バッファ上書き
重大度フィルタ
ロギング設定
再起動
記録先の違い

などを確認します。

ログ不在はイベント未発生の証明ではない

ログに目的のメッセージが見つからなくても、

イベントは絶対に発生していない

とは断定できません。

ログ保持条件を確認する必要があります。

logging bufferedはバッファ記録条件に関係する

代表的な設定：

logging buffered

環境によってはバッファサイズや重大度指定を指定します。

例：

logging buffered 16384 warnings

この場合、バッファ容量や重大度条件がログ保持に影響します。

バッファサイズが小さいと古いログが失われやすい

大量のメッセージ：

新しいメッセージ
新しいメッセージ
新しいメッセージ
...

が発生し続けると、有限バッファでは古いメッセージが上書きされる可能性があります。

バッファ上書きをイベント未発生と混同しない

目的ログがないとき、

イベント未発生

と、

以前は記録されていたがバッファ上書きで残っていない

は区別します。

重大度フィルタは保存対象に影響する

ログバッファに重大度条件が設定されている場合、すべての重大度が同じように保存されるとは限りません。

目的イベントの重大度と、バッファの記録条件を照合します。

logging bufferedの重大度方向

例：

logging buffered warnings

のような重大度指定では、その設定がどの重大度を記録対象にするかを理解して確認します。

重大度は、

0が最も重大
7が最も低い

という方向です。

フィルタ条件を逆に解釈しない

重大度数値の大小を逆に覚えると、

どのメッセージが保存対象か

の判断も誤ります。

まず重大度方向を正しく理解します。

たとえば、

logging buffered warnings

では、warningsの重大度4を基準として、より重大な0〜4が対象になり、5〜7は対象外になります。

記録対象
→ 0 emergencies
→ 1 alerts
→ 2 critical
→ 3 errors
→ 4 warnings

対象外
→ 5 notifications
→ 6 informational
→ 7 debugging

数値が大きい方まで含むのではなく、指定した重大度と、それより重大な小さい数値側を含むと判断します。

show loggingではバッファ情報も確認する

show loggingでは環境に応じて、ログバッファの状態や記録メッセージを確認できます。

見る観点：

バッファに何が残っているか
記録条件はどうなっているか
目的時刻のメッセージが残っているか

です。

古いメッセージが見つからないときの基本手順

1. show loggingを確認する
2. タイムスタンプの有無を見る
3. バッファ条件を見る
4. 重大度フィルタを確認する
5. 再起動など保持条件を確認する
6. ログ不在だけでイベント未発生と断定しない

ログの現在性を意識する

ログは過去のイベント記録です。

現在：

インターフェース
→ アップ

過去ログ：

リンクダウン

という組み合わせは矛盾ではありません。

過去イベントと現在状態を分ける

例：

1時間前
→ インターフェースダウンログ

現在
→ up/up

この場合、

過去に一時的な状態変化があった
現在は復旧している

可能性があります。

現在up/upだから過去ログを否定しない

現在正常でも、過去の一時障害は存在し得ます。

今は正常
=
過去も正常だった

ではありません。

過去ログがあるから現在もダウンと決めない

逆に、

1時間前にダウンログあり

だけで、

現在もダウン

とは判断できません。

現在状態はshow interfacesなどで確認します。

ログと現在の確認出力を相関する

例：

show logging
↓
1時間前にリンクダウン

現在：

show interfaces GigabitEthernet0/1
↓
up/up

判断：

過去イベント
↓
現在は復旧

という関係を考えます。

ログとインターフェースカウンタを相関する

過去ログ：

リンクダウン

現在のshow interfaces：

CRC増加
input errors増加

なら、物理品質の問題仮説を追加で検証する価値があります。

ただし、ログだけでケーブル故障確定とはしません。

ログと設定状態を相関する

過去ログに状態変化があり、現在設定に、

shutdown

がある場合、管理操作や設定状態との関係を確認します。

逆に現在、

no shutdown

でも、過去に一時的に設定が変更されていた可能性は別途確認します。

発生元カテゴリが同じでも原因が同じとは限らない

同じ発生元カテゴリのメッセージが複数あっても、

発生対象
時刻
識別名
メッセージ本文

が違えば、イベント内容も異なる場合があります。

発生元カテゴリだけで同一原因と決めません。

重大度が同じでも原因が同じとは限らない

複数メッセージが、

重大度 3

だからといって、すべて同じ原因とは限りません。

重大度は重大度であり、原因識別子ではありません。

識別名が同じでも対象を確認する

同じ識別名でも、

GigabitEthernet0/1
GigabitEthernet0/2

のように対象が違う場合があります。

message-textまで確認します。

タイムスタンプが近いイベントをまとめて見る

障害時刻付近で、

リンクダウン
回線プロトコルダウン

など複数イベントが近接している場合、それぞれの順序と時刻を確認します。

ただし、時間的に近いだけで因果関係を確定しません。

シーケンス番号でメッセージ順を補強する

タイムスタンプ精度が粗い場合でも、シーケンス番号があれば、

どちらが先に記録されたか

を補助的に確認できます。

シーケンス番号の差を時間差として扱わないことが重要です。

ログの時系列は時刻品質と一緒に評価する

時系列を評価するときは、

タイムスタンプの有無
タイムスタンプ形式
装置時刻の正確性
タイムゾーン
シーケンス番号

をまとめて確認します。

シナリオ1：装置内部の過去イベントを確認する

目的：

装置内部に記録された過去イベントを見たい

選択：

show logging

です。

シナリオ2：インターフェースダウン時刻付近を調べる

症状：

12:30ごろに通信断があった

最初に、

show logging

で時刻付近のシステムメッセージを確認します。

現在状態だけでは過去の一時障害が見えない場合があります。

シナリオ3：%LINK-3-UPDOWNの3を読む

ログ：

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

分解：

発生元カテゴリ
→ LINK

重大度
→ 3

識別名
→ UPDOWN

したがって3は重大度です。

シナリオ4：識別名の役割を読む

ログ：

%LINK-3-UPDOWN

UPDOWNはメッセージ種別を識別する手掛かりです。

送信元MACアドレスやルーティングメトリックを示す値ではありません。

シナリオ5：重大度 2と6を比較する

重大度 2
重大度 6

比較：

2の方が重大度が高い

と判断します。

シナリオ6：重大度0〜7の方向を判断する

正しい方向：

0
→ 最も重大

7
→ 最も低い

です。

シナリオ7：タイムスタンプがない

ログ：

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

判断：

イベント記録あり
タイムスタンプなし
絶対時刻比較には追加情報が必要

です。

シナリオ8：タイムスタンプなしで複数ログを比較する

複数メッセージにタイムスタンプがなければ、

絶対時刻による比較

はその出力だけではできません。

シーケンス番号がある場合は順序の手掛かりにできますが、実時刻そのものではありません。

シナリオ9：00:35:14をカレンダー時刻と誤認しない

表示：

00:35:14

が稼働時間形式形式なら、

装置起動後35分14秒

のような相対時間として扱います。

カレンダー日時とは分けます。

シナリオ10：日時形式と稼働時間形式を比較する

日時形式
稼働時間形式

は時間基準が異なります。

値の見た目だけで同じ基準として比較しません。

シナリオ11：シーケンス番号 101と102

101
102

から、

102が101より後に記録された

という順序の手掛かりを得られます。

シナリオ12：シーケンス番号差を1秒と考えない

101
102

だからといって、

1秒差

ではありません。

実時刻差はタイムスタンプで確認します。

シナリオ13：2台の日時形式ログを比較する

装置Aと装置Bのログ時刻を比較する前に、

装置時刻
タイムゾーン

の信頼性を確認します。

表示が日時形式であるだけでは十分ではありません。

シナリオ14：装置時刻がずれている

装置時刻が大きくずれていても、

リンクダウン

などのイベント内容は利用できます。

ただし、外部監視時刻との絶対時刻照合には装置時刻ずれを考慮します。

シナリオ15：目的の過去メッセージがない

show loggingに目的メッセージが見つからない場合、

バッファ上書き
重大度フィルタ
ロギング条件
再起動

などを確認します。

イベント未発生と即断しません。

シナリオ16：ログバッファが小さい

大量ログが発生している場合、有限バッファでは、

古いメッセージ
↓
上書き

される可能性があります。

目的ログがない理由の1つとして考えます。

シナリオ17：リンクダウンだけでケーブル断と断定しない

ログ：

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

このログから、

リンク状態変化が記録された

ことは分かります。

しかし、

ケーブル断確定

とはしません。

シナリオ18：1時間前にダウン後アップ、現在up/up

過去：

Interface Down
Interface Up

現在：

up/up

判断：

過去イベントと現在状態を分けて相関する

です。

シナリオ19：リンクダウンと現在up/upを相関する

ログ：

リンクダウン

現在：

up/up

次に、

ログの時刻品質
前後イベント
現在のインターフェース詳細
エラーカウンタ
設定状態

を確認し、原因仮説を検証します。

よくある誤り

show clockだけでイベント内容まで分かると考える

show clockは装置時刻確認に使います。

過去イベント内容はshow loggingで確認します。

重大度 7を最も重大と考える

0が最も重大で、7が最も低い重大度です。

重大度番号を原因番号と考える

重大度は重大度であり、原因そのものではありません。

識別名だけで物理原因を確定する

識別名はメッセージ種別の手掛かりです。

根本原因は別の確認情報と相関します。

タイムスタンプなしをログ破損と考える

タイムスタンプ表示設定によっては時刻が付かない場合があります。

稼働時間形式をカレンダー日時と考える

稼働時間形式は装置起動後の相対時間です。

日時形式なら装置時刻確認不要と考える

日時形式は装置時刻に依存します。

装置時刻やタイムゾーンが不正確なら絶対時刻比較に注意します。

シーケンス番号差を秒差と考える

シーケンス番号は順序の手掛かりです。

時間差ではありません。

ログがなければイベント未発生と決める

バッファ上書きや重大度フィルタなど、保持条件を確認します。

リンクダウンがあればケーブル断と決める

ログは状態変化の証拠であり、根本原因の一意な証明ではありません。

過去ダウンログがあれば現在もダウンと考える

現在状態は現在のshow出力で確認します。

現在up/upなら過去障害もなかったと考える

一時障害が復旧している可能性があります。

問題での判断パターン

パターン1：装置内部のシステムメッセージを確認する

show logging

を選びます。

パターン2：インターフェースダウン時刻付近のイベントを確認する

過去イベント確認なので、

show logging

を選びます。

パターン3：%LINK-3-UPDOWNの3を問われる

重大度

です。

パターン4：識別名の目的を問われる

メッセージ種別を識別する手掛かり

です。

パターン5：重大度 2と6を比較する

2の方が重大度が高い

と判断します。

パターン6：重大度0〜7の方向

0
→ 最も重大

7
→ 最も低い

です。

パターン7：タイムスタンプがない

タイムスタンプ表示条件を確認する

と考えます。

ログ破損やイベント未発生とは断定しません。

パターン8：タイムスタンプなしで絶対時刻比較

その出力だけでは絶対時刻比較できない

と判断します。

パターン9：稼働時間形式形式

装置起動後の相対時間

として扱います。

パターン10：日時形式と稼働時間形式

時間基準が異なる

ことを区別します。

パターン11：シーケンス番号

メッセージ順序の手掛かり

として使います。

パターン12：シーケンス番号の差

実時刻差を直接示さない

と判断します。

パターン13：複数装置の日時形式ログ

装置時刻
タイムゾーン

の信頼性を確認します。

パターン14：装置時刻がずれている

イベント内容は利用できる
絶対時刻照合にはずれを考慮

と判断します。

パターン15：目的ログがない

バッファ
重大度フィルタ
ロギング条件

も確認します。

パターン16：小さいバッファと大量メッセージ

古いメッセージが上書きされた可能性

を考えます。

パターン17：リンクダウン

状態変化イベントは確認できる
根本原因は追加確認

と判断します。

パターン18：過去ダウン後アップ、現在up/up

過去イベント
現在状態

を分けて相関します。

パターン19：ログと現在状態の総合判断

タイムスタンプ品質
イベント内容
現在の確認出力

を相関して原因仮説を検証します。

ログ読解の基本手順

1. show loggingでメッセージを確認する
2. 発生元カテゴリを確認する
3. 重大度を確認する
4. 識別名を確認する
5. メッセージ本文で対象と状態変化を確認する
6. タイムスタンプの有無を見る
7. 稼働時間形式か日時形式かを確認する
8. シーケンス番号があれば順序確認に使う
9. 装置時刻とタイムゾーンの信頼性を確認する
10. バッファと重大度フィルタの影響を考える
11. ログ不在をイベント未発生と断定しない
12. 現在の確認出力と相関する

まとめ

show loggingは、装置内部に記録された過去イベントを確認する基本コマンドです。

システムメッセージは、正式には、

%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: Message-text

の構造で読みます。

SUBFACILITYが表示されない場合は、

%FACILITY-SEVERITY-MNEMONIC: Message-text

の形になります。

重大度は、

0
→ 最も重大

7
→ 最も低い

という方向です。

タイムスタンプでは、

稼働時間形式
日時形式

を区別し、日時形式でも装置時刻とタイムゾーンの信頼性を確認します。

シーケンス番号は、

メッセージ順序

の手掛かりであり、実時刻差ではありません。

目的ログがない場合も、

バッファ上書き
重大度フィルタ
ロギング条件

などを確認し、イベント未発生と即断しません。

最後に、

過去ログ
≠
現在状態

と理解し、ログのイベント内容と現在のshow出力を相関して原因仮説を検証します。