【AWS CloudWatch】基本の解説と設定方法

Amazon Web Services（AWS）が提供する100を超えるサービスの中で、Amazon CloudWatchはAWSが提供する最も初期のサービスの1つでした。 CloudWatchは2009年5月17日に発表され、S3、SQS、SimpleDB、EBS、EC2、EMRの後にリリースされた7番目のサービスでした。

AWS CloudWatchは、ログやメトリックの収集など、幅広いクラウドリソースを網羅するツールスイートです。 モニタリング; 視覚化とアラート; 運用状態の変化に応じた自動化されたアクション。 CloudWatchは、監視を超えて可観測性を実現できる優れたツールです。

AWS CloudWatchのデータをMetricFireのダッシュボードに直接繋げることができ、実はUIの向上や経済的な面からみてもMetricFireを使用する価値があるはずです。 無料トライアルで確認し、是非MetricFireでデータを視覚化してみてください。

1. はじめに

しばらくの間、可観測性はクラウドコンピューティングと最新のソフトウェアエンジニアリングエコシステムにおいて不可欠な位置を占めてきました。この言葉はもはや単なる流行語ではありません。Amazonは、予防的な監視を行うためのツールと手段を追加することで、これに適応してきました。

実際、多くの監視を行うことができますが、監視可能なシステムがない場合もあります。

可観測性が聞きなれない方は、システムの内部出力が外部出力の知識からどれだけ適切に推測できるかを示す尺度と考えてください。簡単に言うと、監視は問題の症状に関するものであり、可観測性は問題の（考えられる）根本原因に関するものです。

可観測性は、「ホワイトボックスモニタリング」と考えることもできます。このタイプの監視では、ログ、メトリック、およびトレースが可観測性の柱です。

このブログ投稿では、CloudWatchの基本を紹介し、そのユースケースをいくつか見て、重要なコンセプトについて詳しく説明していきます。今回は、CloudWatchが提供する以下の4つの主な機能に焦点を当てます。

• アラート
• イベント
• ログ
• メトリック

2. CloudWatchアラーム

事前設定されたしきい値に達した時や、条件が満たされた時にアクションを開始するようにアラームを設定できます。 これをよりよく理解するために、Elastic Computing Cloud（EC2）マシンを作成してみましょう。 ナノインスタンスまたはマイクロインスタンスを使用できるため、本番インスタンスは必要ありません。

このインスタンスを作成するときは、必ずCloudWatch detailed monitoringを有効にしてください。これにより、追加コストで1分間隔でデータを利用できるようになります。 標準モニタリングは無料ですが、CloudWatchにデータを配信するのに5分かかります。

EC2インスタンスを作成したら、EC2マシンを使用してアラームを設定できます。 まず[Edit]をクリックし、次に[Add alarms]をクリックします。

このステップでは、理解すべき重要なコンセプトがあります。アラームはAWS CloudWatchによって管理されますが、ほとんどのユースケースでは、アラームがアクティブになるとメールなどで通知されるように設定されています。 この機能は、AWS Simple Notification ServiceまたはSNSによって管理されており、 SNSは、低コストのメッセージングおよび通知サービスであり、パブリッシャーをサブスクライバーから切り離すことができます。 私たちの場合、SNSはCloudWatchアラームをリッスンし、アラームがアクティブになったときにメールを送信するために使用されます。

EC2アラーム設定ウィンドウからSNSトピックを作成するか、SNS管理ダッシュボードを使用できます。今回は、EC2インスタンスの平均CPU使用率が少なくとも1分間50％以上に達したときに、CloudWatchからメールを送信するとします。 これはEC2コンソールから簡単に設定でき、また同じ条件が満たされたときにトリガーされるアクションを設定することもできます。 ここで、トピックへのメール購読を確認することを忘れないでください。

これをテストするために、EC2 CPUに負荷をかけ、CloudWatchからの結果のアラームと通知を確認します。 ここで使用するツールはstressと呼ばれます。 タイムアウトが600秒のsqrt（）で500ワーカーをスピンさせるには、次のコマンドを使用できます。

