目次

Amazon Managed Service for Prometheus 完全ガイド v2.0

フルマネージドのPrometheus互換メトリクスサービスとKubernetes監視基盤

Amazon Managed Service for Prometheus(AMP) は、Kubernetes(EKS / ECS)・EC2 から Prometheus Remote Write プロトコルで送信されたメトリクスを収集・保存・PromQL クエリで分析する フルマネージドメトリクスサービスです。Prometheus のスケーリング・HA 構成・ストレージ管理・バックアップを AWS が完全に管理。セルフホスト Prometheus の 設定・運用負荷を 95% 削減します。Managed Grafana と統合し、EKS メトリクスの一元ダッシュボード・アラーム管理を実現。本ドキュメントは AMP の本質・メトリクス収集・運用パターン・2026 年最新動向を体系的に解説します。

ドキュメントの目的

本ガイドは以下を対象としています。

  • 初心者向け: AMP とは何か、なぜ Kubernetes メトリクスに必須かを学びたい方
  • DevOps / SRE 向け: EKS からのメトリクス収集・長期保存を実装したい方
  • Kubernetes 管理者向け: Prometheus 運用・スケーリングの負荷を削減したい方
  • 意思決定者向け: セルフホスト Prometheus・Grafana Mimir・VictoriaMetrics・Cortex・Thanos との比較検討

2025-2026年の最新動向

  • ADOT Collector 強化(2026年3月):Go・Rust ランタイムメトリクスの自動計装
  • Cross-Account / Cross-Region 集約(2026年2月):複数 AMP workspace への自動シャーディング・集約
  • Recording Rules UI 改善(2026年4月):Grafana 11 統合で Rules のビジュアルエディタ対応
  • SageMaker Metrics 統合(2026年4月):ML Training Job メトリクスを AMP に自動送信

目次

  1. 概要
  2. AMP が解決する課題
  3. 主な特徴
  4. アーキテクチャ
  5. コアコンポーネント
  6. メトリクス収集方式
  7. 主要ユースケース
  8. 設定・操作の具体例
  9. 類似サービス比較
  10. ベストプラクティス
  11. トラブルシューティング
  12. 2025-2026最新動向
  13. 学習リソース
  14. 導入ロードマップ
  15. 実装チェックリスト
  16. まとめ
  17. 参考文献

概要

初心者向けメモ: Amazon Managed Service for Prometheus は「Kubernetes クラスターのメトリクスを自動収集・保存する AWS サービス」です。従来は EKS クラスター内に Prometheus サーバーをデプロイ・管理する必要がありましたが、AMP では「ADOT Collector を EKS に導入 → Prometheus Remote Write で AMP に送信 → Managed Grafana で可視化」で完成。Prometheus インスタンスの管理・ディスク容量確保・バージョンアップグレードは AWS が担当します。

Amazon Managed Service for Prometheus は、Prometheus Remote Write プロトコルで受け取ったメトリクスを AWS が管理するインフラストラクチャに集約・長期保存するサービスです。セルフホスト Prometheus(HA 構成では Thanos・Cortex が必要)の代替として機能。PromQL で 150 日間保存されたメトリクスをクエリ可能。Alert Manager・Recording Rules も統合。EKS・EC2・Lambda など複数ワークロードからのメトリクスを一元管理できます。

AMP の位置づけ

Kubernetes 監視・メトリクス基盤の役割:

  • Prometheus HA 管理の廃止:Thanos・Cortex 等の複雑な構成をマネージドで実現
  • ストレージ管理ゼロ化:150 日自動保存・自動スケーリング。容量計画不要
  • 運用負荷削減:バージョンアップ・パッチ・スケーリングは AWS が自動管理
  • Managed Grafana との統合:EKS メトリクスの一元ダッシュボード・SLO 管理を実現

AMP が解決する課題

AMP は、Kubernetes メトリクス基盤における次の問いに答えるための基盤です。

