Amazon Web Services ブログ

Amazon Managed Service for Prometheus の一般提供開始

この記事は Amazon Managed Service for Prometheus is now Generally Available (記事公開日: 2021 年 9 月 30 日) を翻訳したものです。

re: Invent 2020 では、フルマネージドな Prometheus 互換サービスである Amazon Managed Service for Prometheus をAWS 上にプレビューとしてローンチしました。これは、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Compute Cloud (EC2) などのさまざまな環境でホストされているワークロードから、さらにオンプレミスの仮想マシンのようなハイブリッド環境からもインフラストラクチャとアプリケーションのメトリクスを収集するために利用できる、安全でスケーラブルなサービスです。

メトリクスは可観測性の重要な柱であり、Prometheus は Cloud Native Compute Foundation (CNCF) を卒業した、非常に人気のあるオープンソースのメトリック監視ソリューションです。Prometheus は、モダンなコンテナベースの環境で幅広くサポートされており、NGINX、Java/JMX、Envoy、その他多数のワークロードなど、多くの一般的なワークロードが Prometheus 形式でメトリクスをネイティブにエクスポートします。これにより、お客様は正常性とパフォーマンスを簡単に収集して監視できます。

Amazon Managed Service for Prometheus をご利用のお客様は、管理する必要のない、Prometheus 互換の堅牢なバックエンドの恩恵を受けることができます。AWS Distro for OpenTelemetry コレクター (ADOT コレクター) や Prometheus Server などの収集エージェントをデプロイするだけで、Amazon Managed Service for Prometheus にメトリクスを安全にリモート書き込みできます。

プレビューでサービスを開始して以来、お客様はこのサービスを利用してさまざまなワークロードを監視しており、サービス機能の改善に向けて貴重なフィードバックを提供してくださいました。私達は Amazon Managed Service for Prometheus が一般提供を開始したことをお知らせします。

新機能

  • アラートマネージャー とルール管理
    • お客様は、Amazon Managed Service for Prometheus の Prometheus 互換のアラートマネージャーおよびルール管理機能を利用できます。これにより、お客様が独自のアラートおよびルール管理機能をホストする必要性が軽減されます。設定と機能の詳細については、以下の “Alert Manager の詳細” セクションを参照してください。
  • タグ付けのサポート
    • お客様はワークスペースにタグを付けて、管理、識別、整理、フィルタリング、アクセス制御に役立てることができるようになりました。この新機能により、お客様はワークスペースにタグを追加してリソースを特定し、ワークスペースへのきめ細かいアクセス制御を提供し、タグに基づいてワークスペースのコスト使用率を特定できます。
  • CloudFormation と CDK (AWS Cloud Development Kit) のサポート
    • ワークスペースやルール、アラート管理設定のライフサイクルを自動化、作成、管理することは、運用にとって非常に重要です。GA により、お客様は AWS CloudFormation と CDK を利用して、Amazon Managed Service for Prometheus ワークスペースの作成と管理、AWS タグの関連付け、アラートと記録ルールの作成と管理を行うことができます。
  • 追加の AWS リージョンでの可用性
    • アジア太平洋地域とヨーロッパ地域を新たに 3 つ追加します。その結果、お客様は、以下のAWS リージョンで Amazon Managed Service for Prometheus ワークスペースを作成できるようになりました: US East-1 (N.Virginia), US-East-2 (Ohio), US-West-2 (Oregon), EU-Central-1 (Frankfurt), EU-West-1 (Ireland), EU-North-1 (Stockholm), AP-SOUTHEAST-2 (Sydney), AP-NORTHEAST-1 (Tokyo), and AP-SOUTHEAST-1 (Singapore)
  • CloudTrail との統合
    • Amazon Managed Service for Prometheus ユーザーは、ワークスペース上で AWS CloudTrail における拡張されたログセットと、作成、変更、削除などのようなアラートおよび記録ルールの操作を表示できるようになりました。

記録ルールとアラートマネージャーの設定

以下の手順では、Amazon Managed Service for Prometheus でのルールとアラートマネージャーの設定について説明します。アラートマネージャーは現在、Amazon Simple Notification Service (SNS) を送信先としてサポートしています。

前提条件

次のものがインストールされ、設定されていることを確認して、セットアップの手順に従います。

