現在のプロジェクトではインフラ環境をAzureで構築していますが、ログをApplication Insights(Azure上の管理画面から使えるサービス)で管理してます。
世界一わかりみの深いAPM 〜Application Insightsでアプリケーションパフォーマンス管理に全集中！！〜
テスト、ログ、エラーハンドリングはどの現場でも重要になる最大事項ですが、ログについてはどのようにだすかもそうですが、どこに出すか、どのように抽出するかも重要になってきますね・・・・
どこに出すか(告知をするか)
レガシーな環境ですとサーバーに出すのが一般的かとは思いますが、サーバーに出すと
- 適度な抽出や複雑な検索(IPが××でレベルがINFOで検索語句に’〇〇’が入っている)がしづらい
- ログローテが不完全だとサーバーパンクする(過去に数回ありました・・・汗)
- サーバーに入れない環境などでは当然見れない(今だと結構増えてると思います。)
- 定期的なログのトレース(アクセス解析的なもの)をするのには当然独自にスクリプトを組む必要がある
のようなデメリットがあります。
そのため、管理画面から見れるツールなどを使うことが一般的ではないでしょうか。AWSでしたらcloudwatchとかazureだとApplication Insightsのようなものになると思います。
これらのサービスを使うと上記に挙げたデメリットが解決できます。
またエラー(特に例外系のシステムエラー)の場合はSentryなどのエラーレポートサービスやそうでなくてもメールなどで告知する仕組みが必要になるでしょう。
どのように抽出するか
今回Application Insightsで驚いたのですが、検索対象のカラムが10から20ぐらいありました。
sessionIDやAPIの場合はアクセスURL、IP、国、都市、クラス、システム名などなど・・・
まあわけがわからないものが多かったのですが・・・汗
自分が実務で検索するときに必要になるキーなどについて触れておこうと思います。
ログレベル
これを考えない方はいないと思いますが、debug,info,warning,error,fatalのうちどれで抽出するのかということになります。一般的にはfatalやerrorを元にそこにいくまでを辿る必要が出てきます。
特定の検索語句
エラーが起こった時のログの解析としてはなんらかのエラーが起こり、エラーが起こっているリクエスト開始からエラーの起こる地点までの調査・・となることが多いと思います。
その場合、一般的には
- リクエストパラメーターに含まれているクエリの一部
- エラーコード
などで検索することが多いでしょう。
システム名やアクセス元
今まではあまり意識することはなかったんですが、複数のアプリやAPIが混合していると、自分が関わっているシステムのログを抽出するだけでもものすごい大変だったりします。
その場合、自分のシステム名やあるいはアクセスしているIPなどで抽出することができればログの解析が容易になります。
その他の注意点
一般的には本番環境ではある程度のレベル以上のログ(ある程度のレベル)を出すことが多いようなのですが、少なくともリリースまでは全レベルを出しておかないととても追えないと思います。(特にSQL)