stress --cpu 500 --timeout 600

数分後、アラームがアクティブであることを確認できます。また、上記で作成したトピックへのサブスクリプションを確認した場合は、メールも届きます。

条件が満たされたときにメール通知をプッシュする方法を確認しましたが、補足として、自動スケーリングなどのメソッドをトリガーする他のアクションを設定することもできます。

You are receiving this email because your Amazon CloudWatch Alarm "awsec2-i-073cf4770bed5d313-CPU-Utilization" in the EU (Paris) region has entered the ALARM state, because "Threshold Crossed: 1 datapoint [71.6666666666667 (14/10/19 14:00:00)] was greater than or equal to the threshold (50.0)." at "Monday 14 October, 2019 14:01:56 UTC".‍

3. CloudWatchイベント

AWSリソースの変更を説明するほぼリアルタイムのストリームが必要な場合、探しているのはイベントです。 イベントにより、CloudWatchは操作上の変更が発生したときにそれを認識し、アクションを実行することによって応答します。

3.1 イベントとアラーム

使用するAWSリソースのいずれかにアラームを作成でき、しきい値に達すると通知が届きます。 イベントは時間の経過とともに継続的に記録されます。 この継続性は、イベントとアラームの主な違いです。

CloudWatchイベントはシステムイベントのストリームであり、システムの全体像を提供します。 一方、アラームは通常、測定しているメトリックがわかっている場合に使用されます。

例を挙げるとすれば、Netflixのようなストリーミングサービスを実行していて、世界中で何百万人もの視聴者がいるとします。 アラームのみを使用している場合、システムの負荷と運用上の変更が発生するため、それらを完全に把握することはできません。

3.2 CloudWatchイベントの基本

CloudWatchイベントストリームを設定するときに理解しておくべき3つの概念があります。

1. イベント

各リソースには、状態が変化したときにAWSによって生成されたイベントのリストがあります。 この例では、EC2インスタンスの状態が変化したときにイベントをトリガーする方法を学びました。

2. ターゲット

イベントがトリガーされると、ターゲットはイベントを（JSON形式で）受け取ります。

3. ルール

イベントがトリガーされたとき、または状態が変化したとき（この変化が、ユーザーが事前構成したルールと一致したときのみ）、イベントはイベントソースからターゲットに送信されて処理されます。

以下は、AWS CloudWatchが提供するターゲットサービスの一部です。

• Amazon EC2インスタンス
• Amazon CloudWatch Logsのロググループ
• AWS Batchジョブ
• AWS Lambda関数
• Amazon ECSタスク
• Amazon SNSトピック
• Amazon SQSキュー
• Amazon Kinesisデータストリーム

別のAWSアカウントのデフォルトのイベントバスをターゲットとして設定することもできます。

3.3イベントとルールの作成

このブログ投稿の最初の部分では、EC2マシンを作成しました。 これを使用して、インスタンスの状態に関するデータを含みながら、イベントを継続的にストリーミングする方法と、変更が発生するとすぐにイベントがターゲットを呼び出す方法を説明していきます。

AWS CloudWatchコンソールに移動し、[Events]をクリックして、新しいルールを作成します。

EC2サービスの状態変化に一致するようにイベントパターンを構成し、（IDを使用して）単一のインスタンスを指定できます。 ターゲットには、すでにメールで購読しているのと同じSNSトピックを設定できます。 これにより、インスタンスの状態が"stopped", "terminated", "stopping", または "shutting-down"になると、メールが送信されることが保証されます。

インスタンスを停止してイベントをトリガーしてみましょう：

aws ec2 stop-instances --instance-ids <instance_id>

インスタンスが停止すると、2つの電子メールを受信するはずです。 1つは「stopping」状態で、もう1つはインスタンスが完全に停止したときのメールです。