Amazon Managed Service for Prometheusのセットアップ

コンテナ環境で Prometheus を利用しているお客様は、可用性、拡張性、安全性に優れた Prometheus サーバー環境、長期保存のためのインフラストラクチャ、およびアクセス制御を管理する際に課題に直面します。Amazon Managed Service for Prometheus は、認証と承認を制御するために AWS Identity and Access Management (IAM) と緊密に統合された、フルマネージドサービスを提供することでこれらの問題を解決します。また、CloudTrail ログによる監査機能も提供します。次の 2 つのステップに従い、Amazon Managed Service for Prometheus を使い始めましょう。

  • Amazon Managed Service for Prometheus のワークスペースを作成する。
  • AWS Distro for Open Telemetry をAmazon Managed Service for Prometheus のワークスペースにリモート書き込みするように設定します。また、この リンクの手順に従って、Prometheus サーバーを使用してメトリクスをスクレイピングし、Amazon Managed Service for Prometheus に送信することもできます。

ワークスペースを作成する

ワークスペースは、1 つまたはそれ以上の Prometheus サーバーからなるメトリクスの保存、アラーティング、およびクエリを行うことができる専用の論理スペースです。ワークスペースでは、更新、一覧表示、概要表示、削除などの管理や、メトリクスの取り込みやクエリを権限付与するためのきめ細かいアクセス制御がサポートされています。

CLI を使用してワークスペースを設定するには、以下のコマンドを実行します。

aws amp create-workspace --alias my-first-workspace

このコマンドは次のデータを返します。

  • workspaceId はこのワークスペースに対する一意の ID です。この ID を書き留めておきます。
  • arn はこのワークスペースの ARN です。
  • status は現在のワークスペースのステータスです。ワークスペースを作成した直後は、おそらく CREATING になります。

CloudFormation を使ってワークスペースを作成する

AWS:: APS:: Workspace タイプは、Amazon Managed Service for Prometheus のワークスペースを指定します。AWS CloudFormation テンプレートでこのエンティティを宣言するには、次の構文を使用します。

Resources:
  APSWorkspace:
    Type: AWS::APS::Workspace
    Properties:
      Alias: <your workspace name>
      Tags:
      - Key: Key1
        Value: Value1

ワークスペースにタグを追加する

ワークスペースにタグを追加すると、AWS リソースの識別と整理、およびアクセスの管理に役立ちます。まず、1 つ以上のタグ (キーと値のペア) をワークスペースに追加します。タグを作成したら、IAM ポリシーを作成して、そのタグに基づいてワークスペースへのアクセスを管理します。タグを追加するために、コンソールまたは AWS CLI を使用します。

aws amp tag-resource --resource-arn arn:aws:aps:us-west-2:<your-account-id>:workspace/IDstring --tags Status=Secret,Team=My-Team

AWS Distro for OpenTelemetry を使用して Prometheus メトリクスをワークスペースに取り込む

このセクションでは、AWS Distro for OpenTelemetry (ADOT) コレクターが Prometheus でインスツルメントされたアプリケーションからスクレイピングし、Amazon Managed Service for Prometheus にメトリクスを送信するように設定する方法について説明します。

ADOT で Prometheus メトリクスを収集するには、Prometheus Receiver と AWS Prometheus Remote Write Exporter という 2 つの OpenTelemetry コンポーネントが必要です。サービスディスカバリとメトリクスクレイピングを実行するために既存の Prometheus 構成を使用して Prometheus Receiver を設定します。Prometheus Receiver は、Prometheus exposition format でメトリクスをスクレイピングします。スクレイピングしたいアプリケーションまたはエンドポイントは、Prometheus クライアントライブラリを使用して設定する必要があります。Prometheus Receiver は、Prometheus のドキュメント中の Configuration で説明されているように、Prometheus スクレイピングおよび再ラベル付け設定のフルセットをサポートしています。これらの設定を ADOT Collector 設定に直接貼り付けます。

スクレイピングされたメトリクスを管理ポータルのワークスペースに送信するために、AWS Prometheus Remote Write Exporter は remote_write エンドポイントを使用します。データをエクスポートする HTTP リクエストは、安全な認証のための AWS プロトコルである AWS Sigv4 で署名されます。詳細については、シグネチャーバージョン 4 の署名プロセスを参照してください。

