理想のエラーメッセージ

こんにちは、辻村です。今回は「理想のエラーメッセージ」というお題です。「エラーなのに理想って何?」と思った方、良ければ読んでみてください。技術的な内容ではありますが、コンピュータシステムが分からない方でも読んでいただける内容です。

あらためてエラーメッセージとは?

あらためて、エラーメッセージとはなんなのでしょう?今回は、この疑問からはじめて、エラーメッセージを見ているときに、私もあなたも経験したであろうちょっとイラッとした話、そして、エラーメッセージには何が含まれるべきなのかという観点から理想のエラーメッセージについてお話ししたいと思います。

エラメッセージとはなんなのでしょう？

エラーメッセージはコンピュータで作業をおこない、その結果、何かうまくいかなかったときに人間に見える形で表示あるいは記録されるメッセージです。システムの動きを記録したものは、システムログと言います。

古くは番号だけであった時代もあり、こちらは、エラーコードと呼ばれています。現代で有名なエラーコードは、サイトが見つからないときに帰ってくる　HTTP 404ではないでしょうか。

※今時、JSONとかでやり取りしたりしているでしょうが、それはまた別のお話。 

エラーメッセージを読んでいて困ること

エラーメッセージはコンピュータでの作業が何かうまくいかなかったときに表示されるので、内容を読み、適切な対処（自分でできなければ人にお願いする）が必要です。

「英語で書かれても分からねぇよ！」というのが筆頭かもしれませんが、それ以外に、他の方からお聞きした内容には以下のようなものがあります。

(1) 専門用語がよく分からない
(2) どこで起こっているか分からない
(3) 文章は明瞭だが意味が不明

さらに私個人の経験で言えば、以下のようなものがあります。

(4) 複数のシステムにまたがるときに、時計が合っていない
(5) 内容を読んでも細かさが足りず部位が特定できない
(6) 日付の書き方とかのフォーマットが違う

それぞれちょっと考えてみましょう。

(1) は改善の余地はあると思いますが、万人に分かる形でのエラーメッセージは難しいと思います。理由は、専門用語にはそれなりの定義があり、その定義に基づいて厳密に書く必要があるときがあるためです。専門用語が分からないとき、あるいは、内部構造を知らないと理解できないようなメッセージの時は、素直に専門家に任せるのが良いと思います。
（意外に思われるかもしれませんが、メーカーや代理店にいるエンジニアたちにも特定領域の細かいことをを問い合わせるための専門家というのがいます。）

(2) は二つのケースに分かれます。1つ目のケースはメッセージに場所が明示されていない場合。2つ目のケースはメッセージに示されている場所が分からない場合です。

1つ目は直接的な方法がないので、エラーの状況や他のメッセージから推測するしかありません。

2つ目は、エラーメッセージが示す場所のシステムでの位置づけが分からないと言うことで、内部構造を知らないことに起因します。例えば、IPアドレス 192.168.0.2 というコンピュータについての以下のメッセージは、それだけではあまり意味を持ちません。 testhost1 との192.168.0.2の関係性で意味がずいぶん変わってきます。

Aug 31 13:54:12 testhost1 statd[13583]: [ID 702911 daemon.notice] host 192.168.0.2 is not responding

極端な話、192.168.0.2 がシステムから切り離された直後のメッセージであれば、妥当かもしれないのです。

(3) は言い換えれば、「何」が起こっているのか分からないと言うことです。「なんかおかしいんですよね」という言葉でよく表されます。

(4) はシステム間で時計がずれていると時刻の差を考慮して状況を理解しなければいけないためです。同様に、国をまたがるようなシステムでは、タイムゾーンが問題になります。タイムゾーンは例えば、日本であれば日本標準時、アメリカであれば東部標準時間などがあります。

複数のシステムやインスタンスがある場合、時計のずれと時差を考慮しないと、調査する際に「いつ」の認識がおかしくなり、状況が把握できません。

さきに (6) に触れておきますが、同じOSの中でも作った人が違ったり、多のメーカーからOEMとかで、日付の書式が違うことがよくあります。個人的には割とイラッとするポイントです。（自動化すればいいんですけどね。）

// Oracle Solaris のシステムログ
Jul 4 02:41:34 ar1 genunix: [ID 540533 kern.notice] SunOS Release 5.11 Version 11.4.5.3.0 64-bit

