理解確認：Monitoring / Logging Strategyを改善する

既存ワークロードの監視を改善する。CPUやネットワークなど多数のメトリクスは収集しているが、利用者影響を判断できず、運用チームは障害の兆候を見逃している。最初に見直すべきことはどれか。

既存APIで「エラー率が増え始めた時刻」と「個々の失敗リクエストの原因」の両方を確認したい。最も適切な組み合わせはどれか。

既存のAmazon EC2ベースの業務システムを評価したところ、CPUやネットワークの状態は確認できるが、OS内部の状態とアプリケーション処理の詳細を十分に把握できない。監視戦略の改善として最も適切な考え方はどれか。

複数アカウント・複数リージョンのCloudWatch Logsが分散しており、障害調査のたびに各環境を巡回している。ログを中央の保存先へ集約し、横断検索や分析を行いやすくしたい。現在のAWS機能として最も直接的な候補はどれか。

CloudWatch Logsの一元化ルールを今日作成した。ルール作成より前から送信元ロググループに保存されていた過去ログも、同じルールだけで中央へ自動複製されると期待している。最も正しい評価はどれか。

既存の分散アプリケーションで、CPUなどのリソース値は正常に見える一方、利用者は断続的な遅延を報告している。監視戦略を改善するとき、可観測性の考え方として最も適切なものはどれか。

既存環境ではデバッグログを大量に収集しているが、重要な失敗を示す情報が埋もれ、保存コストと調査時間も増えている。監視戦略の改善として最も適切なものはどれか。

運用チームのダッシュボードにはCPU使用率やリクエスト数だけがあり、注文失敗が売上へ与える影響を判断しにくい。改善として最も適切なものはどれか。

既存システムでは各コンポーネントがログを出しているが、同じユーザーリクエストに関係する記録を結び付けにくい。原因調査を容易にする改善として最も適切なものはどれか。