ログのインサイトと分析
AWS のモニタリングとトラブルシューティング
John Q. Martin
Principal Consultant
Logs Insights のクエリ構造
クエリ言語：同じクエリを3通りで記述
CloudWatch Logs Insights QL
fields @timestamp, @message, level
| filter level = "ERROR"
| filter @timestamp > ago(1h)
| sort @timestamp desc
| limit 20
OpenSearch PPL
source = `/aws/lambda/my-function`
| where level = 'ERROR' and @timestamp > ago(1h)
| fields @timestamp, @message, level
| sort - @timestamp
| head 20
クエリ言語：OpenSearch SQL
OpenSearch SQL
SELECT `@timestamp`, `@message`, level
FROM `/aws/lambda/my-function`
WHERE level = 'ERROR'
AND `@timestamp` > ago(1h)
ORDER BY `@timestamp` DESC
LIMIT 20
- 標準的な SELECT / FROM / WHERE 構文
- ロググループをまたいだ JOIN に対応
- チームに合った言語を選択
シナリオ1：エラーの急増を検出
fields @timestamp, @message, level
| filter level = "ERROR"
| stats count() as error_count by bin(5m)
| sort @timestamp desc
応用：エラー種別でグループ化
fields @timestamp, error_type, error_message
| filter level = "ERROR"
| stats count() as count by error_type, bin(5m)
| sort count desc
シナリオ2：低速な API エンドポイント
fields @timestamp, endpoint, response_time, status_code
| filter response_time > 1000
| stats avg(response_time) as avg_time,
max(response_time) as max_time,
count() as slow_requests
by endpoint
| sort avg_time desc
ドリルダウン
fields @timestamp, endpoint, response_time, user_id, request_id
| filter endpoint = "/api/users" and response_time > 1000
| sort response_time desc
| limit 20
シナリオ3：認証失敗
fields @timestamp, user_id, ip_address, action
| filter action = "login_failed"
| stats count() as failed_attempts by user_id, ip_address
| sort failed_attempts desc
| limit 50
時系列分析
fields @timestamp, user_id, ip_address
| filter action = "login_failed"
| stats count() as attempts by ip_address, bin(1h)
| filter attempts > 10
| sort attempts desc
シナリオ4 & 5：データベースのタイムアウトとメモリリーク
データベースのタイムアウト
fields @timestamp, @message
| filter @message like /database/ and @message like /timeout|error|failed/
| parse @message "timeout after * seconds" as timeout_duration
| stats count() as timeout_count,
avg(timeout_duration) as avg_timeout
by bin(5m)
メモリリークの検出
fields @timestamp, memory_used_mb, heap_size_mb
| stats avg(memory_used_mb) as avg_memory,
max(memory_used_mb) as max_memory
by bin(1h)
| sort @timestamp asc
シナリオ6：リクエストトレーシング
fields @timestamp, @message, request_id, service, action
| filter request_id = "abc123def456"
| sort @timestamp asc
マルチサービストレース
fields @timestamp, service, action, duration_ms, status
| filter request_id = "abc123def456"
| sort @timestamp asc
| display @timestamp, service, action, duration_ms, status
高度なテクニック：parse と正規表現
非構造化ログの解析
fields @timestamp, @message
| parse @message "[*] User * failed to access resource * from IP *"
as level, user, resource, ip
正規表現による解析
| parse @message /Request completed in (?<duration>\d+)ms with status (?<status>\d+)/
高度なテクニック：計算フィールド
fields @timestamp, requests, errors
| fields error_rate = (errors / requests) * 100
fields @timestamp, status_code
| fields status_category =
case(status_code < 300, "success",
status_code < 500, "client_error",
status_code >= 500, "server_error")
| stats count() as request_count by status_category
クエリの最適化
異常検出と相関分析
統計的な異常検出
- ベースラインを算出：7日間の平均と標準偏差
- 現在の期間をベースラインと比較
- 標準偏差の2倍を超える値を異常としてフラグ
エラー率の相関分析
fields @timestamp, level
| stats count() as total_requests,
sum(case(level = "ERROR", 1, 0)) as errors
by bin(5m)
| fields error_rate = (errors / total_requests) * 100
まとめ
- CloudWatch Logs Insights：インフラ不要のインタラクティブなクエリサービス
- 3つのクエリ言語：Logs Insights QL、OpenSearch PPL、OpenSearch SQL
- 6つのトラブルシューティングシナリオ：エラーの急増、低速エンドポイント、認証失敗、DBタイムアウト、メモリリーク、リクエストトレーシング
- 高度なテクニック：非構造化テキスト向けの
parse、時系列向けのbin()、パーセンタイル向けのpct() - 相関分析と異常検出：エラー率分析、統計的ベースラインとの比較
- 調査から自動化へ：メトリクスフィルターとアラームでループを完結
練習しましょう！
AWS のモニタリングとトラブルシューティング
