Amazon Web Services ブログ
Amazon CloudWatch での Prometheus メトリクスの使用
Imaya Kumar Jagannathan、Justin Gu、Marc Chéné、および Michael Hausenblas
今週の初めに、AWS は CloudWatch Container Insights での Prometheus メトリクスモニタリングの公開ベータ版サポートを発表しました。この記事では、ユーザーがプロビジョニングする AWS クラスター上の Amazon Elastic Kubernetes Service (EKS) および Kubernetes で、コンテナ化されたワークロードに新しい Amazon CloudWatch 機能を使用する方法をご紹介します。
Prometheus は Cloud Native Compute Foundation (CNCF) の卒業プロジェクトで、アクティブで大きなプラクティショナーコミュニティを持つ人気のオープンソースモニタリングツールです。Amazon CloudWatch Container Insights は、コンテナ化されたアプリケーションからの Prometheus メトリクスの検出と収集を自動化します。CloudWatch Container Insights は、カスタム CloudWatch メトリクスを自動的に収集し、フィルタリングして、AWS App Mesh、NGINX、Java/JMX、Memcached、および HAProxy などのワークロード用のダッシュボードで視覚化された集約メトリクスを作成します。デフォルトで、事前に選択されたサービスが 60 秒ごとにスクレイピングおよび事前集約され、クラスターおよびポッドの名前などのメタデータで自動的にリッチ化されます。
AWS では、OpenMetrics との互換性があるすべての Prometheus エクスポーターをサポートして、ユーザーが 150 を超えるオープンソースのサードパーティーエクスポーターのひとつを使ってコンテナ化されたあらゆるワークロードをスクレイプできるようにすることを目指しています。
これは次のような仕組みになっています。 まず、Kubernetes クラスターで CloudWatch エージェントを実行する必要があります。Prometheus の設定、検出、およびメトリクスのプル型収集をサポートするようになったこのエージェントは、忠実度の高い Prometheus メトリクスとメタデータのすべてをリッチ化し、埋め込みメトリックフォーマット (EMF) として CloudWatch Logs に発行します。各イベントは、完全に設定可能なキュレーションされた一連のメトリクスディメンションのための CloudWatch カスタムメトリクスとしてメトリクスデータポイントを作成します。集約された Prometheus メトリクスの CloudWatch カスタムメトリクス統計としての発行は、パフォーマンス問題と障害のモニタリング、アラーム発行、およびトラブルシューティングに必要なメトリクスの数を低減させます。また、CloudWatch Logs Insights クエリ構文を使って忠実度の高い Prometheus メトリクスを分析して、コンテナ化された環境の正常性とパフォーマンスに影響を及ぼしている特定のポッドとラベルを特定することもできます。
これらを踏まえて、2 つのセットアップでの CloudWatch Container Insights Prometheus メトリクスの使用方法を説明する実践的な部分に進みましょう。まず NGINX スクレイピングのシンプルな例から初めて、次に ASP.NET Core アプリを計装することによってカスタムメトリクスを使用する方法を見ていきます。
NGINX からの追加設定不要のメトリクス
最初の例では、EKS クラスターをランタイム環境として使用し、メトリクスを EMF イベントとして CloudWatch に取り込むために CW Prometheus エージェントをデプロイします。スクレイピングターゲットであり、専用アプリがトラフィックを生成する NGINX をイングレスコントローラとして使用します。全体的なセットアップは以下のようになります。
EKS クラスターには 3 つの名前空間があります。これらは、CW Prometheus エージェントをホストする amazon-cloudwatch
、NGINX Ingress コントローラを実行する nginx-ingress-sample
、およびトラフィックジェネレータを含めたサンプルアプリをホストする nginx-sample-traffic
です。
手順を同時に進めたい場合は、EKS クラスターをプロビジョニングするための eksctl、およびアプリケーションインストールのための Helm 3 をインストールしておく必要があります。
EKS クラスターには、以下のクラスター設定を使っています (clusterconfig.yaml
として保存。リージョンは地理的に近いリージョンに変更するとよいかもしれません)。
この後、以下のコマンドを使って EKS クラスターをプロビジョニングできます。
eksctl
は見えないところで CloudFormation を使用するので、そのコンソールで進行状況を確認できます。プロビジョニングは、開始から完了まで 15 分ほどかかることを見込んでください。
次に、Helm を使って、専用の Kubernetes 名前空間 nginx-ingress-sample
に NGINX Ingress コントローラをインストールします。
NGINX Ingress コントローラによって管理されるロードバランサーをトラフィックジェネレータのターゲットとするには、次のようにそのパブリック IP アドレスをクエリする必要があります。
これで、nginx-sample-traffic
名前空間にサンプルアプリとトラフィックジェネレータをセットアップする準備が整いました (EXTERNAL_IP
には、前のステップで確認した独自の IP を使用するようにしてください)。
最後に、以下を使って amazon-cloudwatch
名前空間に CW エージェントをインストールします。
完成まであと一歩ですが、もうひとつやることがあります。CloudWatch にメトリクスを書き込む許可を CW エージェントに提供することです。これにはサービスアカウントの IAM ロール (IRSA) を使用します。これは、最小権限のアクセスコントロールを許可する EKS 機能で、CW エージェントを実行するポッドへの直接的な CloudWatchAgentServerPolicy
を通じて CW へのアクセスを事実上制限します。
これで、セットアップを検証できるようになりました。まず、CW エージェントデプロイメントによって使用されるサービスアカウントが適切にアノテートされているかどうかをチェックします (ここでは eks.amazonaws.com/role-arn
キーのアノテーションを確認してください)。
また、kubectl -n amazon-cloudwatch get pod
で CWAgent が適切に実行されていることも検証してください。これは、
Running
状態になっているはずです。
すべてがデプロイおよび実行されたところで、以下のように CLI からメトリクスをクエリできるようになります。
上記の aws logs
コマンドの出力は、以下のようになります (最後の value
フィールドでエンコードされている Prometheus メトリクスに注意してください)。
NGINX からの例で Prometheus メトリクスをスクレイプして追加設定なしで使用する方法を確認したところで、カスタムメトリクスを使用する方法に進みましょう。
ASP.NET Core アプリからのカスタムメトリクス
以下のセットアップでは、Prometheus クライアントライブラリを使用して ASP.NET Core アプリケーションを計装します。ここでの目標は、カスタムメトリクスを公開して、これらのメトリクスを CloudWatch に取り込むことです。これは、カスタム設定された CloudWatch Prometheus エージェントを使って実行します。
カスタムメトリクスを公開するためのアプリの計装
まず、aws-samples/amazon-cloudwatch-prometheus-metrics-sample からサンプルアプリケーションをクローンし、HomeController.cs
ファイルを検証します。
ProductsController.cs
ファイルも検証します。
上記のコードスニペットは、オープンソースの Prometheus クライアントライブラリを使って、各ページへの訪問者数と全体的な訪問者数を追跡するための 3 つの異なるメトリクスを計装します。
次に、ローカルでのテストとプレビューのため、Dockerfile
があるディレクトリに移動します。以下のコマンドを使ってコンテナイメージを構築し、実行します。
localhost
に移動します。ここでは、以下のような画面が表示されるはずです。[Home] および [Products] リンクを数回クリックして、トラフィックを生成します。
次に、http://localhost/metrics
に移動します。ここには、/metrics
エンドポイントを通じてアプリが公開しているすべての Prometheus メトリクスが表示されます。
Prometheus メトリクス検出のための CloudWatch エージェントの設定
リポジトリにある /kubernetes
フォルダの prometheus-eks.yaml
ファイルを開きます。YAML ファイルの cwagentconfig.json
セクションにある以下の設定は、CloudWatch エージェントがアプリケーションからスクレイプするメトリクスを示しています。
prometheus.yaml
には、標準の Prometheus 設定を使って、Prometheus メトリクスエンドポイントの詳細を CloudWatch エージェントに指示するセクションがあります。address
ソースラベルの regex を変更して、サンプルアプリケーションがメトリクスを公開しているエンドポイントとポート番号に一致させる必要があることに注意してください。
アプリと CloudWatch Prometheus エージェントのデプロイメント
まず、先ほど構築した ASP.NET Core アプリの Docker コンテナイメージを、独自に選択するコンテナレジストリにプッシュします。次に、deployment.yaml
ファイルの <YOUR_CONTAINER_REPO>
を、イメージを発行したコンテナリポジトリの値に変更します。
すべてが設定されたところで、以下のコマンドを使ってサンプルアプリケーションと CloudWatch Prometheus エージェントを Kubernetes クラスターにデプロイします。
この時点で、オプションとして Kubernetes クラスターで CloudWatch Container Insights を有効化できることに注意してください。これは、AWS マネジメントコンソールでのインフラストラクチャマップと自動ダッシュボードの表示を可能にします。
セットアップは、次のように検証できます (すべてのポッドが Running 状態になっているはずです)。
カスタムダッシュボードの作成
us-east-2
AWS リージョンで PrometheusDotNetApp
という名前のカスタムダッシュボードを作成するには、次を実行します。
別のリージョンにダッシュボードを作成したい場合は、JSON config ファイルの us-east-2
を希望する値に置き換えてください。
これで、作成した CloudWatch ダッシュボードに移動できるようになります。ダッシュボードは以下のようになるはずです。
CloudWatch Container Insights は、Kubernetes クラスターからのパフォーマンスメトリクスに基づいて自動ダッシュボードをパブリッシュします。CloudWatch Container Insights のパフォーマンスモニタリングページに移動して、Container Insights によって作成された自動ダッシュボードを表示してください。
CloudWatch Container Insights が有効化されているので、[リソース] から、コンポーネントを含めた Kubernetes クラスタートポロジを表示するマップビューにアクセスできます。
カスタムメトリクス例のシナリオはこれで終了です。では、今後について簡単に見てみましょう。
次のステップ
私たちは、Prometheus メトリクスに対する CloudWatch Container Insights サポートの公開ベータを開始できることをとてもうれしく思っています。皆さんがこの新しい機能をどのように使用し、将来何を期待しておられるかについて、ぜひお聞かせください。たとえば、PromQL サポート、または Prometheus のヒストグラムやサマリーメトリクスのネイティブサポートなどがあります。ご提案と経験の共有には、containerinsightsfeedback@amazon.com をご利用ください。AWS では、皆さんのフィードバックに基づいて機能の改善と追加を絶えず行っているため、今後も AWS でのコンテナ分野に引き続きご注目ください。