読書会「プログラマが知るべき97のこと」 #6

1．今回の読んだ記事

No.85　冗長なログは眠りを妨げる　
著者: Johannes Brodwall

2．記事の概要

重大な問題が起きているか、いないかを判断できるようなログの出し方をするとよい

• ログの情報が多すぎることは、ログを出力しないのと同じこと
• 「情報ログ」と「エラーログ」の出力場所を分け、記載があるかで判断
• 分散システムの場合、依存関係で発生する異常もあるので考慮が必要

3．この記事を選んだ理由・感想

理由
自分が担当するシステム以外のログの出力基準などを聞いてみたかったから。
アプリが正常に動くことだけでなく、サービス稼働後の運用面も加味してシステムを構築していかなければならないということを皆で再確認するため。

感想

• エラーログファイルを分けることについて
• 検知をする面でいえば、監視ツールが「ERROR」文字列を出力すれば検知して通知するなどの仕組みがあれば、やる必要無いように思った。
• 半面、単純にエラー調査する場合において、エラーログファイルだけを見るだけでよくなるという点では、ログファイルを分けることに価値があるかもしれない。

4．議論

各開発チームごとのログの出し方方針を語る

• Aチーム

  • ログが少なくて、「もう少し多く出力した方がよかった」と思ったことがあった。
    • スタートとエンドの記載しかなくて、遅延が発生した際にどこが遅くなっているのか判別がつかなかった
  • ただ、ログを出しすぎるとサイズが大きくなる

• Bチーム

  • 分散システムなので連携システムの遅延を検知するのに、外部連携時のスタート・エンドの記載は重要
    • エラーになるほどではないが、「通常より処理が遅いかもしれない」・・・という小さい異常などが起きた場合に気づくことができるから

• Cチーム

  • 24時間動くようなシステムではなく、アクセスもそれほど多くないので細かいことまで意識していない
  • ログをたくさん出すとディスクを圧迫することもあり、お客様からも嫌がられる可能性があるので極力少なめに出力する

ログに関する設計書についての議論

• 運用業務が専任の人に対して重要なのでしっかり作りたいが、記載レベルや運用などが難しい面もある
  • 人が書いたログを見ることが多いので感じることは、運用の観点で適切なログの記載レベルをを開発時にメンバーに共有するのが難しい
    • 運用してみて追加していくなどで対応している
    • 重要ななログを出すタイミングは設計書に定義して書くことはある程度認識があって実現できているが、メンバーの裁量によって不足がある。
    • （自分のシステムに関して言うと）運用に慣れていない人が設計した場合、全体的にログが少なめになってしまう傾向がある。
  • ログ専用の詳細設計書を作るのもいいが、ログを追加したり減らしたりしたときのメンテナンスが結構大変でうまく運用しきれていない
  • 自分で開発・運用しているので、試験を実施するときに追加していくようにしている

その他：組み込み系でのログ

• 1トランザクションでの操作をすべてログをメモリにためて、障害が発生したときだけすべて出力しておく方法だった
  • 機械の中で動くものなのでログファイルを貯められないから
  • へー、なるほど

まとめ

ログに関してはそれぞれに意見があって面白い。
そして、ログの話は結構盛り上がるということがわかった。議論時間が過ぎてもまだ話せそうな雰囲気。
ここら辺は、皆それぞれ言いたいことがあるのだと思う。
次回に続く。