Category: Amazon CloudWatch*


新発表 – Amazon CloudWatch AgentとAWS Systems Managerとの連携 – 統一されたメトリクスとログの収集をLinuxとWindowsに

WindowsとLinuxのインスタンスやオンプレミスサーバから、Amazon CloudWatchにメトリクスやログファイルを送信するために利用できる、いくつものエージェント、デーモン、そしてスクリプトをこれまで紹介してきました。こうした異なるツールから収集されたデータによって、計算リソースの状態や挙動を可視化することができ、値が正常域を外れた時や問題のある可能性が見られた時にアクションを起こすこともできます。CloudWatch Dashboardsでどんな欲しいメトリクスもグラフにすることができ、CloudWatch Alarmsでアクションを起こすこともでき、CloudWatch Logsでエラーメッセージを見つけるために検索もでき、カスタムの高解像度メトリクスサポートの利点も享受することができます。

新しい統一エージェント

2017年12月14日に、我々はさらに一歩進めて、新しい統一されたCloudWatch Agentをリリースしました。これはクラウドでもオンプレミスでも、LinuxでもWindowsでも実行でき、メトリクスとログファイルを取り扱えます。デプロイするにはAWS Systems Manager (SSM) Run CommandSSM State Manager、またはCLIを利用できます。以下が、いくつかの最も重要な機能になります:

単一のエージェント – メトリクスとログの両方を単一のエージェントで収集できます。これによって、セットアップ手順を簡略化でき複雑さを減らすことができます。

複数プラットフォーム / 複数環境 – 新しいエージェントはクラウドでもオンプレミスでも実行可能で、64-bit Linuxと64-bit Windows上で動かせ、HTTPプロキシもサポートしています。

設定可能 – 新しいエージェントは自動的に最も役に立つシステムメトリクスを取得します。さらに、CPUスレッド、マウントしたファイルシステム、そしてネットワークインタフェースといった、より詳細なメトリクスやサブリソースを数百集めることもできます。

CloudWatch親和性 – 新しいエージェントは標準の1分間隔メトリクスも、新しい1秒間隔の高解像度メトリクスもサポートしています。インスタンスID、イメージID、Auto Scaling Group名等のEC2のディメンジョンを自動的に含めてくれますし、カスタムディメンジョンの利用もサポートしています。全てのディメンジョンを使って、Auto Scaling Groupやアプリケーションにまたがった集約が可能です。

移行 – 既存のAWS SSMとEC2Configの設定から、簡単に新しいエージェントを使う様に移行することができます。

エージェントをインストールする

CloudWatch AgentはEC2インスタンスで動く場合にはIAM roleを使い、オンプレミスサーバで動く場合にはIAM userを使います。roleもしくはuserはAmazonSSMFullAccessAmazonEC2ReadOnlyAccessポリシーを持っている必要があります。以下が私のroleです:

これを既に実行中のインスタンスに簡単に追加できます (これは比較的新しいEC2の非常に便利な機能です):

SSM Agentをインスタンス上で既に実行しています。もしまだであれば、SSM エージェント をインストールし設定するの手順に従ってセットアップします。

次に、AWS Systems Managerを使ってCloudWatch Agentをインストールします:

これは数秒で終わります。これで、簡単なウィザードを使ってエージェントの設定ファイルをセットアップします:

ウィザードでは監視するログファイルのセットアップもできます:

ウィザードはJSON形式の設定ファイルを生成し、インスタンス上に保存します。その後、他のインスタンスへのデプロイを可能にするためにParameter Storeへのアップロードをするかどうかの選択肢を聞いてきます(ファイルを編集することでもっと詳細なメトリクスとログ収集の設定も可能です):

これでRunCommandを使いParameter Storeの設定名を与えて、CloudWatch Agentを起動することができます。

これは数秒で終わり、エージェントはすぐにメトリクスを送信開始します。先に述べた通り、エージェントはインスタンスの中やアタッチされたリソースの詳細なメトリクスを送信可能です。た取れば、以下は各ファイルシステムのメトリクスです:

監視しているログファイル毎に、各インスタンスで別々のlog streamがあります:

他のlog streamでできることと同様に、ログを見たり検索することができます:

今から利用可能です

新しいCloudWatch Agentは全てのパブリックAWSリージョンで利用可能です。AWS GovCloud (US)と中国内のリージョンは今後リリースしていきます。

エージェントには全く料金はなく、通常のCloudWatchのログとカスタムメトリクスの料金をお支払頂くだけです。

Jeff;

原文: New – Amazon CloudWatch Agent with AWS Systems Manager Integration – Unified Metrics & Log Collection for Linux & Windows (翻訳: SA岩永)

Amazon CloudWatch における高解像度メトリクスとアラーム

Amazon CloudWatch は 2009 年以来 AWS の重要な要素となっています。3 つの同時リリース (Auto ScalingElastic Load Balancing) の 1 つとして公開された CloudWatch は、AWS リソースや AWS クラウドで実行するアプリケーションをモニタリングする非常に強力なサービスに進化しました。CloudWatch カスタムメトリクス (2011 年にリリース) は CloudWatch でビジネスおよびアプリケーションメトリクスを保存できるようにし、グラフ表示や CloudWatch アラームをベースにアクションを開始することができます。数年間に渡り CloudWatch にいくつもの強化点を施してきたことは言うまでもありません。最近ではメトリクス保存期間の延長 (およびユーザーインターフェイスの更新)、ダッシュボードダッシュボードでの API/CloudFormation のサポートダッシュボードにアラームなどを追加してきました。

最初はメトリクスを 5 分間隔で保存していましたが、ユーザーから寄せられたリクエストに応え、2010 年にこれを 1 分間隔に変更しました (詳細モニタリング)。これについては高い評価を頂きましたが、そろそろレベルアップさせる時期が来ました。AWS をご利用されているお客様は 1 日に多数の動画をストリーミングしたり、フラッシュセールを行ったり、コードをいくつもデプロイしたりしています。さらに、状況が変わるに連れてすばやくスケールインまたはスケールアウトするアプリケーションも実行しています。こうした様々な状況において 1 分間隔では詳細性に欠けることになります。また、重要で一時的な増加を見逃してしまう可能性もあります。異種 (でありながら関連性のある) イベントを時間と関連付けるのは困難です。何か支障があった場合の MTTR (mean time to repair – 平均修復時間) に時間が掛かることもあるでしょう。

新しい高解像度のメトリクス
本日、高解像度のカスタムメトリクスを対象とするサポートを追加しました。また、今後 AWS サービスのサポートを追加することも計画しています。アプリケーションが 1 秒の解像度で CloudWatch にメトリクスを発行できるようになりました。発行後、数秒でメトリクスを画面で見ることができるほか、10 秒ごとに評価する高解像度の CloudWatch アラームをセットアップできます。

使用可能なメモリが低下するとアラームが起動すると想像してください。これは通常、頻度が低いサンプルではキャッチしにくい一時的な状態です。高解像度のメトリクスでは、数秒内に閲覧、検出 (アラームを使用)、対応することができます。

この場合、右側のアラームが開始しないので問題に気付くことがありません。

高解像度メトリクスの発行
高解像メトリクスを発行するには 2 つの方法があります。

  • APIPutMetricData 関数が StorageResolution パラメーターを許可するようになりました。このパラメーターを 1 に設定して高解像度メトリクスを発行します。スタンダードの 1 分間の解像度で発行するにはこれを排除 (または 60 に設定) します。
  • collectd プラグイン – 高解像度メトリクスのコレクションと発行をサポートするように collectd の CloudWatch プラグインを更新しました。そのため、 enable_high_definition_metrics パラメーターをプラグインの config ファイルで設定する必要があります。

解像度はメトリクスが古くなるに連れて低下するので、CloudWatch は徐々にロールアップするようになっています。スケジュール詳細は次の通りです。

  • 1 秒に設定したメトリクスは 3 時間使用可能です。
  • 60 秒に設定したメトリクスは 15 日間使用可能です。
  • 5 分に設定したメトリクスは 63 日間使用可能です。
  • 1 時間に設定したメトリクスは 455 日間使用可能です (15 か月)。

FIFO キューに対して GetMetricStatistics 高解像度メトリクスでは期間を 1、5、10、30 または 60 秒の倍数に指定することができます。標準メトリクスでは期間を 60 秒の倍数に指定することができます。

