ログ設計で明確にすべき4つのポイント
サービス運用にログを活用するには、まずログ設計が重要になる。
「ざっくりログ設計といっても曖昧になるので、今回は次のポイントにしぼってお話します。ログの利用目的、ログの重要度、ログの出力形式、ログの保管先の4つです」
ログの利用目的は、このログを利用して何を実現したいかだ。Webサービスの場合は、安定的なサービス運用となるだろう。これを手に入れるために、ログを活用するのだ。
ログの重要度は対象システムやレイヤーによって異なるが、アプリケーション開発を例にすると次のようになる。例えば、FATALはサービスを継続できないような致命的なエラーをあらわし、WARNは動作には影響しないが気を付けたほうがよい動作の警告をあらわし、INFOが正常動作の出力情報をあらわすという具合だ。
「これらの情報をうまく使い分けることによって重要度を決めていきます。本来はWARNとして出力されなきゃいけない情報がERRORとして出力されたり、その逆もあったりすると運用上の妨げになることがあるので、ここはきちっと意識をしないといけないと思います」
ログの出力形式は、どのようなフォーマットで出力するかである。Webアプリケーションであれば、タイムスタンプや出力元の情報、ログの重要度をあらわすログレベルなどある程度の内容は決まっているだろう。
「通常は、スライドの青文字の部分で確認することが多いです。メソッドとURLでどういった処理が行われたかを確認して、レスポンスコードでその処理結果がどうだったかを確認します。異常が起こった場合には赤文字の部分を追加で確認します。どこからという情報は、IPやリファラーで確認し、何が起きたかを詳細にて確認します。詳細部分にはスタックトレースをそのまま出力することが多いです」
ログの保管先とは、単純にログファイルが出力される場所である。田中氏が運用するNJSSではECSを使用しているため、基本的にCloudWatchに出力される。またAWSのサービスから出力されるログに関してはS3に出力している。さらに、リクエストログの一部は、CloudWatchではなくBigQueryに出力するようにしてある。このBigQueryをデータウェアハウスとして使っていて、Google Analyticsの情報も出力している。最後に、アプリケーションで発生したログやリクエストログの一部はDatadogなどのイベントトラッキングサービスに連携している。
もう一つ大事なのが、出力するタイミングである。特にサービス運用として考えた場合にはエラーが重要になる。アプリケーションの不具合の可能性があるので、早急に対応が必要になるからだ。エラーではないが特定の条件に合致した場合も注目する必要がある。たとえば、バリデーションエラーやログイン認証の失敗、規約上の上限といった具合だ。また想定通りの挙動だがユーザーとしてうまく利用できてない状況を記録していく。こうした状況の発生頻度が多いようであれば、何かしら改善の余地がある可能性がある。
