運用を意識したログについて
はじめに
システムを運用する際は「ログ」はとても重要です。
これまでいくつものアプリケーションの保守・運用に関わってきましたが、必要なログが出力されていないことで苦労したことが多々ありました。
今回は開発者の方に向けて、運用観点でのアプリーションログについて触れたいと思います。
ログの用途について
まずはログの用途について触れたいと思います。
問い合わせ・障害発生時の調査
監査ログ
利用状況の確認
問題の前兆検知
これらの情報は非常に重要なもので、必要な内容が出力されていない・欠損した、などは重大なインシデントとして処理されこともあります。
運用における重要度を意識しておくとログに対する考え方も変わってくるのではないかなと思います。
出力項目について
一般的にはログには以下のような内容が必要になります。
この辺りは特に意識せずに出力されているのではないでしょうか。
ログレベルについて
運用ではログ監視でエラーレベルを利用することがあります。（ERRORというキーワードがある場合に、アラートを出すなど）
このため適切なログレベルが設定されていないと、運用時の負荷が増えることになります。
出力内容を統一するためにも、しっかりとログ設計をしておき、開発メンバーで共有しておくことをお勧めします。
参考までに、過去に関わったプロジェクトでのログ出力ルールの概要を提示します
上記はあくまで一つの例となるので、実際は開発するシステムに適した内容を定義してください
出力内容について
ログの出力内容もしっかりとルール・指針を決めておき、レビュー時のチェックポイントとして組み込んでおくと良いです。
そうすることで、必要な内容が出力されていない、などの問題を防ぐことに繋がります。
なお、出力する内容もそうですが、「出力しない（してはいけない）」内容についてもしっかりとルール化しておきましょう。
以下に私がログを出力する際に注意しているポイントを記載します。
エラー原因を特定するための情報を含める
通信エラーなどの場合は、エラー原因（タイムアウト・ステータス不正・レスポンスのフォーマット不正など）を出力しておきましょう。
期待値がある場合期待値と実際の値を出力する
入力チェックなどで期待と異なる場合、期待値と実際の値を出力しておくと障害解析が容易になるケースもあります。
処理の開始・完了・途中経過を出力する
バッチなどで複数の処理を繰り返す場合、開始・終了・途中経過を残しておくことで障害解析がやりやすくなります。
機密情報は出力しない or マスクしたものを出力する
以前パラメータをそのまま出力した結果機密情報も含まれていた、というケースがありました。機密情報の取り扱いには十分注意しましょう。
なお、デバッグレベルであっても、場合によっては本番環境で出力するケースもあるためこの点も注意してください。
発生しているエラーや必要な対応を含める
ログから原因・必要な対応が読み取れることが望ましいです
可能な限り運用者が次のアクションに繋げられる情報を含めるようにしましょう
エラーの種類にもよりますが、コードを確認することを前提として、とりあえずスタックトレースを出力する、というのは止めた方がよいです
不要な内容を出力しない
必要な情報がないよりは、出力が多い方が「マシ」ではありますが、ログの出力量が増えるとサーバへの負荷もあがりますし、解析時の負荷上がります
「とりあえず出力する」ではなく、明確に用途をイメージして出力内容を決めましょう
（意外と「必要そうだから」などフワッとした理由でログの出力内容を決めている人を見かけます）
最後に
「適切なログを出力する」というのも一つの技術です。
もし可能であれば、自分が作成したアプリケーションの運用時ログを分析してみてください。
不足している内容や、逆に出力しすぎているなど、実装時には気づけなかったものが見えてくるのではないかと思います。
適切なログを出力しておくことで、運用から開発への問い合わせも減ることに繋がり、結果として開発以外に取られる時間を減らすことできるはずです。
この記事を読んでくださった方が、運用を意識した適切なログについて意識して頂ければ幸いです。
クリエイター
@あーさん
この記事が気に入ったらサポートをしてみませんか？