ウッドベック氏　ログに記録する情報は、多過ぎても少な過ぎても良くない。問題がない可能性のあることに関するアラートまで出すと、本当に対処が必要なときに対処すべきアラートに注意を払いにくくなる。

　アラートを出すか出さないかのラインを機械的にはじき出すことは難しい。適切に見極められるようになることは、われわれが常に目指している目標だ。最初からそれができる人はいない。注力して取り組み、基準を調整することが必要だ。

　ロギングに関しては、ログを整形して記録する「構造化ロギング」が有益であることが分かった。ログにコンテキスト（状況）など付加的な情報を追加できるからだ。ログを取る対象のイベントが発生したら、それはどのような条件下で、どのような状況だったかを知らなければいけない。そうした情報は、その際に起こった問題の究明と解決に役立つ可能性がある。構造化ロギングは、こうした調査とそれを踏まえた問題解決の助けになる。

ミスから学ぶ

――　ログを収集するときによくある間違いは何ですか。

ウッドベック氏　適切な事象をログに記録していないことだ。プログラムを開発するときは、どのような問題が起こり得るかを考えなければならない。例えばシステム内のファイルを操作するプログラムを開発するとしよう。保存領域がいっぱいになったら、このプログラムはどのような挙動をするだろうか。正しく運用していれば保存領域の不足は起こらないだろうが、こうした事態が発生する可能性もある。

　ネットワーク管理プログラムを開発する場合は、誰かがネットワークケーブルを抜いたらどうなるかを考えなければならない。この事態では、全ての接続がタイムアウト（一定時間以内に通信相手からの応答がないことによる切断）する。一定数のタイムアウトエラーが連続して発生した場合も、注意する必要がありそうだ。

　何を記録する必要があるのかを経験から学べることもある。問題が発生した際に適切なログを取れていなかったら、「そうか、この情報が必要だったのか」と気付ける。別のプログラムを開発する際に、同じ状況を想定して「このシナリオでは確実にログを取る必要がある」「ここでログの可視性を高める必要がある」と考えることができるようになる。

――　他にアドバイスはありますか。

ウッドベック氏　常に好奇心を持ち続けよう。いつでも実験しよう。HTTP通信をするクライアントアプリケーションを一から作ってみることをお勧めする。サーバとやりとりする機能について学んだり、あるいはサーバ側のアプリケーションも開発して、クライアントアプリケーションからアクセスしてみたりするとよい。実験して遊ぶだけで、多くのことを学べる。

　ライブラリ（プログラム部品群）を使わず、自力でソースコードを書くことが大事だ。そうしてGoで遊んでみよう。Goの標準ライブラリには豊富な機能があり、ソースコードを調べれば機能の仕組みが分かる。