Amazon Managed Service for Prometheus を使用してオンプレミスのメトリクスを収集する

Prometheus は人気の高いオープンソースのメトリクスモニタリングソリューションで、さまざまなワークロードで広く利用されています。Prometheus を使用してコンテナワークロードを監視するのが一般的ですが、Prometheus は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスやオンプレミス環境の仮想マシン (VM)、サーバーの監視にも使用されています。

Amazon Managed Service for Prometheus (AMP) は、インフラストラクチャおよびアプリケーションメトリクスのための Prometheus 互換のモニタリングサービスであり、お客様は大規模なワークロードを安全にモニタリングすることが容易になります。セルフホスト環境で Prometheus を使用するお客様は、高可用性、拡張性、安全性を備えた Prometheus サーバー環境、メトリクスの長期保存のためのインフラ環境、アクセス制御の管理に課題を抱えています。AMP は AWS Identity and Access Management (IAM) と密に統合されたフルマネージドな環境を提供することで、これらの課題を解決します。

AMP を使い始めるには、以下の2つのステップを実行します。

• AMP ワークスペースを作成します。
• AMP ワークスペースに remote write するように Prometheus サーバーを設定します。

AMP ワークスペースに remote write するには、IAM の権限とポリシーを持つ IAM ロールが必要です。これは、IAM ロールがインスタンスで利用できないオンプレミス環境では課題となります。この課題の一般的なソリューションはプログラムによるアクセスキーを使用することです。セキュアな場所に保存した認証情報をアプリケーション起動時に取得することによって実現できますが、認証情報のローテーションなどのベストプラクティスに準拠することが困難になります。

そのため、より良いアプローチとして AWS Security Token Service (AWS STS) による一時的なクレデンシャルを使用することがあげられます。しかし、アイデンティティ・フェデレーション (SAML、OIDCなど) を使用し、Prometheus の remote write 部分を変更する必要が出てきます。

AWS Systems Manager (SSM) によって、AWS STS を安全な方法で使用することができます。Systems Manager を使えばコードを書き換えることなく、AMP ワークスペースへの remote_write アクセスが可能になります。

Systems Manager を使用して、AWS 上のインフラとオンプレミスのリソースを管理することもできます。Systems Manager コンソールから AWS サービスの運用データを表示したり、AWS リソース全体の運用タスクを自動化したりすることができます。Systems Manager は、マネージドインスタンスをスキャンし、検出されたポリシー違反を報告する（または是正措置を取る）ことでセキュリティとコンプライアンスを維持します。

マネージドインスタンスとは、Systems Manager で使用するために設定されたマシンのことです。サポートされているマシンタイプには、EC2インスタンス、オンプレミスサーバー、VM (他のクラウド環境の VM を含む) があります。サポートされているオペレーティングシステムの種類には、Windows Server、macOS、Raspbian、および複数の Linux ディストリビューションがあります。

ハイブリッド環境にて Systems Manager を使用するには、対象のインスタンスへの SSM エージェントのデプロイ、および IAM ロールの作成が必要です。SSM エージェントは、Amazon Trust Services の証明書または AWS Certificate Manager (ACM) によるプライベート証明書を使用して、アクティベーションプロセスを行います。ほとんどの最新の OS (WindowsとLinux) の信頼ストアには、すでに Amazon Trust Services の証明書群が含まれています。証明書を手動でインストールする方法については、「オンプレミスのサーバーや VM に TLS 証明書をインストールする」を参照してください。

Prometheus 環境での SSM エージェントについて

SSM エージェントの登録プロセスでは、SSM エージェントを実行しているユーザーのホームパス (デフォルトでは root ) にクレデンシャルファイルが作成されます。SSM エージェントは、AWS STS を通じて一時的な認証情報を要求することで、クレデンシャルファイルを更新し続けます。このことは、アクティベーションプロセスで指定したインスタンスにロールを割り当てることになります。必要なパーミッションを設定することで、AMP クラスターでの remote write 操作に同じクレデンシャルを使用することができます。

図 1: アーキテクチャ

SSM エージェントの設定

SSM エージェントはオープンソースのプロジェクトです。GitHub の公開リポジトリにアクセスできます。本ブログでは、「ハイブリッド環境に AWS System Manager をセットアップする」の手順に沿って説明します。「ステップ1: Systems Manager の一般的なセットアップ手順を完了する」で説明されているように、Systems Manager がすでに構成されていることを前提とします。

AMP ワークスペースの作成

以下のスクリプトでは、us-east-1 リージョンに AMP ワークスペースを作成します。必要に応じて変数の WORKLOAD_REGION を変更して、AMP がサポートされている別の AWS リージョンを使用することができます。

WORKLOAD_REGION='us-east-1'

