[アップデート]CloudWatch Logs Insightsでクエリ結果が要約できるようになりました
お疲れさまです。とーちです。
CloudWatch Logs Insightsで「クエリ結果の要約」と「OpenSearch PPLの機能強化」という2つのアップデートが発表されていたので、早速試してみました。
今回のアップデートについて
CloudWatch Logs InsightsはCloudWatchロググループに貯められたログに対してクエリを実行することで特定のログを抽出するなどの分析をしたり、抽出したログをグラフ等で可視化できるサービスになっています。
このCloudWatch Logs Insightsの新しい機能として以下の2つが追加されました。
- クエリ結果の要約
- OpenSearch PPLの機能強化
一つずつ説明していきましょう。
クエリ結果の要約について
こちらは文字通りCloudWatch Logs Insightsでクエリした結果を要約できる機能になっています。機能としてはシンプルなのですが、公式ドキュメントを見るといくつか注意事項もあるのでそれを紹介します。
使用可能リージョン
使用可能なリージョンはバージニア北部(us-east-1)、オハイオ(us-east-2)、オレゴン(us-west-2)のみです。
また、重要な点として以下の記載が公式ドキュメントにありました。
When you use this feature, your query results might be processed in a different AWS Region within the same continent as your origin region. (日本語訳:この機能を使用する際、クエリの結果は、元のリージョンと同じ大陸内にある別のAWSリージョンで処理される場合があります。)
これはつまり、バージニア北部で要約を行った場合でも要約処理自体はオレゴンで行われる場合があるといったことを示しているようです。要約にはBedrockを使用しているので、クロスリージョン推論を裏では行っていそうですね。
データプライバシーについて
データプライバシーについては、CloudWatch Logs Insights または Amazon Bedrock のトレーニングや改善には使用されません
と公式ドキュメントに明記されていました。安心ですね。
OpenSearch PPLの機能強化について
私はあまり意識していなかったのですが、CloudWatch Logs Insightsでは以下の3つのクエリ言語がサポートされています。
- CloudWatch Logs Insights クエリ言語(Logs Insights QL)
- OpenSearch PPL
- OpenSearch SQL
このうちのOpenSearch PPLについて、今回のアップデートで使用できるコマンドと関数が増えました。例えば以下のようなものが使用できるようになりました。
- JOINコマンド
- SubQueryコマンド
- Fillnullコマンド
- Expandコマンド
- Flattenコマンド
- Cidrmatch関数
- JSON関数
現在使用できるコマンドと関数は以下のページにまとまっているのでこちらも合わせてご確認ください。
やってみた
それではそれぞれの機能について試してみましょう。
クエリ結果の要約
上記の通り、現時点ではUSリージョンでのみサポートされているので、us-east-1で試してみます。
まずRDSのエラーログが出力されたロググループに対して、以下のようにクエリを実行します。
以下のようにクエリ結果が出力されました。
ざっと見ると「プラグイン mysql_native_passwordは非推奨」、「ready for connections.(起動後に接続準備完了した旨のメッセージ)」、「unknown variable '<変数名=値>'」などのエラーメッセージが出ています。
これを要約してみます。「Summarize results」ボタンを押します。
すると以下のようなメッセージが出ました。
日本語訳すると以下となります。
ログには、MySQLデータベースインスタンスが起動し、バージョンアップグレードプロセスと思われる処理が実行されていることが示されています。
将来のリリースで削除される予定の非推奨SSL暗号化アルゴリズムに関する多数の警告が表示されています。
また、MySQLシステムテーブルの自動増分値の読み取りに関する複数のInnoDB警告が、設定ファイルの欠落または必要な自動増分回復機能の未設定が原因で発生しています。
認証やAurora固有の設定に関連する複数の未知の変数に関する警告が表示されています。
ログには、メンテナンス作業中に接続の切断やトランザクションの失敗がなかったことを示すZero Downtime (ZD) メトリクスが含まれており、
アップグレードまたは再起動プロセスが正常に完了した可能性を示しています。
おー、これは結構良い要約ではないでしょうか?事前に確認していたログの要素は含まれていますし、その他に対象の時間帯で何が発生していたのかも解説してくれました。
これは素晴らしいですね。CloudWatch Logs Insightsで障害が発生していた時間帯のログをクエリして要約させてみるみたいな使い道が想像できます。東京リージョンでもサポートしてほしいですね。
OpenSearch PPLの機能強化
OpenSearch PPLについては私は触ったことがないので、こちらの公式ドキュメントを読んでみたのですが、コマンドがいくつか定義されており、それらのコマンドをパイプ(|
)でつなげていくという使い方をするようです。
ということで、新しくCloudWatch Logs Insightsでサポートされたコマンドをいくつか試してみます。なおこちらは東京リージョンで試しました。
以下のような普通のLambdaログのロググループを対象にクエリを実行します。
SubQuery
複雑なネストしたクエリを実行できるコマンドです。クエリの例としては以下です。(構文参考)
fields @timestamp, @requestId, @type, @message
| where @requestId IN [
search source=`/aws/lambda/hello-v1`
| where @type = "REPORT"
| fields @requestId
]
| where @type = "START"
| stats count()
| head 100
少し複雑なので順を追って説明します。まずサブクエリを実行しているのは[]
の中の部分です。
[
search source=`/aws/lambda/hello-v1`
| where @type = "REPORT"
| fields @requestId
]
ここでは、ロググループ(/aws/lambda/hello-v1
)の中のログで@type列
に"REPORT"
という値をもつログのみを抽出し、そのログの@requestId
の値でリストを作っています。
次に冒頭の部分の以下のクエリについて、
fields @timestamp, @requestId, @type, @message
| where @requestId IN [サブクエリ結果]
@requestId IN [...]
で、サブクエリで取得したrequestIDリストに含まれるログのみを抽出しています。
つまり「@type列
に"REPORT"
という値をもつログのrequestID」を持つログのみを抽出することになります。
最後に後半部分のクエリについて
| where @type = "START"
| stats count()
| head 100
サブクエリで取得したrequestIDリストに含まれるログの中から更に@type列
に"START"
という値をもつログのみを抽出し、stats count()
でその件数を取得しています。結果は以下のようになります。
このように複雑なクエリを実行できるのが、SubQueryとなっています。
Fillnull
指定した列のnull値となっている箇所を特定の値で埋めるコマンドです。クエリの例としては以下です。(構文参考)
fields `@timestamp`, `@message`, `@logStream`, `@log`, errorcode
| sort - `@timestamp`
| fillnull using errorcode = "UNKNOWN"
| head 100
上記クエリでは、errorcodeという列を追加しているのですが、errorcodeという列は元々のロググループ内には存在しないフィールドなので、値はnull値になります。fillnullを実行することで以下のように指定した値UNKNOWN
でnull値の部分を埋めています。CloudWatch Logs Insightsでの使い道は正直思いつかないのですが、機械学習等では欠損値の補完のためにこういった処理が行われている印象です。
まとめ
というわけで、CloudWatch Logs Insightsの新機能「クエリ結果の要約」と「OpenSearch PPLの機能強化」について紹介しました。
特にクエリ結果の要約機能は、障害対応時にログを素早く理解するのに非常に有用だと感じました。現時点ではUSリージョンでのみ利用可能ですが、今後東京リージョンでもサポートされることを期待したいと思います。
以上、とーちでした。