以下の取り込み設定手順を開始する前に、サービスアカウントと信頼ポリシーの IAM ロールをセットアップします。Amazon EKS クラスターからメトリクスを取り込むためのサービスロールのセットアップの手順に従って、サービスアカウントの IAM ロールを作成します。ADOT Collector は、メトリクスのスクレイピングとエクスポート時にこのロールを使用します。

次に、前のステップで作成した amp-iamproxy-ingest-role の信頼ポリシーを編集し、aws-amp を adot-col に置き換えます。最終的なポリシーは次のように表示されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::account-id:oidc-provider/oidc.eks.aws_region.amazonaws.com/id/openid"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.aws_region.amazonaws.com/id/openid:sub": "system:serviceaccount:adot-col:amp-iamproxy-ingest-service-account"
                }
            }
        }
    ]
}

ADOT を使用したメトリクスのスクレイピングのデモンストレーションを行い、メトリクスをワークスペースにリモート書き込みするために、サンプルアプリケーションを利用します。aws-otel-community のリポジトリからサンプルアプリケーションをフォークしてクローンします。以下のコマンドを実行します（訳注: わかりやすさのためにコマンドを追加しています）。

git clone 'https://github.com/aws-observability/aws-otel-community.git'
cd aws-otel-community/
cd ./sample-apps/prometheus-sample-app/
docker build . -t prometheus-sample-app:latest

イメージを ECR や DockerHub などのレジストリーにプッシュします。そして、prometheus-sample-app.yaml ファイルのコンテナイメージリポジトリ URL を イメージプロパティに設定することでプッシュしたイメージに変更し、次のコマンドを実行します。

curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/examples/eks/aws-prometheus/prometheus-sample-app.yaml -o prometheus-sample-app.yaml
kubectl apply -f prometheus-sample-app.yaml

ここで、ADOT Collector をデプロイするには次のコマンドを実行します。

curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/examples/eks/aws-prometheus/prometheus-daemonset.yaml -o prometheus-daemonset.yaml

次に、prometheus-daemonset.yaml ファイルを編集し、 YOUR_ENDPOINT を Amazon Managed Service for Prometheus ワークスペースへの remote_write エンドポイントに、 YOUR_REGION をワークスペースのリージョンに置き換えます。remote_write エンドポイントは、Amazon Managed Service for Prometheus コンソールの、ワークスペースの詳細から確認できます。

同様に、Kubernetes 設定のサービスアカウントセクションにある YOUR_ACCOUNT_ID を AWS アカウント ID に変更します。

この例では、スクレイピングするターゲットエンドポイントを特定するために、ADOT Collector 設定はアノテーション (scrape=true) を利用しています。これにより、ADOT Collector はサンプルアプリのエンドポイントをクラスター内の kube-system エンドポイントと区別できます。別のサンプルアプリをスクレイピングする場合は、再ラベル設定からこれを削除してください。

ADOT Collector を展開し、正常に実行されているかどうかを確認するには、次のコマンドを実行します。

kubectl apply -f prometheus-daemonset.yaml

awscurl を使用して、Amazon Managed Service for Prometheus がメトリクスを受信したかどうかをテストします。このツールを使用すると、AWS Sigv4 認証を使用してコマンドラインから HTTP リクエストを送信できます。awscurlを使用するには、Amazon Managed Service for Prometheus からクエリを実行するためには、AWS 認証情報が正しいアクセス権限でローカルに設定されている必要があります。

次のコマンドの、Amazon_Managed_Service_for_Prometheus_ENDPOINT を、Amazon Managed Service for Prometheus ワークスペースの情報に置き換えます（訳注: Amazon_Managed_Service_for_Prometheus_REGION も同様に置き換えてください）。

awscurl --service="aps" --region="Amazon_Managed_Service_for_Prometheus_REGION" "https://Amazon_Managed_Service_for_Prometheus_ENDPOINT/api/v1/query?query=adot_test_gauge0"

アラートマネージャーの詳細

このセクションでは、AWS マネジメントコンソールを使用して Amazon Managed Service for Prometheus でルールとアラートマネージャーを設定する手順を説明します。

記録ルールとアラートルール

