現在、現場でテストをやってるんですが、やることは昔と変わらずテストデータ作り、ログ、エラーハンドリングになります。
３年近くまえに↓のような記事をかいてました。
テストデータ(再現手法)、ログ、エラーハンドリングが大事って書いてあるんですが、やっぱり変わってないですねー。
ただ本質的なことは変わっていないのですが、ログの抽出方法については直近で大規模な現場を経験したこともあり、結構変わってきました。
色々経験したので、メリデメをまとめておこうと思います。
Contents
ログをどのように抽出するか？
生ログ
比較的小規模〜中規模だったり、レガシーな現場ではいまだに生ログを出力しているというプロジェクトが多いのではないでしょうか。
ただそのまま出しているだけあっていろいろなカスタマイズが可能だったりします。
メリット
- 後述するような設計スキルやエラーレポーティングサービスへの知見が特にいらない
- 全ての情報を自由自在に出力することができる
デメリット
- レベルにもよるが、膨大なサイズになり、ログの検索が大変
- 上記のサイズ制限などにより、保存や管理がしにくい
- レベル分けや入れる情報を精査しないと検索ができない(ログの設計能力がいる)
ログサービス(cloudwatch、application Insightsなど)
生ログをそのまま出す現場はへってきており、中規模以上の現場ではAWSやAzureでシステムを構築している現場が多いと思いますので、これらに付随するログサービスを使っている現場が多いかと思います。
メリット
- さまざまな検索クエリなどをつかうことができ、生ログよりも目的の情報を探しやすい
- 実ログを吐き出しているだけなので、カスタマイズがしやすい
デメリット
- サービスの学習コスト、慣れや検索クエリを覚える手間が若干必要
- 生ログをはいているだけなので、ログ設計指針をしっかりしておかないと検索が大変
レポーティングサービス(Sentryなど)
一般的にログを見なくてはいけないケースは圧倒的にエラーの場合だと思います。その場合、エラーが発生した時のみ、アラートをあげてレポートなどが送られてくる仕組みが便利で、そのためにSentryなどのレポーティングサービスがあると便利でしょう。
現在の現場ではSentryが上がったら、Slackにながれるようになっています。
メリット
- エラーの場合のみ、レポートが送られてくるので、ログよりは見る情報が必然的に少なくて済む
- 情報が細かくカテゴライズされており、検索や抽出が容易
デメリット
- エラーが吐かれない異常の場合、動きを追えない
- 構築の段階でどのエラーハンドリングをもれなくサービスに連携させる設計が必要
- 全ての情報が見れるわけではないので、ある程度推測が必要な部分がでてくる
個人的にはレポーティングサービスでエラーを追いつつ、もしものために通常ログをみれるようにcloudwatchを使うなどの２段構えでログ対策を取るのがいいと思います。
