原因を特定する手段は、さほど多くありません。
概要でも、触れましたが、ログの解析がほとんどです。
どのように解析するのかというと、各分野の文化を理解し、人の行動を想像する事になります。
たとえば、Windowsのイベントログは、下記の構成になっています。
- レベル
- 日付と時刻
- ソース
- イベントID
- タスクのカテゴリ
レベルは、エラー、警告、情報に分類され、イベントIDは、メッセージに紐づけるIDになります。海外システムを日本語化する最初の仕事はIDに紐づいた英語を日本語に訳す事です。
ついでに他の項目はというとソースは場所を表し、タスクのカテゴリはオンラインかバッチかを区別します。Linuxではどうでしょうか。
- 日付と時刻
- ホスト名
- ユーザ名
- （フリーフォーマット）
４．はフリーフォーマットですが、プログラム毎に決めて使用しているのが通例で、やはり、レベル、ソース、イベントIDまたは、メッセージという構成にしがちです。
形式が多少異なる事があっても、最低限伝えなくてはならない事は変わりません。
書く項目が一緒（文化）なのに、内容が違うものになってしまう（人の行動）。悲しい事と一概には言えません。文化は継承しつつ、より良いものにしていきたいという理由もあるからです。（障害解析は、いらいらいするものなので、人の良い面を考えつつ、冷静さを保たなければと思っています）
人の行動とは、周りに合わせる場合もあれば、我関せずで突き進む場合もあります。メッセージを見れば、人が変わったかどうかが見えてきます。あるいは、まったく理解できないメッセージは、忙しかったのかスキルがなかったのか、何れにせよ信用できない内容になります。
レベルが「情報」のメッセージがたくさん出るのは、自身がないのか、周りがコミュニケーションをとってくれないメンバーだったか。これも、連携の部分に問題がある可能性が高くなります。
こういうログの状況と障害が発生した時系列を照らし合わせていく作業がログ解析になります。もちろん、肝心の場所でログがでていない場合もあります。