Amazon Managed Service for Prometheus は、時系列データの収集と処理をアラートシステムに統合します。Prometheus は、記録ルールとアラートルールの 2 種類のルールを設定して定期的に評価できます。お客様は PromQL を利用してルールを設定できます。アドホッククエリとダッシュボードに使用されるのと同じクエリ言語が、アラートルールの定義にも使用されます。

記録ルールを使用すると、頻繁に必要とされる、または計算量の多い式を事前に計算し、その結果を新しい時系列のセットとして保存できます。その場合、事前に計算された結果をクエリすると、必要に応じて元の式を実行するよりもはるかに高速になることがよくあります。

アラートルールを使用すると、Prometheus 式の言語式に基づいてアラート条件を定義し、Alert Manager に通知を送信できます。アラート式が特定の時点で 1 つまたは複数のベクトル要素を生成すると、アラートはこれらの要素のラベルセットに対してアクティブとしてカウントされます。

記録ルールとアラートルールはルールグループ内に存在します。グループ内のルールは、一定の間隔で、同じ評価時間で順番に実行されます。記録ルール名は有効なメトリック名である必要があります。アラートルール名は有効なラベル値である必要があります。

次のルールファイルの例では、特定の条件（expr で定義されている）が指定した期間（for）に当てはまる場合に、Alert Manager に通知を送信させるアラートルールを定義しています。

cat << EOF > rules.yaml
groups:
  - name: test
    rules:
    - record: metric:recording_rule
      expr: rate(adot_test_counter0[5m])
  - name: alert-test
    rules:
    - alert: metric:alerting_rule
      expr: rate(adot_test_counter0[5m]) > 0.014
      for: 5m
EOF

この設定では、メトリクス“adot_test_counter0”の式が 5 分間にわたって実行されており、その値が 5 分間しきい値“0.014”を超えるとアラートが発行されることが示されています。さまざまなユースケースに対するアラートルールの設定例については、リンク先を参照してください。

ファイルが作成されたら、Amazon Managed Service for Prometheus コンソールに YAML ファイルをアップロードします。

Figure 1: Rules management

Figure 1: Rules management

Alert Manager

Alert Manager は、Prometheus サーバーなどのクライアントアプリケーションから送信されるアラートを処理します。重複排除、グループ化、および正しい SNS 受信者へのルーティングを処理します。お客様は、もし計画的なメンテナンスがあることがわかっている場合などに、アラートを止めることができます。アラート疲れを軽減するために、お客様は抑制ルールを使ってアラートを抑制することができます。たとえば、1 つのクラスタアラートを発生させ、個々のノードまたはコンテナのアラートをミュートします。

設定されたアラートルールは Alert Manager にアラートを送信し、Alert Managerは SNS レシーバを介して SNS に通知をルーティングできます。Amazon Managed Service for Prometheus の Alert Manager は現在、その送信先として SNS をサポートしています。これにより、Slack、PagerDuty、OpsGenie などのさまざまな宛先に通知を送信できます。

次の YAML は、SNS に通知を送信するAlert Manager の定義の例を示しています。先に進む前に、このリンクに従って、SNS トピックとサブスクリプションを作成したことを確認してください。

cat << EOF > alertmanager.yaml
alertmanager_config: |
  route:
    receiver: 'default'
  receivers:
    - name: 'default'
      sns_configs:
      - topic_arn: arn:aws:sns:us-east-1:xxxxxxxxxxxx:Amazon_Managed_Service_for_Prometheus-AlertManager
        sigv4:
          region: us-east-1
        attributes:
          key: severity
          value: SEV2
EOF

ファイルが作成されたら、Amazon Managed Service for Prometheus のワークスペースの Alert manager タブにアップロードできます。

Figure 2: Alert configuration details

Figure 2: Alert configuration details

設定で指定された SNS トピックにメッセージを送信するには、Amazon Managed Service for Prometheus に対する適切なアクセスポリシーが必要です（訳注: 前のステップで作成したSNS トピックのアクセスポリシーに以下を追加します）。

{
    "Sid": "Allow_Publish_Alarms",
    "Effect": "Allow",
    "Principal": {
        "Service": "aps.amazonaws.com"
    },
    "Action": [
        "sns:Publish",
        "sns:GetTopicAttributes"
    ],
    "Resource": "arn:aws:sns:<region-code>:<account_id>:<topic_name>"
}

