Amazon Web Services ブログ

Category: Amazon CloudWatch

Amazon RDS for MySQLとMariaDBのログをAmazon CloudWatchで監視出来るようになりました

Amazon RDSは、トラブルシューティングなどの目的にお使い頂けるように、DBインスタンスで生成されたログを表示およびダウンロードする機能を提供してきました。Amazon Relational Database Service(Amazon RDS) for MySQLとAmazon RDS for MariaDBでは、DBインスタンスのログイベントをAmazon CloudWatch Logsに直接保存出来るようになりました。これにより、AWSサービスを使用して、よりシームレスにDBインスタンスログを扱うことができます。 DBインスタンスログのニアリアルタイム分析 Amazon CloudWatch Logsを使用すると、アプリケーションの様々なコンポーネントからのログを集中的かつ永続的に保存できます。また、特定のフレーズ、値、パターン(メトリック)について、ニアリアルタイムでログを監視することもできます。さらに、設定した状態が発生したときに警告するアラームを設定することもできます。Amazon CloudWatchは他の様々なAWSサービスと統合することが可能です。これにより、以下のような幅広いユースケースでログを利用する価値を向上できます: 通常デジではありえない大量のスロークエリや接続の失敗など、異常な状態を検知するためのアラーム設定 他のアプリケーションログと関連させる セキュリティおよびコンプライアンスの目的でログを保持する ログデータの傾向を分析する 以下の図がアーキテクチャの概要です: ログエクスポートの概念 新しいログエクスポート機能は、MySQLおよびMariaDBの次のログタイプをサポートしています: Error log – 起動および停止にデータベースエンジンによって生成された診断メッセージが含まれています General query log – クライアントから受け取ったすべてのSQLステートメントのレコードと、クライアントの接続および切断時間を含みます Slow query log – 設定された時間よりも実行に時間かかったクエリや、定義された行数を超える行を走査したSQL文のレコードが含まれています。 両方の閾値は設定可能です Audit log – MariaDB Audit Pluginを使用して提供されるこのログは、監査目的でデータベースアクティビティを記録します これらのソースからのログイベントは、Amazon CloudWatchのロググループにログストリーム(ログイベントのシーケンス)の形式で保存されます。 各DBインスタンスとログの種類に応じて、DBインスタンスと同じAWS Region内に別のグループを次の命名パターンで作成します: /aws/rds/instance/<db-instance-id>/<log-type> ログデータは耐久性のあるCloudWatch Logsに保存され、透過的に暗号化されます。ただし、ログには機密情報が含まれている可能性があります。データを保護するために、アカウント内の適切なユーザーにアクセスを制限する必要があります。そのために、データベースログを含むロググループに対して適切なIAMアクセスポリシーを設定することが重要です。 Amazon RDSはDBインスタンスと同じアカウント内のロググループにservice-linked roleを使用してログを送信します。これにより、Amazon RDSはアカウント内の関連するロググループにアクセスできます。ログの送信を有効にすると、AWSServiceRoleForRDSという追加のIAMロールが表示されることがあります。 CloudWatch Logsへログの送信を有効にするには、以下のように設定を行います。 […]

Read More

新発表 – 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 Command、SSM 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はAmazonSSMFullAccessとAmazonEC2ReadOnlyAccessポリシーを持っている必要があります。以下が私のroleです: これを既に実行中のインスタンスに簡単に追加できます (これは比較的新しいEC2の非常に便利な機能です): SSM Agentをインスタンス上で既に実行しています。もしまだであれば、SSM エージェント をインストールし設定するの手順に従ってセットアップします。 次に、AWS Systems Managerを使ってCloudWatch Agentをインストールします: これは数秒で終わります。これで、簡単なウィザードを使ってエージェントの設定ファイルをセットアップします: […]

Read More

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

Amazon CloudWatch は 2009 年以来 AWS の重要な要素となっています。3 つの同時リリース (Auto Scaling、Elastic Load Balancing) の 1 つとして公開された CloudWatch は、AWS リソースや AWS クラウドで実行するアプリケーションをモニタリングする非常に強力なサービスに進化しました。CloudWatch カスタムメトリクス (2011 年にリリース) は CloudWatch でビジネスおよびアプリケーションメトリクスを保存できるようにし、グラフ表示や CloudWatch アラームをベースにアクションを開始することができます。数年間に渡り CloudWatch にいくつもの強化点を施してきたことは言うまでもありません。最近ではメトリクス保存期間の延長 (およびユーザーインターフェイスの更新)、ダッシュボード、ダッシュボードでの API/CloudFormation のサポート、ダッシュボードにアラームなどを追加してきました。 最初はメトリクスを 5 分間隔で保存していましたが、ユーザーから寄せられたリクエストに応え、2010 年にこれを 1 分間隔に変更しました (詳細モニタリング)。これについては高い評価を頂きましたが、そろそろレベルアップさせる時期が来ました。AWS をご利用されているお客様は 1 日に多数の動画をストリーミングしたり、フラッシュセールを行ったり、コードをいくつもデプロイしたりしています。さらに、状況が変わるに連れてすばやくスケールインまたはスケールアウトするアプリケーションも実行しています。こうした様々な状況において 1 分間隔では詳細性に欠けることになります。また、重要で一時的な増加を見逃してしまう可能性もあります。異種 (でありながら関連性のある) イベントを時間と関連付けるのは困難です。何か支障があった場合の MTTR (mean time to repair – 平均修復時間) に時間が掛かることもあるでしょう。 […]

Read More

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

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。 新しい API および CLI コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、 のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。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 […]

Read More

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”: { […]

Read More

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 […]

Read More

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 ウィジェット: […]

Read More

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

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

Read More

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

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

Read More

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

最近は 関連の動きが非常に活発です!今月前半には、メトリクスから関連するログへ移動する方法をご紹介し、またメトリックス保存期間の延長とユーザーインターフェイスの更新についてお知らせしました。本日、CloudWatch は再び改良され、パーセンタイル統計および 2 つの新しいダッシュボードウィジェットが追加されました。 のおかげで時間がほとんどないため、簡潔に説明します。 パーセンタイル統計 ウェブサイトやクラウドアプリケーションを大規模に実行する場合、必要なレベルのパフォーマンスをお客様の大多数にお届けできていることを確認する必要があります。数字で平均を確認することも大切ですが、全体像が分かりにくい場合もあります。平均値によってパフォーマンスの異常値が隠れてしまうことがあり、たとえば、お客様の 1% に不便をおかけしていることがわからない場合があります。カスタマーエクスペリエンスを適切に伝える方法でパフォーマンスや挙動を理解し視覚化するために、パーセンタイルは便利なツールです。たとえば、パーセンタイルを使用して、ウェブサイトに対するリクエストの 99% が 1 秒以内に満たされていることを確認できます。Amazon ではパーセンタイルを広範に使用しており、今やお客様にも同様に使用していただけるようになりました。プレフィックスとして「p」を付け、サイトやサービスの応答時間の目標と実際のパフォーマンスを p90、p99、および 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 のカスタムダッシュボードに追加できるようになりました。 […]

Read More