課題 AMP のソリューション
EKS 内の Prometheus 管理が負担(ストレージ・HA・バージョンアップ) AMP にメトリクス送信 → AWS が管理。Prometheus インスタンス不要
Prometheus ディスク枯渇で障害多発 AMP は自動スケーリング。ディスク管理完全廃止
複数クラスター のメトリクス管理が複雑 AMP の複数 workspace で環境分離。クロスアカウント送信で一元集約可能
PromQL クエリ・Recording Rules・Alert Manager 管理が複雑 AMP がネイティブサポート。既存 Prometheus スクリプトそのまま移行可能
Prometheus アップグレード時のダウンタイム・互換性テスト AMP は自動アップグレード・無停止。テスト工数ゼロ
Prometheus HA 構成(Thanos・Cortex)導入の複雑さ AMP は自動 HA・マルチ AZ・バックアップ構成
セルフホスト Prometheus スケーリング限界 AMP は無制限スケーリング。メトリクス数・クエリ頻度に制約なし
EKS + EC2 + Lambda メトリクスの統一管理 AMP Single workspace で複数ワークロードを統一。環境分離も可能

主な特徴

特徴 説明
Prometheus Remote Write 互換 既存 Prometheus エクスポーター・設定そのまま移行。互換性 100%
PromQL クエリ対応 Grafana・Alert Manager・API から PromQL ネイティブクエリ実行
150 日自動保存 メトリクス自動 tier(hot → warm → cold)。保持期間延長可能
Alert Manager ネイティブサポート Alert Manager 設定ファイルを YAML でアップロード。Slack・PagerDuty 通知統合
Recording Rules メトリクス事前計算で PromQL クエリ高速化。CPU intensive な Query offload
マルチアカウント / クロスアカウント 複数 AWS アカウントから同一 workspace に送信・集約可能
ADOT / Prometheus Collector サポート ECS Anywhere・Lambda も対応。Agent 選択肢豊富
CloudWatch メトリクス統合 CloudWatch メトリクス → Prometheus 形式で可視化。AWS リソース監視も統一
Managed Grafana との統合 Grafana データソース自動設定。IAM ロール で認証・ダッシュボード構築
DevOps Guru・AWS Platform での活用 AMP メトリクスを Guru・Application Signals が自動解析
クロスリージョン集約(準備中) 2026 年:複数リージョン workspace を自動集約・検索

アーキテクチャ

【図1】AMP データ流:

graph TD
    EKS["Amazon EKS Cluster<br/>(Kubernetes)"]
    ADOT["ADOT Collector<br/>(OpenTelemetry)"]
    PrometheusClient["Prometheus Exporter<br/>(アプリケーション)"]
    
    EKS -->|Deploy| ADOT
    PrometheusClient -->|Expose Metrics<br/>/metrics endpoint| ADOT
    
    ADOT -->|Prometheus Remote Write| AMP["Amazon Managed Service<br/>for Prometheus<br/>(Workspace)"]
    
    AMP -->|Ingest| Storage["Metrics Storage<br/>(150 日)"]
    AMP -->|Evaluate| AlertManager["Alert Manager<br/>(Rule Evaluation)"]
    AMP -->|Serve PromQL| QueryAPI["Query API<br/>(/api/v1/query)"]
    
    QueryAPI -->|Query| Grafana["Managed Grafana<br/>(Visualization)"]
    AlertManager -->|Notify| Slack["Slack / PagerDuty<br/>(Notification)"]
    
    style EKS fill:#e1f5ff
    style ADOT fill:#c8e6c9
    style PrometheusClient fill:#c8e6c9
    style AMP fill:#fff3e0
    style Storage fill:#e8f5e9
    style AlertManager fill:#fce4ec
    style QueryAPI fill:#f8bbd0
    style Grafana fill:#ffe0b2
    style Slack fill:#fff9c4

【図2】AMP vs セルフホスト Prometheus:

