はじめてのログレベル：何を書き出し、どう扱うのか考えてみた

どうも。キャッチアップの渕上です。こんにちはこんにちは！

今回の題材は「ログレベル」です。
キャッチアップでは、日々、Webシステムを開発し、そして運用しています。
その中でログは、開発中も、開発が終わり運用フェーズに移ったあとでも、様々な場面で重要なお役立ち情報になってきます。
ということで、日々のお役立ち情報として、ログレベルについて整理してみたいと思います。

なお、この記事はキャッチアップでは毎週水曜、社内勉強会を行ってまして、そのときに発表した内容のウケが良かったので、改めて書き起こした内容です。
（ウケたよね？）

なにはともあれ、まずは積極的にログを出力したら良いよね、と行きたいところなのですが、せっかくなので、どのようなログ出力をしたら良いか、そしてどのようにログレベルを設定すると良いか。を整理してみたいと思います。

目的は、「どのレベルのログを、どう扱えばいいのか」を見える化することです。

この5つをまず押さえておけば、どの場面で、どのようなログ出力をしたら良いか、の方針として役立てることができます。

この記事を書くにあたって、改めてログの歴史を調べ直してみました。
https://ja.wikipedia.org/wiki/Syslog#%E6%AD%B4%E5%8F%B2

• syslogは、もともと1980年ごろにSendmailのログ記録のために生まれた仕組み
• 以降、他のアプリケーションでも採用されるようになり、現在ではUnix系システムの標準的なログ記録方式となっている
• その他のOSでも実装されており、ルータなどのネットワーク機器にもよく搭載されている

ログ記録システムとして、以下のようなログレベルが定義されており、これが現在のWebシステムのログレベル設計にも強く影響を与えているようです。
「emerg, alert, crit, err, warning, notice, info, debug」

ログレベルの概念が syslog から広がっていったことを紹介しましたが、実際にこのログレベルの考え方がどう使われているのか、身近な例を見てみましょう。
たとえば、Webサーバーである Apache ではどうなっているでしょうか？
Webサーバーとして多くの現場で使われている Apache にも、ログレベルの設定があります。
Apacheでは、ログの出力量をコントロールするために、「LogLevel」ディレクティブ を使って出力レベルの閾値を指定します。

例えば、次のような設定です。

LogLevel warn

このように設定することで、warnよりも重大なレベル（たとえば error や crit など）のログが出力されるようになります。
指定したレベル以上の重要度を持つログのみを対象としてログに記録する仕組みです。

このような設定は、ログが多くなりがちな本番環境での運用では特に重要です。
たとえば、debug や info などを本番でも出力してしまうと、ディスク容量やログ転送の負荷が高まり、逆に 本当に必要なログが埋もれてしまう 可能性があります。
そのため、実運用では warn や error といったレベルに抑えて、必要な情報を見逃さず、かつノイズになり得る内容は減らすようにする、という運用が多いのではないでしょうか。

詳細は公式ドキュメントにも掲載されています。
👉 Apache公式ドキュメント LogLevel

ApacheのようなWebサーバーでも活用されているログレベルは、アプリケーション側でも同様にログレベルの考え方を取り入れることができます。
ということで、私たちがよく使っているCakePHPのログレベルについても見てみました。

CakePHPでもログレベルは定義されていて、CakePHP5系のドキュメントには以下のように載ってます。
CakePHPの詳細はこちらです。
👉 https://book.cakephp.org/5/ja/core-libraries/logging.html#logging-levels

いかがでしょうか。

こうして並べてみてみると、非常に似通ったログレベルの定義となっていることがわかります。
つまり、ログレベルの考え方は、Webサーバーからアプリケーションまで、非常に似通ったものであることがわかります。

それでは、このログレベルの考え方を、実際にどのように使い分けているのか、見てみましょう。

これまでの流れを踏まえてようやく、冒頭で紹介した「ログレベルの基本セット」が元になります。
ここでは、私が日々の開発や運用の中で意識している目安を紹介します。

• ALERT
  • サービスの提供継続が困難になるレベルの致命的な障害に使います。たとえば、データベース接続の喪失やディスクフルなどが該当します。
• ERROR
  • 明らかに処理が失敗しているケースに使います。監視ツールの通知のトリガーとしての利用に用います。
• WARNING
  • 即座に問題が起きるわけではないけれど、放っておくと不具合に繋がりそうな兆候を捉えるために使います。メモリ使用率の高騰、APIのリトライ回数増加などが該当します。
• NOTICE や INFO
  • ユーザー操作やバッチ処理の開始・終了など、「正常だけど記録しておきたい」ものに使います。あとから「何が起きていたか」を辿るための材料になるログです。
• DEBUG
  • 主に開発中に使うログです。本番環境では基本的に出力しません。たとえば、リクエストパラメータの中身や処理の流れなど、トラブル調査や確認のために一時的に仕込むようなログがこれにあたります。

このようにして、ログレベルごとに「誰のための情報か」「どのくらい緊急性があるか」を意識することで、ログを「あとから役立つ情報資産」として活かせるように努めています。

はい、まとめです。

ログレベルの基本的な種類とその意味、Webサーバーやアプリケーションにおける実例、そして実務での使い分け方について紹介してきました。

普段あまり意識せずに出しているログも、ログレベルを考慮するだけで、後々の運用・保守・トラブルシュートに役立つ場面が出てくるかもしれません。
開発の途中でも、本番運用中でも、「このログ、誰にとって、どれくらい重要なんだろう？」と考えてみるきっかけになればいいなぁ、と思ったりしてます。

ということで、今回は「あとで読むための資産」という観点からのログレベルの話でした。
（･∀･）＜ ログの設計、やってみませんか

現場からは以上です。