簡単なデモをお見せします
一番近い EC2 インスタンスを取得し collected および Python プラグインの最新バージョンをインストールします。

$ sudo yum install collectd collectd-python

次にプラグインのセットアップスクリプトをダウンロードし、実行可能にしてから実行します。

$ wget https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py
$ chmod a+x setup.py
$ sudo ./setup.py

前もって適切な IAM ロールを作成済みなので、これをインスタンスに追加します。これはセットアップ中、自動的に検出されました。高解像度メトリクスを有効にするように促されます。

collectd が実行され、発行メトリクスが数秒で開始しました。CloudWatch コンソールを開き様子を見ます。

ズームインしてメトリクスの詳細を見ます。

memory.percent.used メトリクスを 10 秒間隔でチェックするアラームも作成します。これにより、短期間に大量のメモリがどこで使用されているか検出しやすくなります。

提供開始
高解像度のカスタムメトリクスやアラームはパブリック AWS リージョンで今すぐご利用いただけます。AWS GovCloud (US) でのサポートも近日中に提供する予定です。

従来通り、追加料金なしに毎月 10 件までのメトリクスを保存することができます。詳しくは「CloudWatch 料金表 (CloudWatch Pricing)」のページをご覧ください。高解像度メトリクスの料金は標準解像度メトリクスと同様です。より多くのメトリクスを使用すると、ボリューム層ベースで節約 (メトリクスごと) することができます。高解像度アラームの料金は 1 か月あたり各アラーム 0.30 USD です。

新機能 – Amazon CloudWatch ダッシュボードでの API と CloudFormation のサポート

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。

新しい API および CLI
コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、AWS CloudFormation のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。4 つの新しい API 関数 (および同等の CLI コマンド) があります。

ListDashboards / aws cloudwatch list-dashboards – アカウント内のすべてのダッシュボードのリスト、または共通のプレフィックスを共有するサブセットを取得します。

GetDashboard / aws cloudwatch get-dashboard – 1 つのダッシュボードの詳細を取得します。

PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボードを作成するか、既存のダッシュボードを更新します。

DeleteDashboards / aws cloudwatch delete-dashboards – 1 つ以上のダッシュボードを削除します。

ダッシュボードの概念
これらの関数とコマンドの使用方法を説明したいと思います。詳細な説明に移る前に、ダッシュボードの重要な概念と属性のいくつかを示します。

グローバル – ダッシュボードは AWS アカウントの一部であり、特定の AWS リージョンとは関連付けられていません。各アカウントは最大 500 個のダッシュボードを持つことができます。名前が付けられる – 各ダッシュボードには、AWS アカウント内で一意の名前があります。名前の長さは最大 255 文字です。グリッドモデル – 各ダッシュボードはセルのグリッドで構成されます。グリッドは全体で 24 個のセルで、必要なだけ高くすることができます。ダッシュボードの各ウィジェットはグリッド座標の特定のセットに配置され、整数値の数のグリッドセルにまたがるサイズです。ウィジェット (視覚化) – 各ウィジェットは、テキストまたは CloudWatch メトリクスのセットを表示できます。テキストは Markdown を使って指定し、1 つの値、折れ線グラフ、または積み上げ棒グラフとして表示できます。各ダッシュボードは最大 100 個のウィジェットを持つことができます。メトリクスを表示するウィジェットは、CloudWatch アラームと関連付けることもできます。ダッシュボードには、コンソール内から表示および編集できる JSON 表現があります。[Actions] メニューをクリックして、[View/edit source] を選択します。

ダッシュボードのソースは以下のとおりです。

この JSON は、実際のアプリケーションを構築する際の参考にしてください。ご覧のとおり、ダッシュボードの各ウィジェットに対して widgets 配列にエントリがあります。各エントリは、タイプ、位置、サイズで始まる 1 つのウィジェットを示します。

API を使用したダッシュボードの作成
特定のリージョンの各 EC2 インスタンスに対するウィジェットがあるダッシュボードを作成するとします。Python および AWS SDK for Python を使用して、次のように開始します (私のコードの未熟さはご容赦ください)。

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

次にインスタンスを反復処理し、それぞれに対して widget ディクショナリを作成し、それを widgets 配列に追加します。

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

位置 (xy) をループ内で更新し、グリッドを作成します (位置を指定しない場合、ウィジェットは左から右へ、上から下へレイアウトされます)。

        x += width
        if (x + width > max_width):
            x = 0
            y += height

すべてのインスタンスを処理した後で、ウィジェット配列の JSON バージョンを作成します。

body   = {'widgets' : widgets}
body_j = json.dumps(body)

そして、ダッシュボードを作成または更新します。

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

コードを実行すると、次のダッシュボードが作成されます。

CloudWatch チームは、プログラムで作成されるダッシュボードにはテキストウィジェットを含め、ダッシュボードが自動生成されたことと、その操作を実行したソースコードまたは CloudFormation テンプレートへのリンクを含めることを推奨しています。つまり、ダッシュボードに対して手動の帯域外チェンジャーを実行しないことを推奨しています。前述したように、各メトリクスウィジェットは CloudWatch アラームと関連付けることもできます。アラームは、プログラムで作成するか、サンプル CPU 使用率アラーム などの CloudFormation テンプレートを使用して作成できます。これを行うように決定した場合、アラームのしきい値がウィジェットに表示されます。この詳細については、Tara Walker の最近の投稿「Amazon CloudWatch Launches Alarms on Dashboards」を参照してください。さらに一歩先に進んで、CloudWatch イベントと Lambda 関数を使って特定のリソースの作成と削除を追跡し、変更に合わせてダッシュボードを更新することができます。この方法については、「Keeping CloudWatch Dashboards up to Date Using AWS Lambda」を参照してください。

CLI を使用したダッシュボードへのアクセス
コマンドラインからダッシュボードにアクセスして操作することもできます。たとえば、シンプルなリストを生成できます。

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

そして、Disk-Metrics ダッシュボードを削除できます。

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

ダッシュボードを定義する JSON を取得することもできます。

 

CloudFormation を使用したダッシュボードの作成
ダッシュボードは、CloudFormation テンプレートで指定することもできます。YAML 形式のシンプルなテンプレートを示します ( DashboardBody が依然として JSON で指定されています)。

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

テンプレートをファイルに配置し、コンソールまたは CLI を使用してスタックを作成します。

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

ダッシュボードを次に示します。

ご利用可能
この機能は今すぐ利用できます。本日から使い始めることもできます。ダッシュボードあたり最大 50 メトリクスを持つ 3 つのダッシュボードを無料で作成できます。追加のダッシュボードの料金は、CloudWatch 料金表ページに示すように、1 か月あたり 3 USD です。毎月新しい API 関数に対して最大 100 万回の呼び出しを無料で実行できます。それを超えた場合の料金は、1,000 回の呼び出しごとに 0.01 USD です。

Jeff;

Amazon CloudWatch LogsとMonologを使用したPHPアプリケーションログ

