STAY KOBE

[SolutionArchitect Pro] AWS CloudWatch

Atsushi Marumo

AWS CloudWatch

CloudWatch アーキテクチャ

CloudWatch の概念

メトリック

名前空間

ディメンション

タイムスタンプ

単位

統計

期間

集計

アラーム

リージョン

カスタムメトリック

サポートされるサービス

CloudWatchへのアクセス

AWS認定試験の練習問題

  1. 企業は、AWS MySQL RDS インスタンスの読み取りおよび書き込みの IOPs メトリックを監視し、リアルタイムのアラートを運用チームに送信する必要があります。これはどの AWS サービスで実現できますか?2つの回答を選択
    1. Amazon Simple Email Service (直接 CloudWatch と統合することはできません)
    2. Amazon CloudWatch
    3. Amazon Simple Queue Service
    4. Amazon Route 53
    5. Amazon Simple Notification Service
  2. 顧客は、5分ごとにロードバランサーからすべてのクライアント接続情報を取得する必要があります。同社は、トラフィックのパターンを分析し、そのアプリケーションのトラブルシューティングにこのデータを使用したい。お客様の要件を満たすオプションは次のどれですか。
    1. ロードバランサーに対して AWS CloudTrail を有効にします。
    2. ロードバランサーのアクセスログを有効にします。(リンク参照)
    3. ロードバランサーに Amazon CloudWatch ログエージェントをインストールします。
    4. ロードバランサーで Amazon CloudWatch メトリックを有効にする (クライアント接続情報を提供しません)
  3. ユーザーは、EBS でバックアップされた EC2 インスタンスでバッチプロセスを実行しています。 バッチ処理では、Hadoop Map reduce ジョブを処理するためにいくつかのインスタンスが開始されます。ジョブは50〜600分または時にはさらに時間がかかります。 ユーザーは、プロセスが完了したときにのみインスタンスが終了するように構成する必要があります。 ユーザーはCloudWatchでこれをどのように設定できますか？
    1. CPU 使用率が 5% 未満の場合にインスタンスを終了するように CloudWatch アクションをセットアップします。
    2. 自動スケーリングを使用して CloudWatch をセットアップし、すべてのインスタンスを終了する
    3. 600分後にすべてのインスタンスを終了するジョブをセットアップする
    4. インスタンスを自動的に終了することはできません。
  4. ユーザーには2つの別個の領域で実行される2つの EC2 インスタンスがあります。ユーザーは、同じ名前空間とメトリックを持つ CLI を使用して、データをキャプチャし、米国東部の CloudWatch に送信する内部メモリ管理ツールを実行しています。上記のステートメントに関して、以下のオプションのうちどれが該当しますか?
    1. CloudWatch がリージョン間でデータを受信できないため、セットアップは機能しません。
    2. CloudWatch は、名前空間とメトリックに基づいてデータを受け取り、集計します。
    3. CloudWatch は、データが2つのソースのために競合するため、エラーを与える
    4. CloudWatch は、最初にデータを送信するサーバーのデータを取得します
  5. ユーザーが CloudWatch API を使用して CloudWatch にデータを送信しています。ユーザーは、今後データを90分間送信しています。この場合、CloudWatch は何を行いますか?
    1. CloudWatch は、データを受け入れる
    2. 将来のデータを送信することはできません。
    3. CloudWatch にデータを手動で送信することはできません。
    4. ユーザーは、今後60分以上のデータを送信することはできません。
  6. ユーザーは、特定のイベントに基づいてランダムに生成されたデータを持っています。ユーザーは、そのデータを CloudWatch にアップロードする必要があります。イベントによっては、乱数のためにデータが生成されない場合があります。この場合の推奨オプションは以下のとおりです。
    1. データがない期間については、ユーザーはデータをまったく送信しないでください。
    2. データがない期間については、ユーザーは空白の値を送信する必要があります
    3. データがない期間は、ユーザーが 0 として値を送信する必要があります (ユーザーガイドを参照)
    4. ユーザーは、ある期間のデータがないとして CloudWatch にデータをアップロードする必要があります CloudWatch 監視でエラーが発生します。
  7. ユーザーは、計量プラントを持っています。ユーザーは、5分ごとにいくつかの商品の重量を測定し、監視と追跡のために AWS CloudWatch にデータを送信します。ユーザーが要求リストに含めるためには、以下のパラメータのうちどれが必須ですか。
    1. 値
    2. 名前空間 (put-metric リクエスト を参照)
    3. メトリック名
    4. タイムゾーン
  8. ユーザーは、冷蔵庫の工場を持っています。ユーザーは、15分ごとに植物の温度を測定している。ユーザーがデータを視覚的に表示するためにデータを CloudWatch に送信したい場合は、上記の情報に関して以下の記述のうちどれが真であるか。
    1. ユーザーは、データをアップロードするために AWS CLI または API を使用する必要があります。
    2. ユーザーは AWS インポートエクスポート機能を使用して、CloudWatch にデータをインポートできます。
    3. ユーザーは AWS コンソールからデータをアップロードします。
    4. ユーザーは AWS サービスメトリックではないため、CloudWatch にデータをアップロードできません
  9. ユーザーが EC2 インスタンスを起動しました。ユーザーは CloudWatch アラームのセットアップを計画しています。CloudWatch アラームでサポートされていないアクションは、以下のうちどれですか?
    1. スケールアップの自動スケーリング起動設定を通知する
    2. SNS を使って SMS を送る
    3. 自動スケーリンググループにスケールダウンを通知する
    4. EC2 インスタンスを停止する
  10. ユーザーは、最後の1週間のすべての CloudWatch メトリックデータを集約しようとしています。以下のうち、データ集計の一部としてユーザーに利用できない統計はどれですか？
    1. 集計
    2. 合計
    3. サンプルデータ
    4. 平均
  11. ユーザーは、CPU 使用率が 75% を超えると、EC2 アクションに CloudWatch アラームを設定します。アラームは、アラーム状態の SNS に通知を送信します。ユーザーがアラームアクションをシミュレートしたい場合は、どのように彼はこれを達成することができます?
    1. CPU 上でアクティビティを実行し、その使用率が 75% 以上に達するようにします。
    2. AWS コンソールから状態を「アラーム」に変更します。
    3. ユーザは、CLI を使用してアラーム状態を「アラーム」に設定できます。
    4. SNS アクションを手動で実行する
  12. ユーザーが CloudWatch にカスタムメトリックスを公開しています。以下のステートメントのどれが、ユーザーが機能をよりよく理解するのに役立ちますか。
    1. ユーザーは CloudWatch インポートツールを使用できます。
    2. ユーザーは、約15分後にコンソールでデータを見ることができるはずです
    3. ユーザーがカスタムデータをアップロードする場合、ユーザーはコマンドの一部として名前空間、タイムゾーン、およびメトリック名を指定する必要があります。
    4. ユーザーは、コンソール、CLI、API を使用してデータをアップロードするだけでなく、表示することもできます。
  13. 管理するアプリケーションには、複数の AWS リージョンにデプロイされた EC2 インスタンスと DynamoDB テーブルがあります。アプリケーションのパフォーマンスをグローバルに監視するために、すべての EC2 インスタンスでの平均 CPU 使用率と 2) すべての DynamoDB テーブルのスロットル要求数を2つのグラフで確認します。どのようにこれを達成することができますか?[PROFESSIONAL]
    1. アプリケーション名を使用してリソースにタグを付け、CloudWatch 管理コンソールのディメンションとしてタグ名を選択して、それぞれのグラフを表示します (CloudWatch メトリックはリージョン)。
    2. CloudWatch CLI ツールを使用して、各リージョンのエンドポイントからそれぞれのメトリックを引き出します。データをオフラインで集計し、CloudWatch のグラフに保存します。
    3. 各インスタンスおよび DynamoDB テーブルに SNMP トラップを追加します。中央監視サーバーを活用して、各インスタンスとテーブルからデータをキャプチャします。グラフの CloudWatch に集計データを配置する (管理されたサービスであるため、DynamoDB に SNMP トラップを追加することはできません)
    4. 各インスタンスに CloudWatch エージェントを追加し、各 DynamoDB テーブルに1つをアタッチします。エージェントを設定するときは、適切なアプリケーション名と CloudWatch のグラフを表示します。(管理されたサービスとして DynamoDB にエージェントを追加することはできません)
  14. 各プロジェクトに対して個別の AWS アカウントを設定しました。AWS インフラストラクチャのコストが毎月のプロジェクトごとの予算セットを超えないようにするように求められています。毎月予算を超過しないようにするには、次のどちらの方法が役立ちますか。[PROFESSIONAL]
    1. すべてのアカウントとプロジェクトに対して1つの請求書を持っているので、アカウントを統合します (連結はアカウントごとの制限には役立ちません)
    2. SNS を使用した CloudWatch アラームによる自動スケーリングの設定特定のアカウントで多数のインスタンスを実行している場合に通知する (多くのインスタンスはコストに直接マップせず、正確なコストを与えることはありません)
    3. 各プロジェクトで使用されているすべての AWS リソースに対して CloudWatch 請求アラートを設定し、特定のプロジェクトにタグ付けした各リソースの金額がプロジェクトに割り当てられた予算と一致する場合に通知が発生します。(各プロジェクトには既にアカウントがあるため、リソースのタグ付けは必要ありません)
    4. 各アカウントで使用されているすべての AWS リソースに対して CloudWatch 課金アラートを設定し、50% に達したときに電子メールで通知します。予算月間費用の 80% と 90%
  15. 今月のデータを確認するために、運用チームと毎月1回会う。会議中に、3週間前に、AWS の外部から HTTP 経由で ping を実行する監視システムが、3層 web サービス API の待ち時間に大きなスパイクを記録したことに気付きました。DynamoDB は、ビジネスロジック層に対してデータベース層、ELB、EBS、および EC2 に対して使用し、プレゼンテーション層には SQS、ELB、および EC2 を使います。次の方法のうち、何が起こったかを把握するのに役立ちますか?
    1. 遅延の原因となった API 呼び出しについては、スパイクの時間を中心に CloudTrail ログ履歴を確認してください。
    2. CloudWatch メトリックグラフを確認して、どのコンポーネントがシステムを減速したかを確認します。(メトリックデータは2週間前に利用できましたが、今は拡張されています)
    3. S3 の ELB アクセスログを確認して、システム内の ELB が待ち時間を見たかどうかを確認します。
    4. ログを分析して、その時点でのトラフィックのバーストを検出します。
  16. AWS アカウントには高いセキュリティ要件があります。アカウントへの AWS API 呼び出しへの反応に使用できる、最も迅速で洗練されたセットアップとは何ですか。
    1. SNS トピックを介して AWS 設定へのサブスクリプション。Lambda 関数を使用して、飛行中の解析とその変化に対する反応性を実行します。
    2. グローバル AWS CloudTrail は、配信通知への SNS サブスクリプションを使用して S3 に配信し、Lambda にプッシュして、分析のために ELK スタックにレコードを挿入するセットアップを行います。
    3. CloudWatch ルール ScheduleExpression を使用して、IAM 資格情報ログを定期的に分析します。イベントのデルタを ELK スタックにプッシュし、そこでアドホック分析を実行します。
    4. CloudWatch イベントルールは、すべての AWS API 呼び出しに基づいてトリガされ、すべてのイベントを AWS Kinesis Streams に送信して、任意のダウンストリーム解析を行います。 (CloudWatch イベントは、AWS API 呼び出しへのサブスクリプションと、これらのイベントの方向を Kinesis Streams に許可します。これにより、すべての API 呼び出しについて、ほぼリアルタイムの統一されたストリームを、どのツールでも分析できるようになります。リンク参照)
  17. 異なるユーザーとエンティティによる AWS アカウントに対する API 呼び出しを監視するには、____ を使用して、後で確認するために一括して呼び出し履歴を作成し、____ を使用してリアルタイムで AWS API 呼び出しに反応することができます。
    1. AWS Config ; AWS Inspector
    2. AWS CloudTrail ; AWS Config
    3. AWS CloudTrail ; CloudWatch イベント(CloudTrail はバッチ API 呼び出しコレクションサービスであり、CloudWatch イベントは、Rules オブジェクトインターフェイスを通じた呼び出しのリアルタイム監視を可能にします。リンク参照)
    4. AWS 設定;AWS Lambda
  18. あなたは SaaS の会社のための操作の新しいヘッドとして雇われている。あなたの CTO は、あなたの全体の操作の任意の部分を簡単に、できるだけ早くデバッグするように求めている。彼女は、複雑なサービス指向のアーキテクチャでは、開発者がディスクにログオンするだけで、非常に多くのサービスでログのエラーを見つけるのは難しいので、何が起こっているのか見当がつかないという不満を抱いています。この要件を満たし、CTO を満足させるにはどうすればよいでしょうか。[PROFESSIONAL]
    1. 各インスタンスの cron ジョブを使用して、すべてのログファイルを AWS S3 にコピーします。 PutBucket イベントで S3 通知構成を使用し、AWS Lambda にイベントをパブリッシュします。Lambda を使用して、問題が発生したときにすぐにログを分析します。(検索では高速ではありませんし、遅延を生じる)
    2. すべてのサービスで CloudWatch ログの使用を開始します。すべてのロググループを S3 オブジェクトにストリーミングします。AWS EMR クラスタジョブを使用して、アドホック MapReduce 分析を実行し、必要に応じて新しいクエリを作成します。(検索では高速ではありませんし、遅延を生じる)
    3. 各インスタンスの cron ジョブを使用して、すべてのログファイルを AWS S3 にコピーします。 PutBucket イベントで S3 通知構成を使用し、AWS Kinesis にイベントをパブリッシュします。AWS EMR で Apache Spark を使用して、ログチャンクおよびフラグの問題に対して、スケールストリーム処理クエリを実行します。(検索では高速ではありませんし、遅延を生じる)
    4. すべてのサービスで CloudWatch ログの使用を開始します。すべてのロググループを KIBANA 4 を実行している AWS Elasticsearch サービスドメインにストリーミングし、検索クラスタでログ分析を実行します。(ELK – Elasticsearch、Kibana スタックは、リアルタイムのアドホックログ分析と集約のために特別に設計されています)
  19. EC2 ベースのマルチティアアプリケーションには、さまざまなアプリケーションコンポーネントのアプリケーションレベルの読み取り専用要求を定期的に作成する監視インスタンスが含まれています。これらのコンポーネントのいずれかが30秒以上失敗すると、CloudWatch がアラームを発生させ、 電子メールと SMS を使用して、アプリケーションの健全性の問題を検討してください。 ただし、ウォッチャー（監視インスタンス自体）を監視し、不健全になった場合は通知を受ける必要があります。 次のうち、その目標を達成するための簡単な方法はどれですか？[PROFESSIONAL]
    1. 監視インスタンスを ping する別の監視インスタンスを実行し、アラームマットを起動すると、プライマリ監視インスタンスが異常になるようにオペレーションチームに通知します。
    2. EC2 システムおよびインスタンスステータスチェックに基づいて CloudWatch アラームを設定し、監視インスタンスで検出された問題のオペレーションチームにアラームを通知します。
    3. 監視インスタンスの CPU 使用率に基づいて CloudWatch アラームを設定し、CPU 使用率が 50％ を超えて 1 分を超える場合はアラームを運用チームに通知します。監視アプリケーションを CPU バインドループに移行させる アプリケーションの問題を検出します。
    4. 監視インスタンスが SOS キューにメッセージをポストしてからキューが新しいメッセージを停止すると、別のインスタンスのメッセージをデキューし、2番目のインスタンスは最初に元の監視インスタンスを終了し、別のバックアップ監視インスタンスを開始し、 インスタンスを監視し、SQSキューにメッセージを追加し始めます。

リファレンス

Jayendra’s Blog

この記事は自己学習用に「AWS CloudWatch – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。