EC2 CloudWatch メトリックの種類

過去数十年にわたって、クラウドコンピューティングの世界は驚くほど進歩しました。この2018年のフォーブスの記事によると、「77％の企業がクラウドに少なくとも1つのアプリケーションまたはエンタープライズコンピューティングインフラストラクチャの一部を持っています。」。アプリケーションをクラウドに移行する企業が増えるにつれ、クラウドプロバイダーは、これらのアプリケーションを最適化する最善の方法に関する有用な洞察を提供しながら、これらのビジネスがアプリケーションの状態を監視できるようにする効率的な方法を開発しました。

Amazon Web Servicesは、顧客ベースの点でトップのクラウドプロバイダーであり、この目的に対応する広範なアプリケーションスイートを提供します。AmazonCloudWatchは、その最高のモニタリングおよび監視機能を提供します。 MetricFireはAWS CloudWatchと統合して、AWSユーザーに2番目のプラットフォームを提供し、モニタリングダッシュボードをよりカスタマイズし、より多様なプラグインセットと統合します。 また、お値段的にもかなり経済的であり、ユーザーに新しいオプションを提供しております。MetricFireの無料トライアルにサインアップし、CloudWatchを当社のホスト型GraphiteおよびGrafanaと統合します。 Hosted Graphite Docsで統合についての詳細を知ることもできます。

Amazon CloudWatchとは何か？

Amazon CloudWatchは、AWSクラウドリソースとAWSで実行されているアプリケーションのモニタリングと監視サービスです。 CloudWatchは、AWSプラットフォームのさまざまなコンピューティングサービスとシームレスに統合し、それらのプラットフォームで実行されているアプリのログとメトリックを収集します。アプリケーションから収集したこのデータを使用して、CloudWatchは実用的な洞察を提供し、実行中のアプリケーションの監視、システム全体のパフォーマンスの変化への対応、リソース使用率の最適化、運用状態の統一されたビューの取得に役立ちます。 CloudWatchの詳細については、MetricFireブログ（AWSリソースのKubernetesおよび【AWS CloudWatch】基本の紹介から、実際にセッティングまでしてみる）を参照してください。

CloudWatchが統合するサービスの1つは、AWSのメインの仮想マシンコンピューティングサービスであるAmazonのElastic Compute Cloud（EC2）です。多くの場合、EC2インスタンスはAWSで実行されているほとんどのアプリケーションのコアコンピューティングワーカーとして機能し、その「正常性」とパフォーマンスを監視することが不可欠です。この監視は、CloudWatchによってキャプチャおよび処理される特定のメトリックを使用して行われ、この記事のではそこについても説明していきます。

Amazon EC2インスタンスは、そのプロセスの状態、正常性、およびパフォーマンスに関する膨大な量の生データと統計を出力します。このデータは、EC2スイートに統合されているCloudWatchによって収集され、読み取り可能なほぼリアルタイムのメトリックに処理され、EC2コンソールから直接、読みやすいグラフを使用して表示されます。デフォルトでは、EC2インスタンスはこのデータを5分間隔でCloudWatchに吐き出しますが、より詳細な情報が必要な場合は、インスタンスを作成する前に、またはEC2コンソールまたはAWS CLI。詳細なモニタリングにより、CloudWatchはEC2データを1分単位で収集できます。詳細については、こちらのAWSドキュメントをご覧ください。

CloudWatchによって収集されるメトリックにはどのような種類があるのか？

Amazon EC2インスタンスは、ステータス、ヘルス、パフォーマンスに関する生データをメトリックス形式でCloudWatchに送信します。 このデータは、デフォルトでは5分ごと、または詳細な監視が有効になっている場合は1分ごとに送信されます。 EC2インスタンスの無限の使用例を考えると、これらのインスタンスのすべての単一の側面を文字通り追跡するためにCloudWatchで収集できる膨大な量のメトリックが存在します。

インスタンスメトリック

これらのメトリクスは、インスタンスの特定のコアオペレーションの状態を追跡します。 彼らは含まれています：

• CPUUtilization：このメトリクスは、基になるEC2インスタンスのCPU使用率を、割り当てられたEC2コンピューティングユニットの割合として追跡します。 つまり、インスタンスで現在使用されている割り当て済みEC2コンピューティングユニットの量をパーセンテージで追跡します。
• DiskReadOps：このメトリクスは、指定された期間にインスタンスで使用可能なすべてのインスタンスストアボリュームから完了した読み取り操作の数を追跡します。

インスタンスストアボリュームがない場合、値が0であるか、メトリックが報告されていないということになります。

