More than 3 years have passed since last update.

【カスタムメトリック】AWS CloudWatch と PrometheusでCustom Metricの作成の違いを比較

Posted at 2020-09-09

サービスの安定性と信頼性を確保するには、システムとその基盤となるインフラストラクチャの状態を常に理解することが最も重要です。展開のパフォーマンスと正常性に関する最新の情報は、チームがリアルタイムで問題に対応するのに役立つだけでなく、自信を持って変更を行うためのセキュリティを提供し、システム障害やパフォーマンスの問題を発生前に安全に予測します。

クラウドコンピューティングの世界で非常に人気のある2つのモニタリングアプリケーションは、AWSスイートの主要なモニタリングアプリケーションであるAWS CloudWatchと、SoundCloudで最初に開発された大規模なオープンソースモニタリングアプリケーションであるPrometheusです。

CloudWatchとPrometheusを使用する場合、幅広い組み込みメトリクスから選択できます。ただし、場合によっては、PrometheusまたはCloudWatchが提供する標準のメトリックセットよりも多くを監視する必要があります。当社の監視プラットフォームには、ユーザーが使用しているシステムに独自のメトリックをカスタマイズできる機能があることが重要です。

この記事の目的は、AWS CloudWatchとPrometheusの2つの一般的なモニタリングアプリケーションでカスタムメトリクスを公開および使用することの比較を提供することです。

開始するには、MetricFireの無料トライアルにジャンプして、独自のPrometheusカスタムメトリックを作成できます。私たちのプラットフォームでは、PrometheusとGrafanaを直接試すことができ、独自のカスタムダッシュボードを構築できます。 AWS CloudWatchをMetricFireと統合し、プラットフォームでAWSメトリックを監視することもできます。これは、柔軟性とダッシュボードオプションが強化された2番目のプラットフォームを探しているAWSユーザーにとって非常に役立ちます。 Hosted GraphiteのドキュメントでAWS CloudWatchをGrafanaと統合する方法を確認してください。

カスタムメトリックとは何ですか？

簡単に言うと、カスタムメトリックはアプリケーションユーザーが定義したメトリックです。これらは組み込みシステムメトリックとは異なり、その目的は、このデータがシステムによってネイティブに公開されていなくても、ユーザーまたはシステム管理者がシステムから監視または追跡するものを定義できるようにすることです。

CloudWatchカスタムメトリクス

AWS Command Line Interface（CLI）ツールまたはAWS APIを使用して、カスタムメトリックを作成してCloudWatchに発行できます。これらのカスタムメトリックは、デフォルトではネイティブに公開されないアプリケーションパフォーマンスデータから、販売アプリケーションで行われた購入などのビジネスメトリックまで、あらゆる種類のデータを収集するために作成できます。

カスタムメトリックスは、AWSサービスで実行されている任意のアプリケーションに対して作成でき、サービスに応じてプロセスと要件がわずかに異なります。たとえば、Elastic Beanstalk（EBS）やElastic Cloud Compute（EC2）などのコンピューティングサービスでは、基本的にカスタムスクリプトを作成してレポートできるperlスクリプトであるCloudWatchモニタリングスクリプトを使用できます。

これらのスクリプトは、収集するメトリックと収集方法を定義するように記述されており、ユーザーからそれらを抽象化します。これらのスクリプトは、データを収集するコンピューティングインスタンスにインストールして実行するのと同じくらい簡単です。

CloudWatchモニタリングスクリプトは、モニタリングしたいコンピューティングインスタンスにこれらのスクリプトを非常に簡単にインストールして実行できるため、カスタムメトリックスで驚くほどの柔軟性と再利用性を提供します。これらのスクリプトによって収集されたメトリックスはCloudWatchコンソールでグラフ化され、すべてのカスタムメトリックスを一目ですべて1か所で確認できます。

これらのスクリプトを使用する場合の欠点の1つは、計算インスタンスにインストールして実行する前に、収集するメトリックを事前に定義する必要があることです。そのようなスクリプトの詳細な例は、EC2ドキュメントにあります。

カスタムCloudWatchメトリックスを作成する別の方法は、AWS APIを使用することです。これにより、アプリケーションコード内から直接メトリックを作成できます。たとえば、eコマースWebサイト（主要業績評価指標）での特定のユーザーインタラクションを追跡すると、時間の経過に伴うビジネスパフォーマンスの洞察が得られます。 AWS SDKの機能を活用して、このデータを追跡するカスタムメトリクスを作成するコードを記述し、setイベントが発生するたびにラムダ関数を使用してこのコードを実行できます。このコードは、以下のスニペットに似ている可能性があります。