上記のステップが完了したら、Amazon Managed Grafana インスタンスのデータソースとして Amazon Managed Service for Prometheus を使用して、セットアップをエンドツーエンドで検証します（訳注: AMGのセットアップについてはこちらを、GrafanaにAMPをデータソースとして設定する方法はこちらをご覧ください）。メトリック “metric:recording_rule” を探し、メトリクスが正常に見つかれば、記録ルールを正常に作成できたことになります。

Figure 3: Recording rule metric on Grafana console

Figure 3: Recording rule metric on Grafana console

次のコマンドを実行して、セットアップに負荷をかけて検証します。

$WORKSPACE_ID を、Amazon Managed Service for Prometheus ワークスペースの ID に置き換えてください（訳注: ワークスペースがバージニア北部リージョンではない場合は us-east-1 も適切なリージョンコードに置き換えてください）。

awscurl https://aps-workspaces.us-east-1.amazonaws.com/workspaces/$WORKSPACE_ID/api/v1/rules --service="aps"

アラートが発火されたことを確認できる成功結果が表示されます。Alert Manager エンドポイントにクエリを実行して、同じことを確認できます。

awscurl https://aps-workspaces.us-east-1.amazonaws.com/workspaces/$WORKSPACE_ID/alertmanager/api/v2/alerts --service="aps" -H "Content-Type: application/json"

クリーンアップ

以下のコマンドを実行して、Amazon Managed Service for Prometheus ワークスペースを終了します。作成した EKS クラスターも必ず削除してください。

aws amp delete-workspace <your workspace alias>

次のステップ

mazon Managed Services for Prometheus を今日にでもお試しください。 このサービスが一般提供され、他のリージョンでも利用できるようになったため、お客様がこのサービスを利用してどのようなサービスを構築していくのかを楽しみにしています。

また、Amazon Managed Service for Prometheus から運用メトリクスを取り込んだりクエリしたりするための経験、知識、追加サービスを提供するAppDynamics、Contino、Dynatrace、kubecost、NTT データ、Rafay、Reply、Tech Mahindra、Wipro などの AWS パートナーと連携してください。パートナーの詳細については、パートナーページ をご覧ください。

また、GAの立ち上げの一環として、他のトピックを取り上げたブログも公開しました。

また、お客様は Amazon Managed Grafana を利用して、Amazon Managed Service for Prometheus およびその他の多くのデータソースのメトリクスを視覚化することもできます。Amazon Managed Grafana は 2021年8 月末に一般提供を開始しました。このサービスについて詳しく説明しているこの ブログ投稿 を読むことをお勧めします。このサービスのハンズオンを試したい場合は、 Observability Workshop を調べてください。

著者について

Imaya Kumar Jagannathan

Imaya は、Amazon CloudWatch、AWS X-Ray、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS Distro for Open Telemetry などの AWS の可観測性サービスにフォーカスしているプリンシパルソリューションアーキテクトです。彼は監視と可観測性に情熱を傾けており、アプリケーション開発とアーキテクチャの豊富なバックグラウンドを持っています。分散型システムでの作業と、マイクロサービスアーキテクチャ設計について話すことが好きです。彼は C# でのプログラミングが大好きで、コンテナやサーバーレステクノロジーを扱っています。Twitter と LinkedIn で @imaya を見つけてください.

Vikram Venkataraman

Vikram Venkataraman は、アマゾンウェブサービスのシニアテクニカルアカウントマネージャーであり、コンテナ愛好家でもあります。AWS でワークロードを実行するためのベストプラクティスを提供し、組織を支援しています。余暇には、2人の子供と遊ぶのが大好きで、クリケットを観戦しています。

Marc Chene

Marc Chene

Marc は、モダンなアプリケーション環境でのマイクロサービスとコンテナのモニタリングにフォーカスしているプリンシパルプロダクトマネージャーです。理解を深め、信頼を築き、アジャイルな方法で最高のユーザーエクスペリエンスを提供するためにお客様と協力しています。現在は、CloudWatch と、Grafana および Prometheus といったオープンソースツールを使ったメトリクス、ログ、および分散トレーシングなどの時系列データ全体での最高のオブザーバビリティエクスペリエンスの実現に取り組んでいます。

翻訳はソリューションアーキテクトの 藤嶋 が担当しました。本記事は翻訳にあたり、一部記述を追加および修正しています。