エラーログって軽視されがちでないですか？

DB のエラーログってクラウドサービスでも使ってない限り、軽視する傾向にあるのではないでしょうか。

クラウドサービスの場合は web 上で確認できるので手軽ですが、そうでない場合はどう管理すれば良いのやらという感じです。

例えば、

• エラーログに関する無知
• エラーログを見ることができない・見づらい

などの理由で曖昧にされることもあるのではないでしょうか

エラーログの種類

PostgreSQL のエラーログ

PostgreSQL の場合は以下のようにレベルが分かれています。上から順に重要度が高くなっています

• PANIC
• FATAL
• LOG
• ERROR
• WARNING
• NOTICE
• INFO
• DEBUG1 ~ DEBUG5

PANIC から WARNING までは定常的な監視をしていた方が良さそうです

MySQL のエラーログ

• General Query Log
  • 接続情報や実行したクエリなどの操作関連
• Slow Query Log
  • 実行したクエリの処理にかかった時間
• Error Log
  • Error, Warning, Note の３種類のログレベルがある
  • Error には PostgreSQL の PANIC から ERROR 同等のものが含まれる
  • サーバから出力されるエラ〜メッセージ
• Debug Log
  • 開発者用のトレースログ

エラーログの監視

エラーログの種類がわかったところで、実際にそのログを監視しなければ意味がありません。

ではエラーログをどうやって監視するのが良いでしょうか

3 つの観点から考えてみましょう

1. レベルを分ける
2. 通知の仕組みを作る
3. 可視化する

レベルを分ける

まずはレベルを分けるですが、開発環境と本番環境では取得するログに差を出したり、通知するか否かを考えることができます

PostgreSQL を例にして考えると、開発環境においては、PANIC から DEBUG の全てのログを出力して良いでしょう。また通知は、PANIC から FATAL ぐらいを通知で十分ではないでしょうか。本番環境においては、PANIC から INFO のログを出力して、通知は開発環境と同じぐらいで十分ではないでしょうか。

そう考えると開発環境と本番環境で違うのはログの出力に DEBUG が入るかどうかぐらいですが、その 2 つの環境で分けすぎると、本番環境になって気付くログなども出てきてしまうので妥当だと思います

通知の仕組みを作る

次に、通知の仕組みを作るですが、Mackerel や Zpbbix などの監視サービス・ツールを使って Slack などへ通知を送るのが一般的です。最近では AWS/GCP などで PubSub の仕組みを使い、ログにトピックをつけて、サーバーレスで監視をして Slack に通知などの構成も取ることが考えられます

【参照】

• https://aws.amazon.com/jp/sns/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc#How_it_works
• https://cloud.google.com/pubsub/docs/overview?hl=ja

可視化する

Elastic 社が提供している Elastic Stack を使うことで可視化が可能です。

【参照】

• https://codezine.jp/article/detail/10083

また、クラウドサービスにはログ可視化サービスがついていることもあります

GCP であれば以下のようなサービスがあります

• トレース
• モニタリング
  • API/DB/GCS などなど
• プロファイラ
• Logging

参考

失敗から学ぶ RDB の正しい歩き方