import boto3
def lambda_handler(event, context):
    cloudwatch = boto3.client('cloudwatch')
    response = cloudwatch.put_metric_data(
        MetricData = [
            {
                'MetricName': 'KeyPerformanceIndex',
                'Dimensions': [
                    {
                        'Name': 'SALES_SERVICE',
                        'Value': 'SalesService'
                    },
                    {
                        'Name': 'APP_VERSION',
                        'Value': '1.0'
                    },
                ],
                'Unit': 'None',
                'Value': #the actual data from your app
            },
        ],
        Namespace = 'SalesApp'
    )
print response

簡単に言うと、上のlambda関数は、MetricDataのValueフィールドで指定したデータのデータ値を記録するKeyPerformanceIndexというカスタムメトリックを作成します。理想的には、このデータはアプリケーションから提供され、このメトリックが送信されるたびにメトリック値を表します。したがって、本質的に、傾向を監視したい任意のデータをこのメトリックにフィードできます。この関数は、Python用AWS SDKであるboto3ライブラリを使用して、put_metric_data（PutMetricData）API呼び出しを介してCloudWatchにメトリックスを公開します。

注目したいのは、上で説明したAWS CLIメソッド（モニタリングスクリプト）も、内部でこのPutMetricData API呼び出しを使用するという事実です。 AWSサービスによって生成されたメトリクスには、デフォルトの標準解像度（1分単位）または高解像度（1秒単位）がありますが、カスタムメトリクスに対するすべてのPutMetricData呼び出しが課金されるため、高解像度のメトリックでPutMetricDataを頻繁に使用すると、はるかに高いコストが発生する可能性があります。 CloudWatchの価格は、予想以上にエスカレートすることで悪評が高く、詳しくはCloudWatchの価格をご覧ください。

Prometheusカスタムメトリック

Prometheusは、非常にシンプルな（まだ複雑な）ユースケースを持つ非常に人気のあるオープンソースモニタリングツールです。一連のスクレイプジョブを構成することにより、メトリックを見つける場所を指示します。各ジョブは、スクレイピングするエンドポイントを持つ一連のノードを指定します。次に、Prometheusはこれらのエンドポイントのメトリックデータを定期的にスクレイピングし、ローカルに保持し、それを使用して視覚的なメトリックチャートを表示します。

組み込みのPrometheus式ブラウザーにメトリックを表示したり、Grafanaなどの他のグラフUIにエクスポートしたりできます。ほとんどの部分で、PrometheusカスタムメトリックスはCloudWatchカスタムメトリックスにいくぶん似ており、アプリケーションのあらゆる側面を指定して監視する柔軟性をユーザーに提供します。ただし、Prometheusは、サポートするメトリックの種類に少し制限を加えて、4つの主要なタイプに制限します。

カウンター：カウンターは、アプリケーションの再起動時にのみ増加または0にリセットできる単一の増加値を表す累積メトリックです。そのようなメトリックを使用して、いくつかの例を挙げると、提供されたリクエストの数、または完了したタスクの数を表すことができます。
ゲージ：ゲージは、上下に移動できる単一の数値を表し、現在のメモリ使用量や同時リクエスト数などの測定に使用できます。
ヒストグラム：ヒストグラムは観測値をサンプリングし、構成可能なバケットでカウントして、特定のレベルの集計を可能にします。主に、リクエストの継続時間や応答時間などの分布を測定するために使用されます。
サマリー：サマリーは観測値をサンプリングし、すべての観測値の数を提供します。これらは、ペイロードサイズなど、合計値が重要な状況で使用されます。

PromQLでクエリする方法に関する記事で、Prometheusデータ構造の詳細をご覧ください。

したがって、カスタムメトリックを作成するには、コードで上記のタイプの1つを指定し、それを専用のエンドポイントに公開し、メトリックデータの構成可能な間隔でPrometheusにそのエンドポイントをスクレイピングさせる必要があります。

ただし、Prometheusが持つ統合オプションの数は、このわずかな柔軟性の欠如を補います。 Prometheusはエクスポーターやその他の統合を使用してこれを行うため、サードパーティのソフトウェアがほとんど手間をかけずにメトリックをPrometheusに引っ張ることができます。オープンソースプロジェクトであるため、これらのエクスポーターは、Prometheus GitHub組織の一部として作成および保守したり、Prometheusの外部で作成およびホストしたりできます。こちらのPrometheusエクスポーターに関する記事をご覧ください。

