TL;DR
- 7.19) CloudWatch Logs InsightsのクエリにPatternが追加された
- Patternを使うとMLでログのパターンを自動的に集約して、大量のログをグループ化して確認できる
リファレンス
使ってみる
Aurora PostgreSQLのログでやってみる (1分おきにチェックポイント開始と終了がひたすら出てるログ)
CloudWatchコンソールでログのインサイトを選択
ロググループを選択
クエリにpattern @message と入力して実行
1時間のログが2つに分類された
微妙に違うログを分類してみる
実務的にはこっちだと思う。ログに出るものって微妙な違いで無視したりまとめちゃっていいものと、そうでなく対応が必要なものがある。その辺機械的な仕分けが簡単じゃなくて人間がやってるけど、それをいい感じにできるのか??
Aurora起動時ログをかけてみる
対象とするログの内容
- 起動時なので色んなログがでてる
- 起動後は色んなログは出なくなり、チェックポイント開始/終了のログが定期的に出てる
- が、その中にエラーレベルのログがまぎれてる (見過ごさないようにしたい)
- ERROR: relation “customer” does not exist at character 13
- エラーレベルじゃないやつでも以下とかは見えてほしい
- automatic vacuum of table “PFS.PFS.t1”: … …
patternにかけてみる
pattern @message
実行時間は数秒
(対象の期間内(最大1時間)にログが膨大にあると10秒とか待つことがあったけど早い)
評価
- 大量の無視して良いログ(チェックポイント)に挟まれてるエラーレベルのログは拾えてる
- ERROR: relation “t1” already exists
- 同じく無視可能ログに挟まれてるauto vacuum拾えてる
- automatic vacuum of table “PFS.PFS.t1”: … …
- チェックポイント開始/終了はまとまってていい感じ(合計回数110回で集約)
- 起動時にでてるいろんなログは、強引なアスタリスクでめっちゃ丸められた.. (いえ、いいと思います)
丸め方の例。確かに上手でいい感じかもしれない
1. skipping missing configuration file … 的なもの
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
skipping missing configuration file "/rdsdbdata/config/recovery.conf"
skipping missing configuration file "/rdsdbdata/db/postgresql.auto.conf"
たぶん以下にまとめられてる (これがsampleCount 118回)
<*> <*> <*> <*> <*> <*> <*> <*>2. parameter … changed to “off” 的なもの
parameter "apg_critical_insights_enabled" changed to "on"
parameter "unix_socket_permissions" cannot be changed without restarting the server
...
parameter "rds.aggressive_buffer_eviction_config" changed to "100,1000;130,1250"
parameter "rds.apg_space_reclaim_thread_enabled" changed to "on"
parameter "rds.enable_buffer_pin_conflict_forking" changed to "on"
parameter "rds.enable_replication_diagnostic_report" changed to "off"
parameter "rds.resource_manager_enabled" changed to "true"
parameter "unix_socket_permissions" cannot be changed without restarting the server
received SIGHUP, reloading configuration files たぶんこれも以下にまとめられてる
<*> <*> <*> <*> <*> <*> <*> <*>でもこれだけ別で分類されて見えるようになってる
parameter “rds.aggressive_buffer_eviction_config” changed to “100,1000;130,1250”
changed toの後が、on/off/trueじゃなくて、数値になってるものだけ、一緒くたから除外されたみたい
3. ERRORレベルのログもまとめられてる。これはエラーが多い場合良さそう
ERROR: relation “customer” does not exist at character 13
ERROR: <*> <*> does not exist at character <*>結論
ちょっとさわった感じだといい感じにまとめてくれてるように見えるので、ログが大量の場合はいっかいpatternにかけてみると、同じものが何百回でてるといった傾向や、逆に大量のログに挟まれて検知しづらいものが見えてくる可能性あり。目grepは必要だけど、各ログとも時間順で出力時刻部分の削除や整形が面倒だったり、同じように見えてちょっと違いがある出力の連続とかだとエディタでの集計とか目grepもしづらいので、patternにかけてみてどんな感じが見てみる価値あり。
あとは運用時に使ってナレッジをためてもっと使えるようになって(対象期間とかクエリのチューニング)、ログ見るときの手段として目grepとかエディタでの集計と併用するとログ解析がはかどりそう。