graph LR
    subgraph SelfHosted["セルフホスト Prometheus"]
        Prom["Prometheus<br/>(EKS StatefulSet)"]
        Thanos["Thanos<br/>(HA / 長期保存)"]
        Cortex["Cortex<br/>(マルチテナント)"]
        Prom -->|Push| Thanos
        Thanos -->|Sidecar| Cortex
        Storage1["S3<br/>(Object Storage)"]
        Cortex -->|Persist| Storage1
    end
    
    subgraph ManagedAMP["Amazon Managed Service for Prometheus"]
        AMP["Workspace<br/>(AWS 管理)"]
        Storage2["AWS Managed Storage<br/>(自動スケール)"]
        AMP -->|Ingest| Storage2
    end
    
    style SelfHosted fill:#ffebee
    style ManagedAMP fill:#e8f5e9
    style Prom fill:#ffccbc
    style Thanos fill:#ffccbc
    style Cortex fill:#ffccbc
    style Storage1 fill:#ffccbc
    style AMP fill:#a5d6a7
    style Storage2 fill:#a5d6a7

コアコンポーネント

1. Workspace(ワークスペース)

AMP の基本単位。メトリクス収集・保存・クエリを提供する論理的単位。

Workspace の構成:

Workspace: prod-metrics
├─ ID: ws-abc123def456
├─ Endpoint:
│  ├─ Ingestion: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/api/v1/remote_write
│  └─ Query: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/api/v1/query
├─ Region: ap-northeast-1
├─ Retention: 150 days
├─ Metrics Count: 450M series
├─ Ingestion Rate: 2.3M samples/min
└─ Status: Active

2. Recording Rules(記録ルール)

メトリクス事前計算。PromQL クエリを高速化。

# recording-rules.yaml
groups:
  - name: Kubernetes Recording Rules
    interval: 30s
    rules:
      # 事前計算:Pod CPU 使用率(5分平均)
      - record: pod:cpu_usage:5m
        expr: rate(container_cpu_usage_seconds_total[5m])
      
      # 事前計算:Node メモリ使用率
      - record: node:memory_usage:percent
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
      
      # 事前計算:リクエストレート
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

3. Alert Manager Rules(アラートルール)

AMP の Alert Manager が評価するルール。Slack・PagerDuty に通知。

# alert-rules.yaml
groups:
  - name: Kubernetes Alerts
    interval: 30s
    rules:
      # Alert: Node CPU high
      - alert: HighNodeCPU
        expr: node_cpu_percent > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU on node {{ $labels.node }}"
          description: "Node CPU at {{ $value }}%"
      
      # Alert: Pod restart storm
      - alert: PodRestartStorm
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0.1
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Pod {{ $labels.pod }} restarting frequently"

4. Query API(クエリ API)

Grafana・アプリケーションが PromQL でメトリクスをクエリ。

# PromQL クエリ実行(SigV4 署名認証)
curl -X GET \
  "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/api/v1/query" \
  -H "Authorization: $(aws amp generate-grafana-api-key ...)" \
  --data-urlencode 'query=rate(http_requests_total[5m])'

# 応答例
{
  "status": "success",
  "data": {
    "resultType": "vector",
    "result": [
      {
        "metric": {"job": "api-service"},
        "value": [1682000000, "1234.5"]
      }
    ]
  }
}

メトリクス収集方式

ADOT Collector(推奨)

OpenTelemetry 標準で Prometheus メトリクスを収集・送信。

# ADOT Collector ConfigMap(EKS)
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: adot-collector
spec:
  mode: deployment
  config: |
    receivers:
      prometheus:
        config:
          scrape_configs:
            - job_name: 'kubernetes-pods'
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
                  action: keep
                  regex: true
                - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
                  action: replace
                  target_label: __metrics_path__
                  regex: (.+)
                - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
                  action: replace
                  regex: ([^:]+)(?::\d+)?;(\d+)
                  replacement: $1:$2
                  target_label: __address__
    
    exporters:
      prometheusremotewrite:
        endpoint: "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/api/v1/remote_write"
        auth:
          authenticator: sigv4auth
    
    extensions:
      sigv4auth:
        region: ap-northeast-1
        service: aps
    
    service:
      extensions: [sigv4auth]
      pipelines:
        metrics:
          receivers: [prometheus]
          exporters: [prometheusremotewrite]

Prometheus Server(Direct Push)

既存 Prometheus サーバーから AMP へ Prometheus Remote Write で送信。

# prometheus.yml(Remote Write 設定)
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'kubernetes'
    kubernetes_sd_configs:
      - role: node
    relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)