これは、システムに独自のエクスポーターを作成し、このエクスポーターを使用してメトリックをPrometheusがスクレイプできるという点で強力です。その結果、Prometheusを使用すると、カスタム監視がはるかに簡単になります。また、Prometheusは多種多様なシステムと統合するため、コードで使用する実際のAPIは、システムを実行している基になるクライアントライブラリに依存します。 Prometheusで使用されているクライアントライブラリの一部を以下に示します。

カスタムメトリックの比較

両方のシステム、それらのカスタムメトリックがどのように機能するか、およびそれらを作成/公開する方法を見て、それらが驚くべき類似点を共有していることは明らかです。独自の概念としてのカスタムメトリックは、システム開発者または関連する利害関係者がアプリケーションとその動作方法について貴重な洞察を得るのに役立ち、システムのあらゆる側面を文字どおり特定して追跡できるようにし、これを実現することを目的としています監視アプリケーションに入力されたデータは、使いやすい方法で処理および表示されます。

AWS CloudWatchとPrometheusのカスタムメトリックはどちらも、この要件を十分に満たしています。ただし、これらにはいくつかの違いがあり、いくつかのシナリオで一方の使用を促進します。

CloudWatchはAWSで実行され、他のAWSサービスと非常に簡単に統合できるので、アプリケーションがAWSプラットフォームでホストされている場合、これは理想的なソリューションです。
ただし、Prometheusのオープンソースの性質により、多種多様な他のアプリケーションとの統合をサポートできます。 CloudWatchは、ホストされているかオンプレミスかにかかわらず、AWSサービスに制限されますが、Prometheusは非常にオープンで柔軟性があります。
CloudWatchは、すべてのアプリケーションのすべてのメトリックデータを表示するための便利な集中型の場所を提供します。したがって、すべてのカスタムメトリックを一目で見つけて表示することが非常に簡単になり、固定されたダッシュボード上のすべてを読みやすいグラフとして視覚化できます。一方、Prometheusはカスタマイズ性が高いため、自動的に作成されるダッシュボードは少なくなります。 Grafanaとの統合を使用すると、CloudWatchが提供する固定ダッシュボードに限定されず、生産性を高める独自の方法でダッシュボードを構築できます。
CloudWatchカスタムメトリックは、何からでも構築できます。コードで値として表すことができる場合、それからメトリックを作成できますが、Prometheusはメトリックの作成を前述の4つのメトリックタイプのみに制限します。ただし、logstashなどの収集エンジンでPrometheusを使用すると、この制限が緩和されます。
Prometheusは、コンテナー化を使用して抽象化することができるため、基盤となるテクノロジーに関係なく、構成がほとんどなく、任意のシステムプラットフォームで実行できます。オープンソースであるという事実により、Prometheusのソースコードをユースケースに最適にカスタマイズできるため、柔軟性がさらに魅力的になります。 CloudWatchは独自のソフトウェアであるため、このような柔軟性はありません。
Prometheusは、基本的にはサードパーティのシステムからPrometheusへのメトリックのエクスポートを可能にするライブラリであるエクスポーターを使用して、カスタムメトリックをワンランクアップします。すでに利用可能なエクスポーターの膨大なカタログを使用できるだけでなく、独自のカスタムエクスポーターを構築して、システムからPrometheusにメトリックをエクスポートすることもできます。
最後に、オープンソースのPrometheusは無料で使用できます。 Dockerイメージをほとんどダウンロードして、ごくわずかな費用でシステムを数分で動作させることができます。ただし、CloudWatch PutMetricData APIへのすべての呼び出しは課金されます。これは、多くのカスタム監視を行うつもりである場合、膨大な請求につながる可能性があります。

ローカルでPrometheusをダウンロードしてインストールする手間をかけたくない場合は、メンテナンスのオーバーヘッドを気にすることなく、Prometheusのすべての利点を備えたホストされたバージョンを試すことができます。 MetricFireが提供するHosted Prometheusをご自由にチェックしてみてください。

まとめ

カスタムメトリックは、それらを収集して処理するために使用される監視プラットフォームに関係なく、強力な機能です。上で説明した両方のプラットフォームの長所と短所にもかかわらず、どちらも適用されるのを待っているだけの大きな可能性を秘めています。

AWS CloudWatchはMetricFireと統合されているため、一般的な方法の1つはCloudWatchメトリックスをMetricFireに送信することで、カスタマイズされたモニタリングとダッシュボードを簡単に実行できます。

MetricFireの無料トライアルを試して、今日からPrometheusでモニタリングを開始してください。また、MetricFireチームと直接話をしたい場合は、デモを予約してビデオ通話にてご相談ください。

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

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up