• DiskWriteOps：このメトリクスは、指定された期間に、基礎となるインスタンスで使用可能なすべてのインスタンスストアボリュームへの完了した書き込み操作の数を追跡します。このインスタンスに起因するインスタンスストアボリュームがない場合、値は0であるか、メトリックは報告されません。
• DiskReadBytes：これは、基本監視では5分間、詳細監視では1分間にインスタンスで使用可能なすべてのインスタンスストアボリュームから読み取られたデータ量をバイト単位で追跡します。このメトリックは、アプリケーションがインスタンスのハードディスクから読み取るデータの量を決定するために使用され、アプリケーションの速度を決定するために使用できます。このインスタンスのインスタンスストアボリュームがない場合、値が0であるか、メトリックが報告されていません。
• DiskWriteBytes：このメトリックは、基本モニタリングでは5分間、詳細モニタリングでは1分間にインスタンスで使用可能なすべてのインスタンスストアボリュームに書き込まれたバイト数を記録します。これは、アプリケーションが基礎となるディスクにデータを書き込む速度を追跡するため、アプリケーションの速度を推測するために使用できます。このインスタンスのインスタンスストアボリュームがない場合、値が0であるか、メトリックが報告されていません。
• NetworkInおよびNetworkOut：これらのメトリックは、インスタンスによってすべてのネットワークインターフェースで転送されたバイトの量を追跡します。前者（NetworkIn）は受信したバイトの量を記録し、後者（NetworkOut）は送信したバイトの量を記録します。これらの追跡は、記録期間に関して行われます。つまり、これらのメトリックは、基本モニタリングでは5分間に転送され、詳細モニタリングでは1分間に転送されたバイトの量を記録します。
• NetworkPacketsInおよびNetworkPacketsOut：これらのメトリックは、インスタンスによってすべてのネットワークインターフェースで受信（NetworkPacketsIn）および送信（NetworkPacketsOut）されたパケットの数を追跡します。それらは、単一インスタンス上のパケット数の観点から、着信および発信トラフィックの量を識別します。これらのメトリックは、基本的な監視でのみ使用できます。
• MetadataNoToken：このメトリックは、トークンを使用しないメソッドを使用してインスタンスメタデータサービスが正常にアクセスされた回数を追跡します。インスタンスメタデータサービスバージョン1を使用してインスタンスメタデータにアクセスするプロセスがあるかどうかを判断するために使用されます（インスタンスメタデータサービスバージョン1はトークンを使用しません）。すべてのリクエストがトークンベースのセッション、つまりインスタンスメタデータサービスバージョン2を使用する場合、値は0です。

CPUクレジットメトリック

バースト可能なパフォーマンスインスタンスと呼ばれる特定のEC2インスタンスタイプ（T3、T3a、およびT2インスタンス）があります。これらは、ワークロードで必要なときに、ベースラインレベルのCPUパフォーマンスを提供して、より高いレベルのパフォーマンスにバーストする機能を提供するように設計されています。このバースト容量はCPUクレジットによって制御されます。通常、インスタンスが時間とともに蓄積するCPUクレジットが多いほど、バースト容量は長くなります。次のCPUメトリックは、利用可能なクレジットとクレジットの使用状況の追跡に役立つため、バースト可能なインスタンスでのみ使用できます。注意すべき点の1つは、これらのメトリックは詳細な監視には使用できないことです。

• CPUCreditUsage：このメトリックは、5分間にCPU使用率のインスタンスによって消費されたCPUクレジットの数を追跡します。 1つのCPUクレジットは、100％の容量で1分間実行される1つのvCPU、またはvCPU、時間、および容量の同等の組み合わせに相当します（たとえば、1つのvCPUが50％の容量で2分間実行される、または2つのvCPUが25％の容量で実行される2分）。
• CPUCreditBalance：これは、インスタンスが起動または開始されてからインスタンスが獲得した獲得CPUクレジットの数を追跡します。つまり、インスタンスで使用可能なCPUクレジットの数を追跡します（時間の経過とともに蓄積された合計クレジットから、インスタンスが以前のバーストで使用した合計クレジットを差し引いたもの）。
• CPUSurplusCreditBalance：これは、無制限のインスタンスによって消費された余剰クレジットの数を追跡します（無制限のインスタンスは、無制限モードで実行するように構成されたバースト可能なインスタンスです。つまり、いつでも必要なだけパフォーマンスバーストを維持できます） CPUCreditBalance値がゼロの場合。余剰は、獲得したCPUクレジットによって払い戻されますが、この余剰がこのインスタンスが24時間以内に獲得できる最大CPUクレジットを超えると、追加料金が発生する可能性があります。
• CPUSurplusCreditsCharged：これは、獲得したCPUクレジットによって払い戻されず、追加料金が発生する使用済みの余剰クレジットの数を追跡します。