ロギングとデバッグ情報は、さまざまな角度からアプローチできます。アプリケーションフレームワークを使用する場合でも、一からコーディングする場合でも、異なるプロジェクト間で使い慣れたコンポーネントやツールを使用することは常に快適です。今回の例では、PHPアプリケーションからのログを、Amazon CloudWatch Logsに出力させます。これを実現するために、すでに普及しよく利用されている標準に準拠した既存のソリューションを使いたいと思っていました。これらの理由からオープンソースのログライブラリであるPHP Monolog(https://github.com/Seldaek/monolog)を使用します。

PHP Monolog

新しいPHPアプリケーション、フレームワーク、またはサービスを扱う人にとって、ソリューション間で頻繁に現れる技術の選択肢の1つとしてアプリケーションログ用のMonologを利用することが挙げられます。PHP Monologは標準に準拠したPHPライブラリで、開発者はデータベース、ファイル、ソケット、さまざまなサービスなどのさまざまな種類のフォーマットにログを送信できます。PHP MonologはPSR-3で定義されたPHPロギングの標準化よりも前に、PSR-3のインターフェースと標準を実装していました。これにより、Monologはロギングライブラリ用の共通インタフェースに準拠しています。CloudWatch LogsでMonologを使用すると、PSR-3互換ロギングソリューションが作成されます。Monologは、Laravel、Symfony、CakePHPなど多くの異なるアプリケーションやフレームワークで使用できます。今日の例は、アプリケーションログの目的で、PHP Monologを使用してCloudWatchLogsに情報を送信し、CloudWatchのアラームと通知でアプリケーションデータを使用できる構造とプロセスを構築することです。これにより、アプリケーションからのログをキーにAmazon EC2 AutoScalingのようなサービスのアクションに使用することができます。

Amazon CloudWatch Logs

顧客第一主義の組織として、AWSはお客様やAWSパートナーが要望する重要な機能やサービスを絶えず構築し、リリースしています。本日、ハイライトされるサービスの1つがAmazon CloudWatch Logsです。CloudWatch Logsを使用すると、アプリケーション、オペレーティングシステムおよびインスタンス、AWSサービス、およびその他のさまざまなソースからのログファイルの情報を保存できます。以前のブログ記事では、CloudWatch Logsをさまざまなプログラミング例とともに紹介しました。

ブログ記事にはCloudWatch Logsを使用してアプリケーションからのエントリを保存するPHPの例があります。この例を使用してスタンドアロンソリューションとして拡張し、アプリケーション内からCloudWatch Logsにログを送ることができます。この例では、PHP Monologを活用してこの機能を強化します。

Monologの実装

Monologを使用開始するには、Composer(https://getcomposer.org/)を使用して必要なライブラリをインストールします。以下の手順では、AWS SDK for PHP、PHP Monologおよび CloudWatch Logsへのログを有効にするMonologのアドオンをインストールします。

curl -sS https://getcomposer.org/installer | php 
php composer.phar require aws/aws-sdk-php 
php composer.phar require monolog/monolog 
php composer.phar require maxbanton/cwh:^1.0

あるいは、次のエントリをcomposer.jsonファイルにコピーし、php composer.phar installコマンドでインストールすることもできます。

{
    "minimum-stability": "stable",
    "require": {
        "aws/aws-sdk-php": "^3.24",
        "aws/aws-php-sns-message-validator": "^1.1",
        "monolog/monolog": "^1.21",
        "maxbanton/cwh": "^1.0"
    }
}
Local logging

PHP Monologが利用できるようになったので、それを実装しテストすることができます。まず、1ファイルにロギングする例を示します。

require "vendor/autoload.php";

use Monolog\Logger;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\StreamHandler;

$logFile = "testapp_local.log";

$logger = new Logger('TestApp01');
$formatter = new LineFormatter(null, null, false, true);
$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($formatter);
$logger->pushHandler($infoHandler);
$logger->info('Initial test of application logging.');

前の例では、先ほどインストールしたコンポーザーライブラリが必要です。新しいロガーラインは「TestApp01」として、チャンネル名を設定します。次の行は、未使用のログ項目の括弧を削除する新しいLineFormatterを作成します。次の行は、識別されるファイル名として先を確立しtestapp_local.log、およびINFOログレベルでそれを関連付けます。次に、ストリームハンドラにフォーマットを適用します。次に、更新された形式のストリームハンドラをハンドラリストに追加します。最後に、INFOというログレベルで新しいメッセージが記録されます。ログレベルとハンドラの詳細については、Monolog GitHubページIETF RFC 5424およびPSR-3を参照してください。

機能を確認するために、ログファイルの内容を表示できるようになりました:

Syslog logging

シンプルなログエントリをローカルファイルに書き込むことができたので、次の例ではシステムのSyslogを使用してイベントを記録しています。

$logger = new Logger($appName);

$localFormatter = new LineFormatter(null, null, false, true);
$syslogFormatter = new LineFormatter("%channel%: %level_name%: %message% %context% %extra%",null,false,true);

$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($localFormatter);

$warnHandler = new SyslogHandler($appName, $facility, Logger::WARNING);
$warnHandler->setFormatter($syslogFormatter);

$logger->pushHandler($warnHandler);
$logger->pushHandler($infoHandler);

$logger->info('Test of PHP application logging.');
$logger->warn('Test of the warning system logging.');

syslogメッセージのフォーマットが$syslogFormatterという値で変更されていることがわかります。syslogは各ログエントリに日付/時刻を挿入するので、これらの値をログテキストに含める必要はありません。syslog機能はlocal0に設定され、すべてのWARNINGメッセージはsyslogにともに送信され、INFOレベルのメッセージとWARNINGレベルのメッセージはローカルファイルに記録されます。Syslog機能とログレベルに関する追加情報は、Syslog Wikipediaのページを参照してください。

Logging to CloudWatch Logs

Monologの基本的な使い方を見てきたので、いくつかのログをCloudWatch Logsに送りましょう。Monologライブラリ用のAmazon Web Services CloudWatch Logs Handlerを使用して、MonologをCloudWatch Logsに統合することができます。この例では、認証アプリケーションによってログ情報が生成されます。

use Aws\CloudWatchLogs\CloudWatchLogsClient;
use Maxbanton\Cwh\Handler\CloudWatch;
use Monolog\Logger;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\StreamHandler;
use Monolog\Handler\SyslogHandler;

$logFile = "testapp_local.log";
$appName = "TestApp01";
$facility = "local0";

// Get instance ID:
$url = "http://169.254.169.254/latest/meta-data/instance-id";
$instanceId = file_get_contents($url);

$cwClient = new CloudWatchLogsClient($awsCredentials);
// Log group name, will be created if none
$cwGroupName = 'php-app-logs';
// Log stream name, will be created if none
$cwStreamNameInstance = $instanceId;
// Instance ID as log stream name
$cwStreamNameApp = "TestAuthenticationApp";
// Days to keep logs, 14 by default
$cwRetentionDays = 90;

$cwHandlerInstanceNotice = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameInstance, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::NOTICE);
$cwHandlerInstanceError = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameInstance, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::ERROR);
$cwHandlerAppNotice = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameApp, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::NOTICE);

$logger = new Logger('PHP Logging');

$formatter = new LineFormatter(null, null, false, true);
$syslogFormatter = new LineFormatter("%channel%: %level_name%: %message% %context% %extra%",null,false,true);
$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($formatter);

$warnHandler = new SyslogHandler($appName, $facility, Logger::WARNING);
$warnHandler->setFormatter($syslogFormatter);

$cwHandlerInstanceNotice->setFormatter($formatter);
$cwHandlerInstanceError->setFormatter($formatter);
$cwHandlerAppNotice->setFormatter($formatter);

$logger->pushHandler($warnHandler);
$logger->pushHandler($infoHandler);
$logger->pushHandler($cwHandlerInstanceNotice);
$logger->pushHandler($cwHandlerInstanceError);
$logger->pushHandler($cwHandlerAppNotice);

$logger->info('Initial test of application logging.');
$logger->warn('Test of the warning system logging.');
$logger->notice('Application Auth Event: ',[ 'function'=>'login-action','result'=>'login-success' ]);
$logger->notice('Application Auth Event: ',[ 'function'=>'login-action','result'=>'login-failure' ]);
$logger->error('Application ERROR: System Error');

 

この例では、アプリケーション認証イベントはPHP配列として渡され、JSONとしてCloudWatch Logsに表示されます。login-successおよびlogin-failureの結果を伴うイベントは、インスタンスIDに関連付けられたログストリームと、アプリケーション名に関連付けられたログストリームの両方に送信されます。

 

これらの異なるストリームの場所を使用して、インスタンスごとまたはアプリケーションごとにメトリックとアラームを作成できます。過去5分間にアプリケーションにログインしたユーザーの総数に対するメトリックを作成するとします。イベント・グループを選択し、メトリック・フィルターの作成を選択します。

次のページでは、フィルタとテストを同じウィンドウで作成できます。フィルタデータについては、ログエントリのJSON文字列を使用します。すべての正常なログインを抽出するには、次の文字列を入力します。

{ $.result = login-success }

下記のように、フィルタの詳細が表示されます。フィルタ名を識別しやすい値に変更しました。メトリック名前空間にはアプリケーション名に関連付けられた値があり、メトリック名にはログイン成功数が反映されます。

CloudWatch Logsを介して受け取ったこの情報に基づいて、アラームを作成して通知を送信したり、(Amazon EC2スケーリングの決定などの)アクションとることができます。

これらの値を使用すると、5分以内に50回以上ログインが成功するたびに警告が表示されます。

Laravel logging