# Remote Write to AMP
remote_write:
  - url: "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/api/v1/remote_write"
    sigv4:
      region: ap-northeast-1
      service: aps

CloudWatch Agent(オプション)

CloudWatch メトリクス → Prometheus 形式で AMP に送信。

{
  "metrics": {
    "namespace": "AWS/EC2",
    "metrics_collected": {
      "cpu": {
        "measurement": [
          {
            "name": "cpu_usage_idle",
            "rename": "ec2_cpu_usage_idle",
            "unit": "Percent"
          }
        ],
        "totalcpu": false
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/app/*.log",
            "log_group_name": "/aws/app/logs",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

主要ユースケース

1. EKS クラスター全体の Kubernetes メトリクス監視

背景: EKS ノード・Pod・コンテナの CPU・メモリ・ネットワークを一元監視。

構成:

  • Collector: ADOT Collector(Kubernetes prometheus receiver)
  • Metrics: kube-state-metrics・kubelet cAdvisor メトリクス
  • 保存期間: 150 日(自動保持)
  • ダッシュボード: Managed Grafana で Kubernetes クラスター全体を可視化

実装:

# ADOT Collector デプロイ
kubectl apply -f adot-collector.yaml

# Prometheus メトリクス確認
kubectl port-forward -n otel-system ds/adot-collector 9090:9090

# PromQL クエリでメトリクス確認
curl 'http://localhost:9090/api/v1/query?query=up'

2. マイクロサービスのカスタムメトリクス・監視

背景: 複数マイクロサービスから Prometheus クライアントライブラリでメトリクス送信。AMP で統一管理。

メトリクス例:

from prometheus_client import Counter, Histogram, start_http_server
import time

# リクエスト数カウンター
request_count = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'endpoint', 'status']
)

# レスポンスタイム ヒストグラム
response_time = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration',
    ['method', 'endpoint'],
    buckets=(0.1, 0.5, 1.0, 5.0)
)

@app.route('/api/data')
def get_data():
    start_time = time.time()
    # 処理
    duration = time.time() - start_time
    
    request_count.labels(
        method='GET',
        endpoint='/api/data',
        status=200
    ).inc()
    
    response_time.labels(
        method='GET',
        endpoint='/api/data'
    ).observe(duration)
    
    return {'data': []}

# Prometheus endpoint expose
start_http_server(8000)  # /metrics endpoint on port 8000

AMP での PromQL 分析:

# リクエストレート(1分間)
rate(http_requests_total[1m])

# P99 レスポンスタイム
histogram_quantile(0.99, http_request_duration_seconds)

# エラーレート
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])

3. マルチクラスター 環境での メトリクス集約

背景: dev / staging / prod の 複数 EKS クラスターのメトリクスを一元管理。

構成:

  • Single Workspaceで複数クラスター をメトリクス送信
  • Cluster Labelで クラスター別に区別

PromQL 例:

# 全クラスターのノード CPU
sum by (cluster) (rate(node_cpu_seconds_total[5m]))

# 本番クラスターのみ
sum by (namespace) (rate(http_requests_total{cluster="prod"}[5m]))

4. SLO(Service Level Objective)の定義・測定

背載: API の SLO(99.9% 可用性・P99 < 100ms)を AMP で測定・追跡。

Recording Rules:

# SLO 計算用 Recording Rules
groups:
  - name: api-slo
    interval: 30s
    rules:
      # エラーバジェット:有効リクエスト数(成功)
      - record: api:slo:success:5m
        expr: sum(rate(http_requests_total{status=~"2.."}[5m]))
      
      # エラーバジェット:全リクエスト数
      - record: api:slo:total:5m
        expr: sum(rate(http_requests_total[5m]))
      
      # SLO 達成率(99.9% = 0.999)
      - record: api:slo:ratio:5m
        expr: api:slo:success:5m / api:slo:total:5m

Grafana でのアラート:

  • Alert: SLO Breach Imminent
  • Condition: api:slo:ratio:5m < 0.999
  • Severity: High
  • Action: エラーバジェット消費速度がSLO達成を脅かす → 施策実行

5. コスト最適化:Recording Rules で Query オフロード

背景: 大量の PromQL クエリで CPU 負荷 → Recording Rules で事前計算。

Before(Query で 毎回計算):

# CPU intensive:毎回 rate() 計算
sum by (job) (rate(http_requests_total[5m]))

After(Recording Rule で 事前計算):

# 30秒ごとに自動計算・保存
- record: job:http_requests:rate5m
  expr: sum by (job) (rate(http_requests_total[5m]))

# ダッシュボード Query では簡単に参照
job:http_requests:rate5m  # 事前計算済み → 瞬時に応答

効果:

  • Query 応答時間:5 秒 → 100ms(50倍高速化)
  • CPU 削減:記録ルール計算に集約

設定・操作の具体例

AWS CLI での Workspace 作成

# Workspace 作成
aws amp create-workspace \
  --region ap-northeast-1 \
  --alias prod-metrics \
  --tags "Environment=Production" "Team=Platform"

# → 出力:
# {
#   "workspace": {
#     "workspaceId": "ws-abc123def456",
#     "alias": "prod-metrics",
#     "prometheusEndpoint": "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-abc123def456/"
#   }
# }

# Workspace 一覧
aws amp list-workspaces --region ap-northeast-1

# Recording Rules アップロード
aws amp put-rule-groups-namespace \
  --workspace-id ws-abc123def456 \
  --name prod-rules \
  --data fileb://recording-rules.yaml

# Alert Manager 設定アップロード
aws amp put-alert-manager-definition \
  --workspace-id ws-abc123def456 \
  --data fileb://alertmanager.yaml

CloudFormation での構築

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Amazon Managed Service for Prometheus'

Resources:
  # AMP Workspace
  PrometheusWorkspace:
    Type: AWS::APS::Workspace
    Properties:
      Alias: prod-metrics
      Description: Production Prometheus Metrics
      Tags:
        - Key: Environment
          Value: Production
        - Key: Team
          Value: Platform

  # IRSA Role for ADOT Collector
  ADOTCollectorRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Federated: !Sub 'arn:aws:iam::${AWS::AccountId}:oidc-provider/oidc.eks.${AWS::Region}.amazonaws.com/id/XXXXXXXXXXXXXXXX'
            Action: 'sts:AssumeRoleWithWebIdentity'
            Condition:
              StringEquals:
                'oidc.eks.ap-northeast-1.amazonaws.com/id/XXXXXXXXXXXXXXXX:aud': 'sts.amazonaws.com'
                'oidc.eks.ap-northeast-1.amazonaws.com/id/XXXXXXXXXXXXXXXX:sub': 'system:serviceaccount:otel-system:adot-collector'

  ADOTCollectorPolicy:
    Type: AWS::IAM::RolePolicy
    Properties:
      RoleName: !Ref ADOTCollectorRole
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - 'aps:RemoteWrite'
              - 'aps:GetMetricStatistics'
            Resource: !GetAtt PrometheusWorkspace.Arn

Outputs:
  WorkspaceId:
    Value: !Ref PrometheusWorkspace
    Description: AMP Workspace ID

  PrometheusEndpoint:
    Value: !GetAtt PrometheusWorkspace.PrometheusEndpoint
    Description: Prometheus Endpoint URL

Terraform での構築

resource "aws_prometheus_workspace" "main" {
  alias = "prod-metrics"

  tags = {
    Environment = "Production"
    Team        = "Platform"
  }
}

# Recording Rules
resource "aws_prometheus_rule_group_namespace" "recording" {
  workspace_id   = aws_prometheus_workspace.main.id
  name           = "prod-rules"
  data           = file("${path.module}/recording-rules.yaml")
}

# Alert Manager Definition
resource "aws_prometheus_alert_manager_definition" "main" {
  workspace_id = aws_prometheus_workspace.main.id
  definition   = file("${path.module}/alertmanager.yaml")
}

# IRSA Role
resource "aws_iam_role" "adot_collector" {
  name = "adot-collector-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.REGION.amazonaws.com/id/XXXXXXXX"
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "oidc.eks.REGION.amazonaws.com/id/XXXXXXXX:sub" = "system:serviceaccount:otel-system:adot-collector"
          }
        }
      }
    ]
  })
}

resource "aws_iam_role_policy" "adot_collector" {
  name = "adot-collector-policy"
  role = aws_iam_role.adot_collector.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "aps:RemoteWrite",
          "aps:GetMetricStatistics"
        ]
        Resource = aws_prometheus_workspace.main.arn
      }
    ]
  })
}

類似サービス比較

特性 AMP Grafana Mimir VictoriaMetrics Cortex Thanos
Prometheus 互換 ✅ Remote Write ✅ 完全互換 ✅ PromQL 互換 ✅ 互換 ✅ sidecar
自動スケーリング ✅ 自動 △ 手動 △ 手動 △ 手動 △ 手動
HA 構成 ✅ 自動 △ 手動 △ 手動 △ 手動 ✅ 自動
AWS 統合 ✅ 深い △ 無し △ 無し △ 無し △ 無し
マネージド ✅ AWS 管理 △ セルフホスト ✗ セルフホスト ✗ セルフホスト ✗ セルフホスト
コスト(小規模) ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ ⭐⭐ ⭐⭐
運用負荷(大規模) ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐
推奨用途 AWS Primary 大規模 大規模 大規模 長期保存

ベストプラクティス

✅ 推奨される実装パターン

1. ADOT Collector での Prometheus メトリクス収集

# EKS での ADOT Collector デプロイ
apiVersion: v1
kind: ConfigMap
metadata:
  name: adot-collector-config
  namespace: otel-system
data:
  config.yaml: |
    receivers:
      prometheus:
        config:
          scrape_configs:
            - job_name: 'kubernetes-pods'
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
                  action: keep
                  regex: true
    
    exporters:
      prometheusremotewrite:
        endpoint: "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/api/v1/remote_write"
        auth:
          authenticator: sigv4auth
    
    extensions:
      sigv4auth:
        region: ap-northeast-1
        service: aps
    
    service:
      extensions: [sigv4auth]
      pipelines:
        metrics:
          receivers: [prometheus]
          exporters: [prometheusremotewrite]

2. Recording Rules で Query 最適化

# メトリクス事前計算で PromQL クエリ高速化
groups:
  - name: optimization
    interval: 30s
    rules:
      # CPU intensive Query を 事前計算
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))
      
      # ダッシュボードでは record 参照
      # query: job:http_requests:rate5m  ← 瞬時に応答

3. Grafana 統合で Dashboard 構築

# Grafana Data Source(AMP)
POST /api/datasources
{
  "name": "Prometheus (AMP)",
  "type": "prometheus",
  "url": "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxx/",
  "access": "proxy",
  "jsonData": {
    "sigv4Auth": true,
    "sigv4Region": "ap-northeast-1"
  }
}

# Grafana Dashboard で PromQL Query
{
  "targets": [
    {
      "expr": "rate(http_requests_total[5m])",
      "legendFormat": "{{job}}"
    }
  ]
}

トラブルシューティング

問題 原因 解決方法
メトリクス受信エラー(403) IAM 権限不足 / SigV4 署名エラー IRSA ロール確認、リージョン設定確認
PromQL Query エラー(404) Workspace ID 不正 / メトリクス未送信 Workspace ID 確認、ADOT Collector ログ確認
メトリクス データ不足 Collector スクレイプ設定ミス prometheus.yaml relabel_configs 確認

まとめ

Amazon Managed Service for Prometheus は、Kubernetes(EKS / ECS)・EC2 から Prometheus Remote Write で送信されたメトリクスを AWS が完全マネージドで集約・保存・分析する フルマネージドメトリクスサービス です。Prometheus のスケーリング・HA 構成・ストレージ管理・バージョンアップグレード負荷を 95% 削減。150 日自動保存・PromQL ネイティブ対応・Alert Manager・Recording Rules でエンタープライズ級メトリクス基盤を実現。Managed Grafana と統合し、EKS クラスター全体の統一ダッシュボード・SLO 管理・アラート自動化を完成させます。


最終更新:2026-04-27 バージョン:v2.0