//Oracle Solaris のシステムログ（デバッガで表示したとき）
> ::msgbuf -v
TIMESTAMP LOGCTL MESSAGE
2019 Aug 31 13:49:07 ffffa100098a7cc0 sd15 at ahci0: target f lun 0
2019 Aug 31 13:49:07 ffffa100098a7c00 sd15 is /pci@0,0/pci8086,2829@d/disk@f,0
2019 Aug 31 13:49:07 ffffa100098a7b40 /pci@0,0/pci8086,2829@d/disk@f,0 (sd15) online

「(5) 内容を読んでも細かさが足りず部位が特定できない」は多少 (2) に通じるところがありますが、こちらは、メッセージを見ても部位を示すメッセージの粒度が荒すぎて場所が特定できない例です。「ストレージが壊れました」と「ストレージ装置のX番目のトレーのY番目のSSDが壊れました」という情報は「粒度」が違います。最初の情報だけでは、Y番目のSSDの交換を検討できないように、メッセージに十分な情報がないパターンです。

エラーメッセージに関する研究

1940年代に最初のコンピュータが誕生して以来、80年近くの時間が流れています。エラーメッセージに何が含まれるべきかという議論がきっとあるのだろうと思い、簡単に探してみました。

エラーメッセージやシステムログとして記録されてメッセージをどう収集してどう保管するべきかという議論や、セキュリティの観点からログをどう活用するべきかという議論の論文は見つけられました。しかしながら、エラーメッセージ自身に何が含まれるべきかという議論は見つけられませんでした。
（※もしそのそのような論文をご存じなら教えて頂けたら幸いです。）

プロトコルや標準を作る際にはエラーメッセージやエラーコードを当然定義していますが、その要素は「その都度適切なものを用意する」ことを是としているように見え、べき論から書き下ろしたものではないように見えます。

理想のエラーメッセージ

私の考えでは、以下が必要だと思います。しかし、現実にはメッセージの要素として必ず含まれているとは限らないのが実態なのでしょう。

・いつ（時刻、タイムゾーン）で発生したか
・どこ（システムの部分）で発生したか
・なにが発生したか
・（そして理想としては）日本語で書いてある

「いつ」を把握するには、システムの状態を知る必要があります。切り離されたシステムの部分や追加されたという「構成情報」があれば、無駄な調査を減らせます。ですから、例えば、Ansibleや Puppetみたいな構成管理ツールは構成の「質」を担保するだけではなく、構成変更があったことを確実に記録してくれるので、使っていくのが良いかと思います。

「どこ」については、サーバーのどことか、ソフトウェアの一部分という情報以外に、そのソフトウェアとかハードウェアがシステムの中でどう言う役割を意味するのかという「メタ」な情報が必要です。
システム設計の時には、これはWebサーバー（あるいはインスタンス）であるとか、DBサーバーであるとかを考え、それぞれの連携を考えます。しかし、障害を解析する時にログを見ると、各ログはその機器やソフトウェアに閉じてしまっていて、他のシステムの部分（コンポーネント）との位置づけの情報が失われてしまっています。

私個人はこの「どこ」の決定打になるのは構成情報と構成変更の履歴であると思っています。何が何を内包するのかという集合の関係で表せるので、モレなくダブりなく構成情報を持っていれば、細かなことが分からなくても、「システムのどのあたりの障害」ということが表せます。詳細は専門家に任せるとしても、「おおざっぱ」に捉えられることで、調査の方向性を決める道具になると思います。

構成変更がおこなわれた際には、システムの全体に含まれるものが変わることになるので、単純比較してはいけません。

「なに」が発生したかについては、すべての情報を記載できない以上、以下のいずれかである必要があります。

・望む粒度で情報が記載されていること。
・望む粒度で情報が記載されていないのであれば、望む粒度での情報を取る方法が分かっていること。

一例ですが、ファイルを使っている人は、「書き込めた」とか「書き込めなかった」という情報で十分です。しかし、書き込めなかった原因を調査する人は、ファイルの権限の情報であったり、ロックの取得が可能であるかと言ったもっと小さい差な粒度での情報が必要です。

最後に

エラーメッセージに必要な要素はいつ、どこで、何が起こったかと言う情報が、適切な細かさで分かる必要があります。理想は受け取り手によって異なるレベルのログを提示できることでしょう。

しかしながら、ソフトウェアを書いている人と使っている人の間の圧倒的な情報量の差があるので、これは難しいかもしれません。

システムのエラーメッセージやログ、システムの構成は障害解析の要となることです。これからも少し純粋に検討できないか考えていこうと思います。