{
  }
  "version":"0",
  "id":"2d2fa149-b1b6-23ad-27cd-15fdc00d4ff2",
  "detail-type":"EC2 Instance State-change Notification",
  "source":"aws.ec2",
  "account":"998335703874",
  "time":"2019-10-14T14:06:15Z",
  "region":"eu-west-3",
  "resources":[
     "arn:aws:ec2:eu-west-3:998335703874:instance/i-073cf4770bed5d313"
  ],
  "detail":{
    "instance-id":"i-073cf4770bed5d313",
    "state":"stopped"
  }

CloudWatchが提供するさまざまな構成を使用して、いくつかのユースケースを実装できます。 たとえば、AWS Lambda関数を追加して、変更が発生したときに送信されるデータを処理、変換、分析し、これにより、カスタムアクションを指定してトリガーできます。 SNSをSlackチームチャットに接続して、同じSNSにアラームを公開することもできます。

4. CloudWatchログ

メトリクスと同様に、システムの制御性と可観測性を高めたい場合、ログは重要です。 CloudWatchを使用して、ログを監視、保存、アクセス、クエリ、分析、視覚化できます。 CloudWatchは、スケーラブルなサービスで使用するすべてのリソースとAWSサービスからのログを一元化しています。 たとえば、Webアプリケーションのアクセスログを保存して、保持期間を10年に調整できたり、システムログを保存することもできます。これは、ホストマシンにログを保持したくない場合や、インフラストラクチャが不変である場合に最適です。

4.1 Twelve Factor-AppとCloudWatch

ログをイベントストリームとして扱うということは、Herokuによって開発された12要素アプリの原則の1つです。

AWS CloudWatch Logsの哲学を受け入れ、この原則を実装していくと、ログをイベントストリームとして扱うと役立ちます。

4.2 CloudWatch Logsエージェントの使用

CloudWatch Logsを使用してシステムログ（syslog）のストリームを作成したいので、EC2マシンにエージェントをインストールして設定する必要があります。

curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O 
sudo python ./awslogs-agent-setup.py --region eu-west-3

インストールが完了すると、インタラクティブなセットアップが開始されます。

Step 3 of 5: Configuring AWS CLI ...
AWS Access Key ID [None]: xxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [eu-west-3]:
Default output format [None]:
Step 4 of 5: Configuring the CloudWatch Logs Agent ...
Path of log file to upload [/var/log/syslog]:
Destination Log Group name [/var/log/syslog]:

少なくともこれらのアクションを実行する機能を持つIAM認証情報を設定してください。

• logs:CreateLogGroup
• logs:CreateLogStream
• logs:PutLogEvents
• logs:DescribeLogStreams

または、このポリシーを使用するロールに添付します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
    ],
      "Resource": [
         "arn:aws:logs:*:*:*"
    ]
  }
 ]
}

上記の設定を完了して数秒すると、syslogが表示されます。

5. CloudWatchインサイト

Insights Explorerを使用すると、ログストリームをクエリできます。 下記はいくつかの有用な例です：

• 最近追加された25個のログイベント：

    fields @timestamp, @message
  
    sort @timestamp desc
  
    limit 20
  

• 5分ごとに記録されるログの例外の数：

    filter @message like /Exception/
  
    stats count(*) as exceptionCount by bin(5m)
  
    sort exceptionCount desc
  

• 例外ではないログイベントのリスト：

    fields @message
  
    filter @message not like /Exception/
  

• Lambdaレイテンシ統計を5分間隔で表示:

    filter @type = "REPORT"
  
    stats avg(@duration), max(@duration), min(@duration) by bin(5m)
  

• 送信元および宛先IPアドレス別のVPC上位10バイト転送：

    stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
  
    sort bytesTransferred desc
  
    limit 10
  

5.1 CloudWatch Logsサブスクリプション

この機能により、AWS Lambdaなどの別のサービスにサブスクライブできます。 AWS CloudWatchから別のデータストアにログデータをETL（抽出、変換、ロード）する必要がある場合は、良いユースケースです。 全文検索エンジンを使用する必要がある場合もあります。これは、サブスクリプションを使用してログをAmazon Elasticsearch Service（AES）に送信できる場合です。

CloudWatchメトリックフィルター