WORKSPACE_ID=$(aws amp create-workspace --alias onpremises-demo-workspace \
  --region $WORKLOAD_REGION \
  --output text \
  --query 'workspaceId')
  
WORKSPACE_URL=$(aws amp describe-workspace --region $WORKLOAD_REGION --workspace-id $WORKSPACE_ID --query workspace.prometheusEndpoint --output text)

echo "This is the URL for remote_write configuration you must copy to your VM:\n $WORKSPACE_URL"
echo "export WORKSPACE_ID=$WORKSPACE_ID" >> delete.env

ハイブリッド環境用のIAMサービスロールの作成

次のコマンドを使用して、Systems Manager が VM の代わりにロールを引き受けることを許可するポリシーを持つ IAM ロールを作成します。

cat > SSMService-Trust.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [    
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ssm.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
aws iam create-role \
    --role-name SSMServiceRoleRemoteWrite \
    --assume-role-policy-document file://SSMService-Trust.json 

この空のロールにポリシーを割り当てます。1つ目のポリシーである AmazonSSMManagedInstanceCore は、SSM エージェントが基本操作を実行する際に必要です。2つ目のポリシーである AmazonPrometheusRemoteWriteAccess は、先ほど作成した AMP ワークスペースへの remote write 操作を実行する際に必要となります。

aws iam attach-role-policy \
    --role-name SSMServiceRoleRemoteWrite \
    --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore  
    
aws iam attach-role-policy \
    --role-name SSMServiceRoleRemoteWrite \
    --policy-arn arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess 

ハイブリッド環境のマネージドインスタンスアクティベーションの作成

ハイブリッド環境のサーバーや VM をマネージドインスタンスとして設定するには、マネージドインスタンスのアクティベーションを作成する必要があります。アクティベーションが正常に完了すると、アクティベーションコードとアクティベーション ID が発行されます。このコードと ID の組み合わせは、ハイブリッド環境のサーバーと VM に SSM エージェントをインストールする際に指定します。また、管理対象のマネージドインスタンスから Systems Manager への安全なアクセスを提供します。詳細については、「ハイブリッド環境に AWS Systems Manager をセットアップする」をご参照ください。

このクレデンシャルペアは、Systems Manager に VM を登録するために使用されるため、保存されたりサービスとの通信に使用されたりすることはありません。マネージドインスタンスとして登録されると、SSM エージェントは非対称キーペアを生成し、それを使用して正常に機能するために必要な一時的なクレデンシャルを取得します。キーペアはマシンに一意に結び付けられます。この登録は Systems Manager からいつでも削除することができるため、長期的なクレデンシャルよりも優れた選択肢となっています。

アクティベーションを作成するためのオプションについては深く掘り下げません。以下のコマンドにて、コードと ID の組み合わせで登録できるインスタンスの数 、アクティベーションウィンドウの有効期限 (クレデンシャルペアが新しいサーバーのアクティベーションに使用できる時間) 、適切なタグ付けなどを指定できます。

EXPIRATION=$(date -u -v +1H +%Y-%m-%dT%H:%M:%S)
aws ssm create-activation \
    --default-instance-name OnPremisesServer \
    --iam-role SSMServiceRoleRemoteWrite \
    --registration-limit 1 \
    --region $WORKLOAD_REGION \
    --expiration-date $EXPIRATION \
    --tags "Key=Department,Value=Accounting" "Key=DataClassification,Value=Restricted"

アクティベーション ID とアクティベーションコードをメモしておいてください。次のステップで必要になります。

ハイブリッド環境での SSM エージェントのインストール

オンプレミスの VM で、本ブログの残りのコマンドを実行します。

本ブログでは、VirtualBox 上で動作する Ubuntu 20.04 インスタンスを使用しています。インスタンスをインストールして設定する手順は扱いません。事前に最小限の要件でインスタンスをインストールし、最新版へアップデートしてください。Linux の手順については、「ハイブリッド環境での SSM エージェントのインストール (Linux)」を、Windows の手順については、「ハイブリッド環境用の SSM エージェントのインストール (Windows)」をご参照ください。

VM 上では、事前に構築された Debian パッケージを使用して SSM エージェントをインストールします。

mkdir /tmp/ssm
curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
sudo service amazon-ssm-agent stop

次に、先ほど払い出されたアクティベーション ID とアクティベーションコードを使って SSM エージェントをアカウントに登録します。

sudo -E amazon-ssm-agent -register -code “activation-code” -id “activation-id” -region “region” 
sudo service amazon-ssm-agent start

処理が成功すると、マネージドインスタンスの ID を含む以下のようなメッセージが表示されます。

2021-05-17 15:24:49 WARN Could not read InstanceFingerprint file: InstanceFingerprint does not exist.
2021-05-17 15:24:49 INFO No initial fingerprint detected, generating fingerprint file…
2021-05-17 15:24:50 INFO Successfully registered the instance with AWS SSM using Managed instance-id: mi-12345678901234567

インスタンスが正しくレポートされていることを確認するには、Systems Manager コンソールで Fleet Manager を選択します。インスタンスが表示され、SSM エージェントのステータスが Online になっているはずです。数秒後、インスタンスに関する情報が、アクティベーションリクエストに渡されたタグとともに入力されます。

図 2: Fleet Manager でのインスタンス概要

SSM エージェントは、エージェントを実行したユーザー (デフォルトでは root) のルートフォルダで資格情報を管理します。

以下のコマンドを使用して、ファイルが存在するかどうかを確認します。

rpereyra@onpremises:~$ sudo ls -al /root/.aws/
total 12
drw------- 2 root root 4096 May 17 15:34 .
drwx------ 5 root root 4096 May 17 15:25 ..
-rw-r--r-- 1 root root 1158 May 17 15:34 credentials

Prometheus サーバーのインストール

SSM エージェントがインスタンスの root ユーザーに一連のクレデンシャルファイルを提供するようになったので、Prometheus サーバーをインストールして AMP ワークスペースへのメトリクスのエクスポートを開始することができます。以下のコマンドを使用して、Prometheus をダウンロードします。

mkdir /tmp/prometheus
curl -L https://github.com/prometheus/prometheus/releases/download/v2.27.0/prometheus-2.27.0.linux-amd64.tar.gz -o /tmp/prometheus/prometheus-2.27.0.linux-amd64.tar.gz
cd /tmp/prometheus
tar -xvzf prometheus-2.27.0.linux-amd64.tar.gz
cd prometheus-2.27.0.linux-amd64

ここで、AMP ワークスペースにメトリクスを送信 (remote_write) するように Prometheus を設定してから、Prometheus を起動します。

cp prometheus.yml prometheus.yml.bak
WORKSPACE_URL=<paste value here>
WORKLOAD_REGION=<AMP workspace region>
cat >> prometheus.yml << EOF

remote_write:
  - url: ${WORKSPACE_URL}api/v1/remote_write
    sigv4:
      region: $WORKLOAD_REGION
EOF
chmod +x prometheus
sudo ./prometheus

注：今回のサンプルでは、Prometheus はフォアグラウンドで一時フォルダから起動していますが、この方法はほとんどのシナリオで実用的ではありません。おそらく、Prometheus をシステムサービスとして実行する必要があるでしょう。そのようなケースでは、Prometheus は同じクレデンシャルファイルを共有しなければならないことに注意してください。AWS SDK は、ユーザーのホームフォルダー ($HOME/.aws/credentials) でクレデンシャルファイルを探します。本記事では簡単にするために、両方のプロセスを root ユーザーで実行しています。お使いの OS によっては、同じユーザーを共有しないようにしたり、最小権限を適用したりなどの対策が必要になるかもしれません。

Prometheus サーバーが起動すると、AMP の remote_write で指定したワークスペースにメトリクスが送られてきます。ローカル環境に Grafana をインストールするか、Amazon Managed Grafana (AMG) のワークスペースを作成することで、メトリクスを可視化することができます。

次の図は、AMG ワークスペースを介して AMP からメトリクスを可視化する方法を示しています。

図 3: go_gc_duration_seconds_count

Prometheus サーバーの代わりに Grafana エージェントを使用する

Prometheus サーバーを実行する代わりに、オープンソースの軽量なエージェントである Grafana Cloud Agent を使用することもできます。Grafana Cloud Agent は Prometheus エクスポーターの検出とスクレイピング、バックエンド (ここでは AMP) へのメトリクスの送信に必要な部分を残し、ストレージ、クエリ、アラートエンジンなどのサブシステムを削除しています。

このセクションでは、Prometheus サーバーの代わりに Grafana Cloud Agent を導入してメトリクスを収集する方法を紹介します。Prometheusサーバーを起動している場合は、Control - C を押してコンソールのセッションを閉じ、以下のコマンドを実行して Grafana Cloud Agent をインストールします。

sudo apt install unzip
mkdir /tmp/grafana-agent
cd /tmp/grafana-agent
curl -O -L "https://github.com/grafana/agent/releases/download/v0.14.0-rc.4/agent-linux-amd64.zip" 
unzip "agent-linux-amd64.zip"
chmod a+x "agent-linux-amd64"

cat >> agent.yml << EOF
server:
  log_level: info
  http_listen_port: 9090
prometheus:
  wal_directory: /var/lib/grafana-agent
  global:
    scrape_interval: 15s
integrations:
  agent:
    enabled: true
  node_exporter:
    enabled: true

  prometheus_remote_write:
   - url: ${WORKSPACE_URL}api/v1/remote_write
     sigv4:
       region: $WORKLOAD_REGION
EOF

sudo ./agent-linux-amd64 -config.file ./agent.yml

この Grafana Cloud Agent の設定では、node_exporter モジュールを有効にしています。現在、AMG で利用可能なメトリクスを確認すると、より多くの情報が利用可能であることがわかります。Grafana Cloud Agent がそれらの情報を送信しています。

図 4: node_netstat_Tcp_InSegs

OpenTelemetry Collectorを使用する

AWS Distro for OpenTelemetry Collector は、アップストリームの OpenTelemetry Collector を AWS がサポートしたバージョンです。Amazon が配布しており、OpenTelemetry コミュニティからいくつかのコンポーネントをサポートしています。Amazon EC2、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service などの AWS のコンピューティングプラットフォームと完全な互換性があります。また、Amazon CloudWatch のメトリクス、トレース、ログやその他のサポートされているバックエンドに計測したデータを送信することができます。

このセクションでは、Prometheus サーバーと Grafana Cloud Agent を使用する代わりに、AWS Distro for OpenTelemetry Collector をデプロイしてメトリクスを収集する方法を紹介します。Grafana Cloud Agent を起動している場合は、Control - C を押してコンソールのセッションを閉じてから、以下のコマンドを実行して AWS Distro for OpenTelemetry Collector をインストールします。

mkdir /tmp/otel
cd /tmp/otel
wget https://aws-otel-collector.s3.amazonaws.com/ubuntu/amd64/latest/aws-otel-collector.deb
sudo dpkg -i -E ./aws-otel-collector.deb

cat > config.yaml << EOF
extensions:
  health_check:
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:55681
  prometheus:
    config:
      scrape_configs:
        - job_name: "otel-collector"
          scrape_interval: 5s
          static_configs:
            - targets: ["localhost:8888"]
processors:
  batch/traces:
    timeout: 1s
    send_batch_size: 50
  batch/metrics:
    timeout: 60s
    
exporters:
  awsprometheusremotewrite:
    endpoint: ${WORKSPACE_URL}api/v1/remote_write
    aws_auth:
      service: "aps"
      region: $WORKLOAD_REGION
          
service:
  pipelines:
    metrics:
      receivers: [otlp,prometheus]
      processors: [batch/metrics]
      exporters: [awsprometheusremotewrite]
  extensions: [health_check]
EOF

export AOT_RUN_USER=root
sudo --preserve-env=AOT_RUN_USER /opt/aws/aws-otel-collector/bin/aws-otel-collector --config /tmp/otel/config.yaml

共有のクレデンシャルファイルを利用するために、Amazon Distro for Open Telemetry (ADOT) Collector をルートユーザーとして実行しています。OTEL Collector のデフォルトユーザー (aot) は、ルートユーザーのホームフォルダにある共有のクレデンシャルファイルにアクセスできません。以下の図のように、AMG で OTEL Collector がメトリクスを送信していることがわかります。

図 5: otelcol_process_runtime_total_alloc_bytes

クリーンアップ

AWS アカウントの不要な課金を避けるために、以下のコマンドを実行して作成したリソースを削除します。また、VM 環境をクリーンアップまたは終了させる必要があります。

rm -f SSMService-Trust.json
aws iam detach-role-policy --role-name SSMServiceRoleRemoteWrite --policy-arn arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess
aws iam detach-role-policy --role-name SSMServiceRoleRemoteWrite --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam delete-role --role-name SSMServiceRoleRemoteWrite
aws amp delete-workspace --workspace-id $WORKSPACE_ID --region $WORKLOAD_REGION

まとめ

本ブログでは、オンプレミスの VM から Prometheus メトリクスを収集し、AMP にリモートでメトリクスを書き込むためのセキュアな環境を構築する方法をご紹介しました。ここでは、SSM エージェントが、Prometheus サーバーに一時的なクレデンシャルを提供し、認証キーを定期的にローテーションするという重要な役割を果たしています。詳細は、SSM エージェントについてをご参照ください。

また、Amazon EKS、Amazon ECS、および EC2 インスタンスから Prometheus メトリクスを簡単に収集できます。詳細については、以下のリソースをご参照ください:

• Getting Started with Amazon Managed Service for Prometheus
• Using Amazon Managed Service for Prometheus to monitor EC2 environments
• Automating the installation and configuration of Prometheus using Systems Manager documents
• Metrics collection from Amazon ECS using Amazon Managed Service for Prometheus
• Hands-on experience using the Observability Workshop

翻訳はソリューションアーキテクトの藤原が担当しました。原文はこちらをご覧ください。