NitroベースのインスタンスのEBSメトリック

Elastic Block Storage（EBS）を使用してNitro Basedインスタンスの読み取りと書き込みの速度を追跡するための特別なカテゴリのメトリックが存在します。 この記事を妥当な長さに保つために、ここに移動して、Nitro Basedインスタンスとは何かについて理解いただければと思います。

ステータスチェックメトリック

この一連の指標は、インスタンスのステータスに関するデータを記録します。 デフォルトでは、1分の頻度で無料で利用できます。 新しいインスタンスの場合、ステータスチェックの指標データは、インスタンスが初期化状態を完了した後でのみ使用できます。

• StatusCheckFailed：これは、インスタンスが最後の1分間にシステムステータスチェックとインスタンスステータスチェックの両方に合格したかどうかを報告するブール値のメトリックです。 0（成功）または1（失敗）のいずれかです。
• StatusCheckFailed_Instance：これはブール値のメトリックで、StatusCheckFailedに似ていますが、インスタンスが最後の1分間にインスタンスステータスチェックに合格したかどうかを追跡するだけです。
• StatusCheckFailed_System：StatusCheckFailed_Instanceに似ていますが、インスタンスが最後の1分間にシステムステータスチェックに合格したかどうかのみを追跡します。

StatusCheckFailedメトリックは、StatusCheckFailed_InstanceとStatusCheckFailed_Systemメトリックの組み合わせとして見ることができます。

Amazon EC2使用状況メトリクス

使用状況メトリクスは、アカウントのリソースの使用状況を可視化するのに役立つCloudWatchメトリクスです。現在、EC2インスタンスで使用できる唯一の使用状況指標は、アカウントで実行されている指定されたリソースの数を追跡するResourceCount指標です。リソースは、指標で設定されたディメンションによって定義されます。

• サービス：これは、追跡されているリソースを含むAWSサービスの名前を指します。この場合、サービス名はEC2です。
• タイプ：追跡するエンティティのタイプを指定します。この場合はリソースです。
• リソース：追跡するリソースのタイプを指定します。EC2使用状況メトリックの有効な値はvCPUのみです。
• クラス：追跡するリソースのクラスを指定します。 EC2インスタンスの場合、有効な値は、Standard / OnDemand、F / OnDemand、G / OnDemand、Inf / OnDemand、P / OnDemand、およびX / OnDemandです。

このメトリクスを使用して、現在のEC2使用状況をCloudWatchグラフとダッシュボードで視覚化できます。また、これらのメトリクスにアラームを設定して、EC2使用状況が特定の割り当てを超えないようにすることもできます。

これらすべてのメトリックやその他のメトリックには、各インスタンスのEC2ダッシュボードから簡単にアクセスできます。 EC2ダッシュボードの[Monitoring]タブで実行中のデモインスタンスのこれらのメトリックがどのようにグラフ化されるかについては、以下の図を確認してください。

前述のように、インスタンスの状態を監視することは、アプリケーションを正常に保つために不可欠であり、AWSによって提供される上記のメトリックス（およびその他多くのメトリックス）を使用すると、比較的簡単にこれを達成できます。

MetricFireとの統合

多くのCloudWatchユーザーは、より柔軟性の高いセカンダリプラットフォームを探しているときに、MetricFireに興味を持ちます。 MetricFireを使用すると、Grafana labなどの幅広いプラグインセットに加えて、無制限のダッシュボード、クエリ、アラートを利用できます。

実際にAWS CloudWatchアカウントをMetricFireに接続して、CloudWatchで監視するメトリクスの量を減らしながら、CloudWatchで必要不可欠なものを監視するという利点を得ることができます。

MetricFireがホストするGraphiteは、アカウントのAdd onページで利用できるAmazon AWS CloudWatchアドオンを提供します。 このアドオンは、指定されたAWSサービス/リージョンのメトリックスをアカウントに同期します。

CloudWatchアカウントに接続するには、AWSアカウントでIdentity and Access Management（IAM）アクセスキーを設定し、MetricFireのHosted Graphiteがメトリックスに接続して収集できるようにする適切なアクセス許可を設定する必要があります。

まとめ

この記事では、AWS環境内での役割の理解からCloudWatchでのEC2メトリックスのダッシュボード作成まで、EC2 CloudWatchメトリックスの使用方法を説明しました。

詳細については、デモを予約して、MetricFireチームと直接話し、EC2設定を最適に監視する方法について私たちと話し合ってください。

そして、MetricFireの無料トライアルにサインアップして、MetricFireが提供する機能を探り、AWS統合を試してください。