CloudWatchコンソールを使用して、次のセクションに示すように、ログからカスタムテキストを抽出するフィルターを作成することもできます。

5.2 CloudWatchメトリクス

メトリクスは、CloudWatchに公開される時間順に並べられたデータポイントのセットです。 カスタム指標の作成を順を追って説明し、AWSで可観測性なメトリックについて説明します。

5.3カスタムメトリック

最後の例に加えて、「kernel」という単語を含むすべてのログ行をグループ化するか、「memory」という単語をグループ化したいとします。 以前から「Create metric filter」を使用してこれを実行してみましょう。

注：この例では単純なパターンを使用していますが、AWSでは複雑なユースケースでより高度なパターンを使用できます。 パターンが複雑か単純かに関係なく、パターンを割り当てて、選択したら視覚化できます。

この実際的な例では、前に設定したsyslogストリームから「Memory」という単語をフィルタリングします。 すべてが正常に機能していることを確認するために、メモリの負荷テストを行います。

stress --vm 10 --timeout 200
---
stress: info: [12302] dispatching hogs: 0 cpu, 0 io, 10 vm, 0 hdd
stress: FAIL: [12306] (494) hogvm malloc failed: Cannot allocate memory

nanoマシンを使用しているので、メモリがこの種のストレステストをサポートしていないことは明らかですが、これはログをチェックして視覚化するための良い練習です。 まず、ここでメモリ障害を確認できます。

同時に、適切な構成で、ログストリーム内の「memory」ワード数を視覚化し、EC2インスタンスメモリの状態を監視できます。

5.4 AWS標準メトリクス

AWSは、デフォルトで設定されたメトリックスも公開します。メトリクスダッシュボードにアクセスすると、AWS名前空間の一部である使用可能なメトリクスを確認できます。カスタムメトリックには異なる名前空間を作成できます。メトリックを別のコンテナに分離する場合は、これをお勧めします。同時に多くのアプリケーションを管理している場合、同じフィードに集約されたさまざまなアプリのメトリックを表示したくないでしょう。

ほとんどのAWSサービスがメトリックスを公開しているという事実を考えると、CloudWatchを効果的に使用するための多くの可能性があります。これらはいくつかの一般的な例です：

• IntegrationLatency、Latency、CacheHitCount、およびCacheMissCountメトリックスを集約することにより、Amazon CloudWatchでAPI実行をモニタリングする

• ビルドの試行、成功、失敗の数をカウントし、BuildDuration、FailedBuilds、QueuedDurationなどのメトリクスを使用してAWS CodeBuildをモニタリングする

• Amazon DocumentDBメトリクスのモニタリング（ディスク使用量、レプリケーションラグ、CPU使用量、ディスクキュー深度など）。 DocumentDBは、BackupRetentionPeriodStorageUsed、Bu ff erCacheHitRatio、CPUUtilization、DatabaseConnections、DBInstanceReplicaLag、DBClusterReplicaLagMaximumなどの多くのメトリックを公開します。

6. まとめ：より良い可観測性なシステムの構築

アラーム、イベント、ログ、およびメトリックス（他のAWSサービスと組み合わせて）は、効率的な監視および監視システムを構築するために必要な柔軟性を提供します。 システムを完全に把握するには、収集および分析する必要のある情報やデータのソースが異なる場合があり、そんな時はAWS CloudWatchが役に立ちます。 CloudWatchの組み込み機能を使用して、最大のデータを収集および集約し、CloudWatchが提供するさまざまなツールを使用してデータを整理および視覚化できます。

AWS CloudWatchを使用してインフラストラクチャのメトリックを収集しているが、よりカスタマイズ可能なアラートと集計データの監視プラットフォームを探している方は、MetricFireの無料トライアルをチェックしてください。 AWSとMetricFireの互換性の詳細については、ドキュメントをご覧ください。 また、AWS CloudWatchをMetricFireと互換性のあるものにする方法について、デモを予約して直接MetricFireに相談することもできます。是非、お試しを。

それでは、またの記事で！