Monologは、一般的なLaravel PHPフレームワークを含む多くのPHPアプリケーションとフレームワークのロギングソリューションとして使用されています。この例では、Laravel内でMonolog with CloudWatch Logsの使用を示します。最初のステップは、Laravelアプリケーションの現在のログ設定を調べることです。アプリケーションルート内でconfig/app.phpを開くと、さまざまなログ設定が表示されます。デフォルトでは、Laravelはデバッグのベースラインログレベルを使用して単一のログファイルにログするように設定されています。

次に、ここからの説明と例を使用して、Laravel内のサービスプロバイダとしてAWS SDK for PHPを追加します。

また、CloudWatchログのMonologライブラリをcomposer.jsonファイルに追加して、アプリケーションに含めることもできます(図を参照)。

これで、現在のLaravel Monolog構成をカスタム構成で拡張する必要があります。この手順の詳細は、Laravel Error and Loggingページを参照してください。以下は、bootstrap/app.phpファイルへの追加例です。

use Maxbanton\Cwh\Handler\CloudWatch;

$app->configureMonologUsing( function($monolog) {

    $cwClient = App::make('aws')->createClient('CloudWatchLogs');
    $cwGroupName = env('AWS_CWL_GROUP', 'laravel-app-logs');
    $cwStreamNameApp = env('AWS_CWL_APP', 'laravel-app-name');
    $cwTagName = env('AWS_CWL_TAG_NAME', 'application');
    $cwTagValue = env('AWS_CWL_TAG_VALUE', 'laravel-testapp01');
    $cwRetentionDays = 90;
    $cwHandlerApp = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameApp, $cwRetentionDays, 10000, [ $cwTagName => $cwTagValue ] );

    $monolog->pushHandler($cwHandlerApp);
});

テスト目的のために、routes/web.phpのテストルートにロギングコールを追加します。

Route::get('/test', function () {
    Log::warning('Clicking on test link!!!');
    return view('test');
});

テストルートが呼び出されると、ログはCloudWatch Logsに表示されるようになりました。

結論

この例では、PHP Monologを使用してローカルファイル、syslogおよびCloudWatch Logsにログを書き込む方法を紹介しました。また、一般的なPHPアプリケーションフレームワーク内で、MonologとCloudWatch Logsの統合を実施しました。最後に、CloudWatch Logsメトリックフィルタを作成し、CloudWatch Alarmsに適用して、ログからのデータを通知とともにスケーラビリティの決定とともに実行可能にする方法をご紹介しました。CloudWatch Logsは、PHPアプリケーションの集中的にロギング機能を提供し、Monologと組み合わせることで、確立されたプロジェクトやカスタムエンゲージメント内で使用するライブラリの可用性を保証します。
(翻訳はSA 森が担当しました。原文はこちら)

Amazon EC2インスタンスにホストベースの侵入検知システムアラートの監視方法

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。

このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service(Amazon ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL(Access Control List)またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。

ソリューションの概要
次の図は、この記事のソリューションの概要を示しています。

ソリューションの仕組みは次のとおりです。

1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。
2. CloudWatch Logs グループはにアラートがイベントとして送信されます。
3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。
4. Amazon ESにはログに記録されたアラートデータがロードされます。
5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。

デプロイ時の考慮事項

この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC(Virtual Private Cloud)サブネットを識別する必要があります。

デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。

Cloud Formation テンプレートは選択したリージョンで、下記の流れで展開されます。

1. CloudWatch LogsにアクセスするためのAWS Identity and Access Management(IAM)ロールが作成され、Amazon Linuxを実行する2つのEC2インスタンスにアタッチされます。注:サンプルHIDSアラートデータを提供するために、2つのEC2インスタンスが自動的に構成され、シミュレートされたHIDSアラートをローカルに生成します。
2. OSSEC、CloudWatch Logsエージェント、およびテスト環境で使用される追加パッケージをインストールして設定します。
3. ターゲットのHIDS Amazon ESドメインを作成します。
4. ターゲットのHIDS CloudWatch Logsグループを作成します。
5. Amazon ESにHIDSアラートを送信するために、Lambda関数とCloudWatch Logsサブスクリプションを作成します。

CloudFormationスタックがデプロイされた後、Amazon ESドメインのKibanaインスタンスにアクセスして、テスト環境のセットアップの最終ステップを完了することができます。これについては後で説明します。

このブログの投稿の範囲外にはなりますが、既存のEC2環境にOSSECを導入する場合は、監視対象のログファイル、完全性チェック用のディレクトリ、アクティブな応答など、必要な構成を決定する必要があります。通常、環境の最適化のためにシステムのテストとチューニングに時間を要すことがほとんどです。 OSSECのドキュメントは、このプロセスに慣れ始めるのに適しています。エージェントのインストールと別のOSSECマネージャを使用してイベントを一元的に処理してからCloudWatch Logsにエクスポートするという、OSSECの展開には別のアプローチをとることもできます。この展開では、エージェントとマネージャの間に追加のサーバーコンポーネントとネットワーク通信が必要です。 Windows ServerはOSSECでサポートされていますが、エージェントベースのインストールが必要なため、OSSECマネージャが必要です。 OSSECのアーキテクチャと展開オプションの詳細については、「OSSECアーキテクチャ」を参照してください。

ソリューションのデプロイ
手順の概要は次のとおりです。

1. CloudFormationスタックを起動します。
2. Kibanaのインデックスパターンを設定し、アラートの探索を開始します。
3. Kibana HIDSダッシュボードを設定し、アラートを視覚化します。

1. CloudFormationスタックの起動

CloudFormationテンプレートを使用して、プロビジョニングプロセスを自動化しテスト環境を起動します。次の入力パラメータでは、展開のためにターゲットVPCとサブネット(インターネットアクセスが必要)を識別する必要があります。ターゲットサブネットがインターネットゲートウェイを使用する場合は、AssignPublicIPパラメーターをtrueに設定します。ターゲットサブネットがNATゲートウェイを使用する場合は、AssignPublicIPのデフォルト設定をfalseのままにしておきます。

まず、デプロイしたリージョンにあるS3バケットにLambda Function 展開パッケージを配置する必要があります。これを行うには、圧縮された展開パッケージをダウンロードし、同じリージョンバケットにアップロードします。 S3へのオブジェクトのアップロードの詳細については、「Amazon S3へのオブジェクトのアップロード」を参照してください。

また、スタックの作成後に環境にアクセスするための信頼できる送信元IPアドレスまたはCIDRブロックと、インスタンスに関連付けるEC2キーペアを提供する必要があります。 EC2キーペアの作成については、「Amazon EC2を使用したキーペアの作成」を参照してください。また、信頼できるIPアドレスまたはCIDRブロックは、Kibanaアクセス用にAmazon ESアクセスポリシーの自動作成のために使用されます。すべてのIPv4アドレスがインスタンスにアクセスできるようにする0.0.0.0/0を使用するのではなく、特定のIPアドレスまたはCIDR範囲を使用することをお勧めします。インスタンスへのインバウンドトラフィックの認可の詳細については、「Linuxインスタンスのインバウンドトラフィックの認可」を参照してください。

入力パラメータを確認したら(詳細は次のスクリーンショットと表を参照)、CloudFormationスタックを作成します。

Input parameter インプット パラメータの説明
1. HIDSInstanceSize テストサーバーのEC2インスタンスサイズ
2. ESInstanceSize Amazon ESインスタンスのサイズ
3. MyKeyPair デプロイ後にインスタンスに安全に接続できる公開鍵/秘密鍵のペア
4. MyS3Bucket ZIP展開パッケージを使用したS3バケット
5. MyS3Key ZIP展開パッケージ用の領域内のS3キー
6. VPCId ソリューションを展開するAmazon VPC
7. SubnetId 選択したVPC内のアウトバウンド接続を持つサブネットID(インターネットアクセスが必要)
8. AssignPublicIP サブネットがインターネットゲートウェイ経由で接続するように設定されている場合はtrueに設定します。サブネットがNATゲートウェイ経由で接続するように設定されている場合はfalseに設定されます
9. MyTrustedNetwork EC2インスタンスおよびAmazon ESエンドポイントへのアクセスをホワイトリストに登録するために使用される信頼できるソースIPまたはCIDRブロック

CloudFormationスタックの作成を継続するには:

1. 入力パラメータを入力して、次へを選択します。
2. 「オプション」ページで、デフォルトを受け入れて「次へ」を選択します。
3. レビューページで詳細を確認し、AWS CloudFormationがIAMリソースを作成する可能性があることを確認します。チェックボックスをオンにし、作成を選択します。 (スタックは約10分で作成されます)。

スタックを作成したら、CloudFormation OutputsタブのHIDSESKibanaURLをメモしてください。そして次のKibanaの設定手順に進みます。

2.Kibanaのインデックスパターンを設定し、アラートの調査を開始
このセクションでは、Kibanaの初期セットアップを実行します。 Kibanaにアクセスするには、CloudFormationスタック出力(前のセクションを参照)でHIDSESKibanaURLを見つけて選択します。これにより、Amazon ESインスタンスに自動的にプロビジョニングされるKibanaインスタンスが表示されます。 CloudFormation入力パラメータで指定したソースIPを使用して、Amazon ESアクセスポリシーが自動的に設定されます。次のようなエラーが表示された場合は、Amazon ESのアクセスポリシーが正しいことを確認する必要があります。

{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: hids-alerts"}

Amazon ESドメインへのアクセスを保護する方法の詳細については、「Amazon Elasticsearchサービスドメインへのアクセスを制御する方法」を参照してください。

OSSEC HIDSアラートは現在Amazon ESに処理されています。 Kibanaを使用してアラートデータをインタラクティブに分析するには、Amazon ESで分析するデータを識別するインデックスパターンを設定する必要があります。索引パターンに関する追加情報は、Kibanaのドキュメントを参照してください。
インデックス名またはパターン ボックスに「cwl-2017.*」と入力します。インデックスパターンは、ラムダ関数内でcwl-YYYY.MM.DDとして生成されるため、月と日のワイルドカード文字を使用して2017のデータと一致させることができます。Time-field nameドロップダウンリストから@timestamp を選択し作成します。


Kibanaでは、ディスカバーペインを選択して、作成されているアラートを表示できるようになりました。リアルタイムに近いアラートの表示のリフレッシュレートを設定するには、右上の時間範囲(Last 15 minutesなど)を選択します。

自動更新を選択し、5秒などの間隔を選択します。

Kibanaでは、設定した時間枠内で5秒間隔で自動更新するように設定する必要があります。次のスクリーンショットに示すように、アラートがカウントグラフとともに更新されるはずです。

EC2インスタンスはCloudFormationによって自動的に設定され、アクティビティをシミュレートして次のようないくつかのタイプのアラートを表示します。

  • 成功したsudoからROOT実行 :Linuxのsudoコマンドが正常に実行されました。
  • Webサーバー400のエラー・コード : サーバーは、クライアント エラー(形式が不適切な要求構文、サイズが大きすぎる、無効なリクエスト・メッセージ・フレーミング、不正なリクエスト・ルーティングなど)によりリクエストを処理できません。
  • SSHのセキュアでない接続試行(スキャン) : SSHリスナーへの無効な接続試行。
  • ログインセッションが開かれました : システムでログインセッションが開かれました。
  • ログインセッションが閉じられました : システムのログインセッションが閉じられました。
  • 新しいYumパッケージがインストールされています : パッケージがシステムにインストールされています。
  • Yumパッケージが削除されました : パッケージがシステムから削除されました。

次のスクリーンショットに示すように、いくつかのアラートフィールドを詳しく見ていきましょう。

上記番号付きアラートフィールド(スクリーンショット)は、次のように定義されています

1. @log_group – ソースとなるCloudWatch Logグループ
2. @log_stream – CloudWatchログのストリーム名(InstanceID)
3. @message – ソースalerts.jsonからのJSONペイロードOSSECログ
4. @owner – アラートが発生したAWSアカウントID
5. @timestamp – Lambda関数によって適用されるタイムスタンプ
6. full_log – ソースファイルからのログイベント
7. location – ソースログファイルのパスとファイル名
8. rule.comment – 一致したOSSECルールの簡単な説明
9. rule.level – 0から16までのOSSECルール分類(詳細は、ルール分類を参照)
10. rule.sidid – 一致したOSSECルールのルールID
11. srcip – アラートをトリガした送信元IPアドレス。この場合、シミュレートされたアラートにはサーバのローカルIPが含まれています

また、Kibanaクエリーバーに検索条件を入力して、HIDSアラートデータをインタラクティブに調べることができます。たとえば、次のクエリを実行すると、ソースIPが10.10.10.10であるEC2 InstanceID i-0e427a8594852eca2のすべてのrule.level 6アラートを表示できます。

“rule.level: 6 AND @log_stream: "i-0e427a8594852eca2" AND srcip: 10.10.10.10”

シンプルテキスト、Luceneクエリ構文、またはJSONベースのElasticsearch Query DSLを使用して検索を実行できます。データの検索に関する追加情報は、Elasticsearchのドキュメントを参照してください。

3. Kibana HIDSダッシュボードの設定、アラートを視覚化

アラートの傾向とパターンを時間の経過とともに分析するには、グラフとグラフを使用してアラートデータを表現すると便利です。私はKibanaインスタンスにインポートできる基本ダッシュボードテンプレートを設定しました。

KibanaインスタンスにサンプルのHIDSダッシュボードのテンプレートを追加するには:

1. テンプレートを ローカルに保存し、Kibanaナビゲーションペインで[管理]を選択します。
2. 保存オブジェクト、インポート、およびHIDSダッシュボードテンプレートを選択します。
3. HIDSアラートダッシュボードエントリの右側にある目のアイコンを選択します。インポートされたダッシュボードに移動します。

Kibanaダッシュボードテンプレートをインポートして選択すると、次のスクリーンショットに示すように、HIDSダッシュボードが表示されます。このサンプルHIDSダッシュボードには、アラートの時間、アラートの種類、ルールレベルの内訳、上位10のルールソースID、および上位10のソースIPが含まれています。

アラートデータを詳細に調べるには、次の2つのスクリーンショットに示すように、フィルタするアラートタイプを選択します。

ソースIPアドレスや時間範囲などの基準に基づいてアラートの詳細を表示できます。 Kibanaを使用してアラートデータを視覚化する方法の詳細については、「Kibanaユーザーガイド」を参照してください。

まとめ

このブログ記事では、CloudWatch Logs を使用してOSSEC HIDSからほぼリアルタイムでアラートを収集し、CloudWatch Logsサブスクリプションを使用して、Kibanaとの分析と可視化のためにアラートをAmazon ESに渡す方法を示しました。このソリューションによってデプロイされたダッシュボードは、AWS環境における防御の深いセキュリティ戦略の一環として、EC2のセキュリティ監視を改善するのに役立ちます。

このソリューションを使用して、EC2への攻撃、異常な活動、およびエラーの傾向を検出することができます。また、システムの修復作業の優先順位付けや、VPCセキュリティグループルールVPCネットワークACLAWS WAFルールなど、追加のセキュリティコントロールを導入する場所を決定するのに役立ちます。

この投稿に関するコメントがある場合は、下の「コメント」セクションに追加してください。このソリューションの実装に関する問題や問題がある場合は、CloudWatchまたはAmazon ESフォーラムで新しいスレッドでお知らせ下さい。このソリューションのソースコードはGitHubで入手できます。 OSSEC固有のサポートが必要な場合は、「OSSECサポートオプション」を参照してください。

– Cameron (翻訳はSA酒徳が担当しました。原文はこちら:How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances)

Amazon CloudWatch がダッシュボードにアラームを追加

Amazon CloudWatch は、AWS のリソースに関するメトリックス、ログ、イベントをリアルタイムで提供および収集することで、アマゾン ウェブ サービスで実行しているアプリケーション、システム、ソリューションをモニタリングできるサービスです。CloudWatch では、リソースのレイテンシー、エラー発生率、CPU 使用率などの主要メトリックスが自動的に測定されます。さらにお客様から提供されたログやシステムデータに基づくカスタムメトリックスのモニタリングも可能です。昨年 11 月、Amazon CloudWatch に新しいダッシュボードウィジェットが追加され、すべてのメトリックスのデータを視覚化できるようになりました。CloudWatch に追加されたダッシュボードのアラームにより、お客様は AWS で実行しているソリューションやリソースの状態を把握しやすくなりました。このアラームの追加により、アラームとメトリックスを同じダッシュボードウィジェットで確認して、データに基づくトラブルシューティングと分析を行うことができます。

CloudWatch のダッシュボードは、複数のリージョンにまたがる AWS リソースを統合されたビューでモニタリングする際の可視性を高めるためのものです。CloudWatch のダッシュボードは高度にカスタマイズ可能であるため、ユーザーは独自のダッシュボードを作成して使用率、パフォーマンス、請求予定額、そして今回のアラーム状態など、さまざまなメトリックスのデータをグラフィカルに表示できます。アラームは、各メトリックスの値と指定したしきい値の関係を経時的に追跡します。アラームの状態が変わると、Auto Scaling ポリシーなどのアクションが実行されます。または、Amazon SNS に通知が送信されます。ダッシュボードにアラームを追加するという新たな方法により、CloudWatch のユーザーは、複数のリージョンにまたがって AWS のリソースやアプリケーションをモニタリングして事前にアラートを受け取る手段が増えました。さらに、ダッシュボードに追加されたアラームでは、メトリックスのデータをグラフで確認できます。アラームには次の 3 つの状態があります。

  • OK: アラームのメトリックス値はしきい値に達していない
  • INSUFFICIENT DATA: データ不足。最初にトリガされたアラームのメトリックス値は、データ不足のため、[OK] 状態か [ALARM] 状態か判定できない
  • ALARM: アラームのメトリックス値はしきい値に達している

ダッシュボードでは、[ALARM] 状態は赤、[INSUFFICIENT DATA] 状態はグレイ、[OK] 状態は無色で表示されます。ダッシュボードのアラームは、Line、Number、Stacked area の各ウィジェットで表示できます。

  • Number ウィジェット: 目的のメトリックスの最新の値をすばやく効率的に確認できます。最新のメトリックスデータに応じてアラームの状態が変わるたびに背景色が変わります。
  • Line ウィジェット: 選択したメトリックスのコレクションの実値を線グラフで表示します。ダッシュボードにアラームのしきい値と状態が水平線で示されます。この水平線を境に、しきい値に達しているかどうかが一目でわかります。
  • Stacked area ウィジェット: 選択したメトリックスのコレクションについて正味の合計結果をグラフで表示します。Stacked area ウィジェットは、メトリックスの上に別のメトリックスをロードして、メトリックスの分布と貢献度を示します。オプションとして、メトリックスの貢献度をパーセントで表示することもできます。アラームのしきい値と状態も水平線で表示されます。

現在、アラームに関連する複数のメトリックスを同じウィジェットに追加する作業が進行中です。この機能はお客様からのフィードバックに基づいて進化しています。

ダッシュボードにアラームを追加する CloudWatch
ダッシュボードでアラームを使用する方法を簡単に確認しましょう。AWS コンソールで、CloudWatch サービスに移動します。CloudWatch コンソールで、[Dashboards] を選択します。[Create dashboard] ボタンをクリックして CloudWatchBlog ダッシュボードを作成します。

CloudWatchBlog ダッシュボードを作成すると、このダッシュボードにウィジェットを追加するためのダイアログボックスが表示されます。ここでは、ウィジェットを追加する手順をスキップして、ダッシュボードにアラームを追加する手順に進むことにします。したがって、[Cancel] ボタンをクリックして、CloudWatch コンソールの [Alarms] セクションに進みます。

CloudWatch コンソールの [Alarms] セクションでは、現在のリージョンのすべてのアラームとその状態が一覧表示されます。

既に述べたように、アラームには 3 種類の状態があります。上に示したコンソールには、アラームごとに状態が表示されています。必要に応じて、コンソールのフィルタを使って状態の種類別にアラームを表示することもできます。たとえば、状態が [ALARM] のアラームだけを確認するとします。この場合は、現在のリージョンで状態が [ALARM] のアラームをフィルタで絞り込みます。

これで、現在の状態が [ALARM] になっている 2 つのアラームだけが表示されます。1 つは、Amazon DynamoDB テーブルのプロビジョニングされた書き込みキャパシティーユニットをモニタリングするためのものであり、別の 1 つは、アクティブな Amazon Elasticsearch インスタンスの CPU 使用率をモニタリングするためのものです。

CloudWatchBlog ダッシュボードをトラブルシューティング手段として利用し、Elasticsearch ソリューションとそのインスタンスの問題を特定して診断するシナリオを検討してみましょう。まず、Amazon Elasticsearch の CPU 使用率のアラームとして [ES Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームを追加するには、目的のアラーム (この例では [ES Alarm]) の横にあるチェックボックスを選択します。次に、アラームを選択した状態で、[Add to Dashboard] ボタンをクリックします。

表示された [Add to dashboard] ダイアログボックスで、CloudWatchBlog ダッシュボードを選択できます。ここで、アラームを表示するウィジェットの種類を選択することもできます。ES Alarm を Line ウィジェットで表示することにし、[Add to dashboard] ボタンをクリックして、このアラームをダッシュボードに追加します。

[ES Alarm] が [CloudWatchBlog] ダッシュボードに正常に追加されると、確認メッセージが CloudWatch コンソールに表示されます。

コンソールの [Dashboards] セクションに移動して [CloudWatchBlog] ダッシュボードを選択すると、[ES Alarm] アラームの Line ウィジェットがダッシュボードに表示されます。[ES Alarm] ウィジェットをダッシュボードの一部として保存するには、[Save dashboard] ボタンをクリックして、このウィジェットのダッシュボードへの追加を確定します。

既に説明したように、CloudWatch ダッシュボードを使用する利点の 1 つは、さまざまなリージョンからの複数のアラームをダッシュボードに追加できることです。この例では、ダッシュボードを Elasticsearch ソリューションのトラブルシューティング手段として利用しているので、このソリューションに関連するいくつかのアラームとメトリックスを [CloudWatchBlog] ダッシュボードに表示することにします。そのため、Elasticsearch インスタンス用に別のアラームを作成してダッシュボードに追加します。まず、コンソールの [Alarms] セクションに戻り、[Create Alarm] ボタンをクリックします。

[Create Alarm] ダイアログボックスが開いて、このリージョンで現在利用可能なすべてのメトリックスが表示されます。メトリックスの要約で、Elasticsearch のために 21 のメトリックスが追跡中であることを簡単に確認できます。[ES Metrics] リンクをクリックして、アラームの作成に使用できる各メトリックスを表示します。

Elasticsearch インスタンスのために表示された個別のメトリックスの中から、新しいアラームを関連付けるメトリックスを選択します。[WriteLatency] メトリックスを使うことにして、このメトリックスの横にあるチェックボックスを選択して [Next] ボタンをクリックします。

次の画面で、アラームの詳細として、名前、説明、アラームのしきい値、時間、アラームのアクションを入力します。新しいアラームの名前を ES Latency Alarm とし、他の残りのフィールドにも入力します。[Create Alarm] ボタンをクリックして、新しいアラームの作成を終了します。

アラームの追加が正常に終了すると、Alarms コンソールの上部に確認メッセージボックスが表示され、新しく作成したアラームの状態がアラームリストに表示されます。

次に、[ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームの横にあるチェックボックスを選択して [Add to Dashboard] ボタンをクリックします。

[Add to Dashboard] ダイアログボックスが開いたら、今回は [Stacked area] ウィジェットを選択します。このウィジェットを使用して [ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに表示します。[Add to Dashboard] ボタンをクリックして、[ES Latency Alarm] ウィジェットをダッシュボードに追加します。

コンソールに戻ると、ウィジェットが正常に追加されたことを確認するメッセージが表示されます。[Dashboards] セクションで [CloudWatchBlog] ダッシュボードをクリックすると、ダッシュボードに 2 つのウィジェットが表示されます。このウィジェットをダッシュボードに保存するには、[Save dashboard] ボタンをクリックします。

最後に、CloudWatch の新しい機能であるダッシュボードのアラームでは、他のリージョンのアラームやメトリックスをダッシュボードに追加して全体をトラブルシューティングの対象にすることができます。アラームウィジェットを使ってダッシュボードにメトリックスを追加してみましょう。コンソール内で、現在のリージョンである米国東部 (オハイオ) から、米国東部 (バージニア北部) リージョンに移動します。

CloudWatch コンソールの [Metrics] セクションに進みます。このセクションに、米国東部 (バージニア北部) リージョンで使用されるサービスのメトリックスが表示されます。

Elasticsearch ソリューションは、Lambda 関数をトリガーして EmployeeInfo DynamoDB データベースの CRUD (作成、読み込み、更新、削除) のすべての変更を DynamoDB ストリーム経由でキャプチャし、それらの変更を Elasticsearch ドメインである taratestdomain 内に書き込みます。したがって、DynamoDB のテーブルメトリックスを追跡するためにメトリックスを [CloudWatchBlog] ダッシュボードに追加します。

そこで、[EmployeeInfo] データベースの [ProvisionedWriteCapacityUnits] メトリックスを [CloudWatchBlog] ダッシュボードに追加します。

[Add to Dashboard] ダイアログで、[CloudWatchBlog] ダッシュボードを選択し、このメトリックスを [Number] ウィジェットで表示することを選択します。

これで、米国東部 (バージニア北部) の [ProvisionedWriteCapacityUnits] メトリックスが [CloudWatchBlog] ダッシュボードに追加され、その Number ウィジェットが米国東部 (オハイオ) のアラームと一緒にダッシュボードに表示されます。この更新をダッシュボードに保存するには、もうおわかりだと思いますが、[Save dashboard] ボタンをクリックします。

 

まとめ
ダッシュボードの開始方法は簡単です。アラームを前もってモニタリングする新たな手段としてリージョンをまたいでダッシュボードのアラームを使用し、トラブルシューティング計画を策定して、目的のメトリックスを確認できます。また、最初にメトリックス UI でメトリックスを選択し、次にメトリックスの視覚化に適したウィジェットの種類に変更することもできます。ダッシュボードのアラームは、Line、Stacked area、Number の各ウィジェットで表示できます。さらに、ダッシュボードでアラームと並んでいる Text ウィジェットを使用して、アラームの状態の変更を処理する方法に関するステップや所見を追加することもできます。

Amazon CloudWatch のウィジェットおよびその他のダッシュボードのウィジェットの詳細については、Amazon CloudWatch ドキュメントおよび CloudWatch の「開始方法」を参照してください。

Tara

アプリケーションパフォーマンスのパーセンタイルと AWS アプリケーションロードバランサーへのリクエストのトレース

本日のゲストポストでは、同僚の Colm MacCárthaigh が新しいCloudWatch パーセンタイル統計およびロードバランサーの意味と利点について語ります。 また、個別のリクエストがロードバランサーに到着した時点からその進行を追跡でき、そのリクエストがアプリケーションに繋がるための新しいリクエストのトレース機能も紹介します。

Jeff;


アプリケーションパフォーマンスのパーセンタイルメトリクス
AWS Elastic Load Balancer はすでに以前から Amazon CloudWatch メトリクスに含まれ、ロードバランサーのバックグラウンドで実行しながらインスタンスとソフトウェアのヘルス状態とパフォーマンスの可視化を提供します。たとえば、ELB はアプリケーションに送られたすべてのリクエストが負荷分散される応答時間を測定します。多くのカスタマーはアプリケーションのパフォーマンスを監視するために、ビルトインの平均と最大レイテンシーメトリクスを使用しています。また、インスタンスやコンテナを負荷の変動として追加や削除するためのきっかけとしてこういったメトリクスを使用することも一般的です。新しい CloudWatch パーセンタイルサポートに基づき、ELB Classic and Application Load Balancer(ALB) はアプリケーションの応答時間によりきめ細かなデータを提供します。こういった測定により範囲内のパフォーマンスをより正確に掴むことができます。たとえば、10 番目のパーセンタイルが 2 ミリ秒とすると、10% のリクエストは 2 ミリ秒以下かかることになり、99.9 番目のパーセンタイル値が 50 ミリ秒とすると、99.9% のリクエストは 50 ミリ秒以下かかっているという具合です。

パーセンタイルがどれだけ役に立つかという現実的な例としては、ほとんどのリクエストを 1 から 2 ミリ秒で高速キャッシュから処理するアプリケーションの場合、キャッシュが空になるとリクエストの処理はさらにずっと遅くなり、100 ミリ秒 から 200 ミリ秒の範囲までも落ちてしまいます。従来の最大メトリクスでは 200 ミリ秒台の最低速の案件のみが反映され、平均には高速と低速の回答が混合して示されることになり、どれだけのリクエストが高速または低速で処理され、そしてそれぞれがどれだけの速度であったかについての詳細はほとんど提供されませんでした。パーセンタイルメトリクスは、アプリケーションのパフォーマンスをリクエストの範囲を通して映し出し、より分かりやすい情報を提供します。パーセンタイルのメトリクスはアプリケーションに対してより有意義で積極的なパフォーマンスとして使用できます。たとえば、99番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、スケーリングのターゲットを設定できるために十分なリソースが提供されて 1% を超えないリクエストのみで 2 ミリ秒以上の処理時間がかかることになります。

リクエストのトレーシング内蔵
パーセンタイルはすべてのリクエストにおけるパフォーマンスの全体像を示すことでアプリケーションの可視性を大幅に向上させますが、AWS のアプリケーションロードバランサーの新しいトレーシング機能では、アプリケーションのパフォーマンスとヘルス状態を個々のリクエストの核心レベルまで掘り下げた理解を提供できます。ALB は現在 1 つの ALB へのすべてのリクエストにおける新しいカスタム X-Amzn-Trace-ID HTTP ヘッダーを探索しています。受信リクエストにこのヘッダーがない場合、ALB は次のようなヘッダーを生成します。

X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354 

そしてこのリクエストをアプリケーションに渡します。ヘッダーがないため、この受信リクエストは「ルート」リクエストと考慮され、ALB が送る新しいヘッダーが無作為に生成されるルート属性に含められます。受信リクエストにヘッダーが付けられている場合、そのコンテンツは保持され、こうしてヘッダーはリクエスト間の系統やタイミングデータなどのトレーシングと診断状態を送付、保持します。たとえば、生成されるリクエストは次のようになります。

$ curl -H \
  "X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354; TimeSoFar=112ms; CalledFrom=Foo" \
  request-tracing-demo-1290185324.elb.amazonaws.com 

このリクエストは ALB によって多少異なるヘッダーが生成されます。

X-Amzn-Trace-Id: Self=1-582113d1-1e48b74b3603af8479078ed6;\
  Root=1-58211399-36d228ad5d99923122bbe354;\
  TotalTimeSoFar=112ms;CalledFrom=Foo 

この例にように受信ヘッダーが自身のルーツ属性に含まれる場合、ALB はそれを保持して無作為に生成される新しい「セルフ」属性を代わりに追加します。この例に TotalTimeSoFar および CalledFrom 属性は任意でありオプショナルとなり、そしてロードバランサー自体にとっては実際意味のないものですが、アプリケーションとトレーシングフレームワークがリクエスト間でデータを移動させるためにそのまま保持されます。受信リクエストにヘッダーを設定しないアプリケーションでは、ALB のリクエストのトレースはすべてのリクエストを一意に識別する働きをします。リクエスト間でヘッダーを送付するアプリケーションでは、トレース機能によってシステム全体におけるエントリポイントを容易に識別し、ルート属性によって関連するリクエストを検索し、アプリケーションがリクエストをつなぐ「パンくず」リストを作成できるようにします。X-Amzn-Trace-ID ヘッダーのコンテンツは Application Load Balancer アクセスログに記載され、これにはそれぞれのリクエストにおけるエラー表示やパフォーマンス測定が含まれ、個別のリクエストにおける事案の特定のための識別用に使用できます。

http 2016-11-08T00:04:13.109451Z app/request-tracing-demo/f2c895fd3ea253c5 \
  72.21.217.129:20555 172.31.51.164:80 0.001 0.001 0.000 200 200 276 550 \
  "GET http://request-tracing-demo-1290185324.elb.amazonaws.com:80/ HTTP/1.1" \
  "curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.16.1 \
  Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" - - \
  arn:aws:elasticloadbalancing:us-east-1:99999999999:targetgroup/echoheader/21a6f1501d2df426 \
  "Root=1-5821167d-1d84f3d73c47ec4e58577259"

パーセンタイル統計は今すべての Application Load Balancer に利用でき、CloudWatch コンソール、AWS SDKsAPI からアクセスできます。既存の Application Load Balancer とすべての Classic Load Balancer へのサポートはこれから利用できる予定です。どちらの新しい機能も無償で導入されます。

Colm MacCárthaigh、AWS Elastic Load Balancer

AWS の値下げ – CloudWatch メトリクスの料金

2011 年と同じに 私は CloudWatch 用のカスタムメトリクスと、お客様のアプリケーションやスクリプトからそれらのメトリクスを発行する方法について説明しました。そのときに、最初の 10 個のカスタムメトリクスは無料で、追加のメトリクスは、発行したメトリクスの数にかかわらず、1 か月あたり、1 メトリクスあたり 0.50 USD でした。本日は、CloudWatch メトリクスの料金変更と数量割引について発表いたします。毎月お客様が発行するメトリクスの数に基づいて、最大 96% の節約を実現できます。US East (Northern Virginia) リージョンの新料金を次に示します (最初の 10 個のメトリクスは引き続き無料です)。

階層 下限 上限 1 か月あたり、1 メトリクスあたりの料金 現在の料金に対する割引率
最初の 10,000 メトリクス 0 10,000 0.30 USD 40%
次の 240,000 メトリクス 10,001 250,000 0.10 USD 80%
次の 750,000 メトリクス 250,001 1,000,000 0.05 USD 90%
残りの全メトリックス 1,000,001 0.02 USD 96%

EC2 詳細モニタリングを有効にした場合、1 か月あたりの料金は、1 か月、1 インスタンスあたり 3.50 USD から、ボリューム層に基づき 2.10 USD またはそれ以下に下がります。新料金は 2016 年 12 月 1 日に有効になり、お客様は何もする必要はありません。そのときに、更新された料金は CloudWatch 料金表ページに記載されます。ところで、CloudWatch メトリクスをご利用中の場合は、メトリクス保存期間の延長Collectd の CloudWatch プラグインCloudWatch ダッシュボード、新しいメトリクスからログへの概要ナビゲーション機能など、最近発表されたその他の機能もぜひご利用ください。

Jeff;

Amazon CloudWatch 更新 – パーセンタイル統計およびダッシュボードの新ウィジェット

最近は Amazon CloudWatch 関連の動きが非常に活発です!今月前半には、メトリクスから関連するログへ移動する方法をご紹介し、またメトリックス保存期間の延長とユーザーインターフェイスの更新についてお知らせしました。本日、CloudWatch は再び改良され、パーセンタイル統計および 2 つの新しいダッシュボードウィジェットが追加されました。AWS re:Invent のおかげで時間がほとんどないため、簡潔に説明します。

パーセンタイル統計
ウェブサイトやクラウドアプリケーションを大規模に実行する場合、必要なレベルのパフォーマンスをお客様の大多数にお届けできていることを確認する必要があります。数字で平均を確認することも大切ですが、全体像が分かりにくい場合もあります。平均値によってパフォーマンスの異常値が隠れてしまうことがあり、たとえば、お客様の 1% に不便をおかけしていることがわからない場合があります。カスタマーエクスペリエンスを適切に伝える方法でパフォーマンスや挙動を理解し視覚化するために、パーセンタイルは便利なツールです。たとえば、パーセンタイルを使用して、ウェブサイトに対するリクエストの 99% が 1 秒以内に満たされていることを確認できます。Amazon ではパーセンタイルを広範に使用しており、今やお客様にも同様に使用していただけるようになりました。プレフィックスとして「p」を付け、サイトやサービスの応答時間の目標と実際のパフォーマンスを p90p99、および p100 (最低の場合) として表現します。長年の経験で、当社ではロングテールにおける応答 (p99 以上) が、データベースのホットスポットおよびその他のトラブルスポットを検出するために使用できることが判っています。パーセンタイルのサポートは、EC2、RDS、Kinesis、および新しく作成された Elastic Load Balancer および Application Load Balancer で利用できます。また、カスタムメトリクスでも利用できます。CloudWatch (カスタムダッシュボード含む) にパーセンタイルを表示できるほか、アラームを設定することもできます。パーセンタイルは他のメトリクスと組み合わせて表示できます。たとえば、オレンジと緑の線は p90 および p95 CPU 使用率を表します。

CloudWatch コンソールに、任意のパーセンタイルを設定できます。

新しいパーセンタイルメトリクスを使用してアプリケーションのパフォーマンスにさらに可視性を追加する方法について詳しくは、Elastic Load Balancing: Support for CloudWatch Percentile Metrics をご覧ください。新しいダッシュボードウィジェット Stacked Area ウィジェットおよび Number ウィジェットを CloudWatch のカスタムダッシュボードに追加できるようになりました。

以下はネットワークトラフィックの Stacked Area ウィジェットです。

EC2 および EBS メトリクスの Number ウィジェットはこのようになります。

 

今すぐご利用可能
すべての AWS リージョンで今すぐ新機能をご利用いただけます。

Jeff;

EBS スナップショットに CloudWatch Events を追加

これまで runbook で保たれていた情報や限定者のみ知ることができた情報など、複雑でレベルの高いオペレーションの自動化を可能にするクラウドコンピューティングは、従来の IT オペレーションを改善させることができます。特に小規模や成長段階の企業および団体でバックアップや復元操作を必要とするオペレーションが多く見られます。スナップショットのバックアップ生成や管理がしやすいため、AWS ユーザーの多くが Amazon Elastic Block Store (EBS) ボリュームを大いに利用しています。また災害対策や運用上の理由から、リージョン間でスナップショットのコピーを定期的に取っています。そこで本日、AWS は EBS に自動化のメリットとして新に EBS スナップショット用の CloudWatch Events を追加しました。このイベントを使用してクラウドベースのバックアップ環境に自動化したオペレーションを追加することができます。新しいイベントは次をご覧ください。

  • createSnapshot – 新たに作成した EBS スナップショットのステータスが Complete に変更すると開始します。
  • copySnapshot – スナップショットコピーのステータスが Complete に変更すると開始します。
  • shareSnapshot – スナップショットを AWS アカウントと共有すると開始します。

多くの AWS ユーザーがスナップショットのステータスをモニタリングしています。この操作を行うため、ユーザーは DescribeSnapshots 関数を何度も呼び出し、特定のスナップショットを探すためにページ分割出力を調べます。今後は新しいイベントを使用して先述のクロスリージョンコピーなど、さまざまなイベントベースの自動化が可能になります。スナップショットイベントの使用 この機能がいかにデータバックアップワークフローの自動化に役立つのか理解するため、別のリージョンに完成したスナップショットをコピーするワークフローを作成してみました。まず、適切なアクセス権限を付与する IAM ポリシーを作成します。次に createSnapshot イベントでアクションを実行する AWS Lambda 関数 (私の同僚が作成) を組み入れます。最後にイベントをキャプチャする CloudWatch Events ルールを作成し、Lambda 関数に転送します。まず、このポリシーで IAM ロール (CopySnapshotToRegion) を作成します。

次に新しい Lambda 関数を作成します (コードは Amazon CloudWatch Events for EBS で検索できます)。

次に CloudWatch Events コンソールにアクセスし [Create rule] をクリックしてから、正確に処理された createSnapshot イベントに対処できるように設定します。

名前を指定します。

テストするため自分のソースリージョンで新しい EBS スナップショットを作成します。

予想どおり関数が呼び出され、数秒内にスナップショットが目的のリージョンにコピーされました (実際に実行する場合、コピーの所要時間はスナップショットのサイズにより異なります)。

こうしたイベントを使用して、別のアカウントから共有されたスナップショットのコピーを作成することもできます。組織や団体そしてセキュリティ上のさまざまな理由から、AWS をご利用されている多くの方々が複数のアカウントにわたり容量を分割しています。この点に関する詳しいアドバイスについては AWS Multiple Account Security Strategy をご覧ください。5 つのモデルのうち 2 つについてはこちらをご覧ください。 今すぐ利用可能 新しいイベントは US East (Northern Virginia)US East (Ohio)US West (Northern California)US West (Oregon)Asia Pacific (Mumbai)Asia Pacific (Seoul)Asia Pacific (Singapore)Asia Pacific (Sydney)Asia Pacific (Tokyo)Europe (Frankfurt)Europe (Ireland)South America (Brazil) リージョンで今すぐ使い始めることができます。ぜひお試しください。皆様からのご感想をお待ちしています。

Jeff;

  PS – このようなシステムを構築してみたいという開発者、開発マネージャー、プロダクトマネージャーの方は EBS Jobs ページをご覧ください。