cloud-monitoring

クラウドモニタリング

このスキルにより、エージェントはクラウドインフラストラクチャとアプリケーション向けに、包括的なモニタリングとオブザーバビリティのソリューションを設計、構成できます。エージェントは、オブザーバビリティの3つの柱であるメトリクス、ログ、トレースを理解し、Prometheus、Grafana、CloudWatch、Datadog、OpenTelemetryなどのツールを使って、ダッシュボード、アラートルール、SLI、SLO、SLAを設定できます。また、重大な問題を迅速に検知できるようにしつつ、アラート疲れを最小限に抑えるためのアラート設定のベストプラクティスも適用します。

ワークフロー

1. モニタリングの目的を特定する： エージェントはユーザーと協力して、何を、なぜモニタリングする必要があるかを定義します。これには、重要なサービスの特定、リクエストのレイテンシ、エラー率、スループットなどのサービスレベル指標（SLI）の設定、許容可能なパフォーマンスのしきい値を定義するサービスレベル目標（SLO）の設定が含まれます。サービスレベル契約（SLA）は、顧客に対する契約上のコミットメントとして文書化されます。

2. モニタリングツールとインストルメンテーションを選択する： クラウドプロバイダーとアプリケーションアーキテクチャに基づき、エージェントは適切なモニタリングスタックを推奨します。これには、メトリクス収集用のPrometheus、可視化用のGrafana、ログ集約用のLokiまたはCloudWatch Logs、分散トレーシング用のJaegerまたはAWS X-Rayなどが含まれます。エージェントは、標準化されたテレメトリデータを出力するよう、アプリケーションコードにOpenTelemetry SDKを構成します。

3. メトリクス収集とダッシュボードを構成する： エージェントは、メトリクススクレーパー、エクスポーター、カスタムメトリクスを定義してデプロイします。ゴールデンシグナル（レイテンシ、トラフィック、エラー、飽和度）とインフラストラクチャメトリクス（CPU、メモリ、ディスク、ネットワーク）を可視化するダッシュボードを構築します。チームが問題をすばやくトリアージできるよう、ダッシュボードはサービスタイアごとに整理されます。

4. アラートルールを設定する： エージェントは、メトリクスの生のしきい値だけではなく、エラーバジェットのバーンレートがしきい値を超えた場合、レイテンシの急増が続いた場合、ポッドが再起動した場合など、有意義な条件でトリガーされるアラートを構成します。検知速度と誤検知の抑制のバランスを取るため、複数ウィンドウ、複数バーンレートのアラートを使用します。重要なアラートはPagerDutyまたはOpsgenieに、警告はSlackに送信されるよう、アラートのルーティングを構成します。

5. ログ集約とトレース相関を設定する： エージェントは、構造化ログ形式（JSON）による一元的なログ収集、ログ保持ポリシー、エラーパターンに基づくアラートを構成します。分散トレースは、共有トレースIDを使ってログやメトリクスと関連付けられます。これにより、1つのアラートから関連するリクエストトレースやログエントリに直接リンクできます。

6. レビューして改善する： エージェントは、アラートのノイズレベル、ダッシュボードの利用状況、SLOの遵守状況を定期的に監査します。使われていないアラートを整理し、観測されたベースラインに基づいてしきい値を調整し、システムの進化に合わせて新しいサービスをモニタリングスタックに追加します。

対応テクノロジー

• メトリクス： Prometheus、AWS CloudWatch、Google Cloud Monitoring、Azure Monitor、Datadog、New Relic
• 可視化： Grafana、CloudWatch Dashboards、Datadog Dashboards、Kibana
• ログ： Loki、CloudWatch Logs、Elasticsearch/Fluentd/Kibana（EFK）、Splunk
• トレース： Jaeger、Zipkin、AWS X-Ray、Tempo、Datadog APM
• インストルメンテーション： OpenTelemetry、Prometheusクライアントライブラリ、StatsD
• アラート： Alertmanager、PagerDuty、Opsgenie、Slack Webhooks、SNS

使用方法

クラウドプロバイダー、モニタリング対象のサービス、希望するモニタリングスタック、既存のSLOやアラート要件をエージェントに伝えてください。

プロンプトの例：

Set up monitoring for our Kubernetes microservices on AWS.
- Use Prometheus and Grafana for metrics and dashboards
- Monitor API latency (p99 < 500ms) and error rate (< 1%)
- Send critical alerts to PagerDuty, warnings to Slack
- Aggregate logs with CloudWatch Logs

例

例1：アラートルールを使用したPrometheus + Grafana

prometheus.yml — Prometheusのスクレイプ構成：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alert_rules.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "app"
    metrics_path: /metrics
    static_configs:
      - targets: ["app:8080"]

  - 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_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: $1

alert_rules.yml — SLOベースのアラートルール：

groups:
  - name: slo-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m])) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate exceeds 1% SLO"
          description: "{{ $labels.job }} error rate is {{ $value | humanizePercentage }}"

      - alert: HighP99Latency
        expr: |
          histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
          > 0.5
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "P99 latency exceeds 500ms SLO"

      - alert: PodCrashLooping
        expr: increase(kube_pod_container_status_restarts_total[1h]) > 3
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Pod {{ $labels.pod }} is crash looping"

      - alert: HighMemoryUsage
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.9
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Node memory usage above 90%"

例2：カスタムメトリクスとアラームを使用したAWS CloudWatchダッシュボード

cloudwatch-dashboard.json — モニタリングスタック用のCloudFormationテンプレート：

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
    "ApiDashboard": {
      "Type": "AWS::CloudWatch::Dashboard",
      "Properties": {
        "DashboardName": "api-service-dashboard",
        "DashboardBody": "{\"widgets\":[{\"type\":\"metric\",\"properties\":{\"metrics\":[[\"AWS/ApplicationELB\",\"TargetResponseTime\",\"TargetGroup\",\"my-tg\",{\"stat\":\"p99\"}],[\"AWS/ApplicationELB\",\"HTTPCode_Target_5XX_Count\",\"TargetGroup\",\"my-tg\"]],\"period\":300,\"title\":\"API Latency & Errors\"}},{\"type\":\"metric\",\"properties\":{\"metrics\":[[\"Custom/App\",\"ActiveConnections\"],[\"Custom/App\",\"QueueDepth\"]],\"period\":60,\"title\":\"Application Metrics\"}}]}"
      }
    },
    "HighLatencyAlarm": {
      "Type": "AWS::CloudWatch::Alarm",
      "Properties": {
        "AlarmName": "api-high-latency",
        "MetricName": "TargetResponseTime",
        "Namespace": "AWS/ApplicationELB",
        "Statistic": "p99",
        "Period": 300,
        "EvaluationPeriods": 3,
        "Threshold": 0.5,
        "ComparisonOperator": "GreaterThanThreshold",
        "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:ops-alerts"],
        "Dimensions": [
          {"Name": "TargetGroup", "Value": "my-tg"}
        ]
      }
    },
    "HighErrorRateAlarm": {
      "Type": "AWS::CloudWatch::Alarm",
      "Properties": {
        "AlarmName": "api-high-error-rate",
        "MetricName": "HTTPCode_Target_5XX_Count",
        "Namespace": "AWS/ApplicationELB",
        "Statistic": "Sum",
        "Period": 300,
        "EvaluationPeriods": 2,
        "Threshold": 50,
        "ComparisonOperator": "GreaterThanThreshold",
        "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:ops-alerts"]
      }
    }
  }
}

ベストプラクティス

• 原因ではなく症状に対してアラートを設定する： 低レベルのインフラストラクチャ指標（CPU 使用率 80% など）ではなく、ユーザーに影響する事象（エラー率の高さ、応答の遅さ）に対してアラートを設定します。CPU 使用率が高くても、ユーザーエクスペリエンスが低下しない限り問題ではありません。
• 複数の時間枠でバーンレートを使用する： 単一のしきい値に対してアラートを設定するのではなく、短い（5m）時間枠と長い（1h）時間枠を使用する SLO バーンレートアラートを設定します。これにより、一時的な短い急増を無視しながら、実際のインシデントを迅速に検知できます。
• アラート疲れを最小限に抑える： すべてのアラートに対応可能なアクションがあるべきです。アラートが発生しても、オンコールエンジニアが実行すべき明確なアクションがない場合、そのアラートは削除するか、ダッシュボードウィジェットに変更します。オンコールのシフトごとに、ページ数を 5 件未満にすることを目指します。
• 構造化ログを実装する： すべてのサービスで、一貫したフィールド（timestamp、level、service、trace_id、message）を含む JSON 形式のログを使用します。これにより、効率的なログ検索とトレースとの相関分析が可能になります。
• 保持ポリシーを設定する： 階層型の保持期間を設定します。高解像度のメトリクスは 15 日間、ダウンサンプリングしたメトリクスは 1 年間、ログはコンプライアンス要件に応じて 30～90 日間保持します。これにより、過去の状況を把握できる状態を保ちながら、ストレージコストを管理できます。
• すべてにタグとラベルを付ける： すべてのメトリクス、ログ、トレースに一貫したラベル（service、environment、team、version）を適用し、オブザーバビリティスタック全体でフィルタリング、グループ化、相関分析ができるようにします。

エッジケース

• メトリクスのカーディナリティの爆発的な増加： カーディナリティの高いラベル（ユーザー ID、リクエスト URL など）を持つカスタムメトリクスは、Prometheus に過剰な負荷をかけ、メモリ不足によるクラッシュを引き起こす可能性があります。ラベルの値を有限の集合に制限し、レコーディングルールを使用してカーディナリティの高いクエリを事前に集約します。
• 分散トレースにおけるクロックスキュー： サービスのクロックが同期していないと、トレーススパンの順序が逆に表示されたり、継続時間が負の値になったりすることがあります。すべてのホストで NTP 同期を使用し、トレースの可視化では小さな時間のずれを許容してください。
• 障害発生時のアラートストーム： 単一のインフラストラクチャ障害によって、相関する数十件のアラートが同時に発生することがあります。Alertmanager でアラートのグループ化と抑制ルールを設定し、親アラート（例：「ノード停止」）によって子アラート（例：「そのノード上のポッドが異常」）が抑制されるようにします。
• デプロイ中のメトリクス欠落： ローリングデプロイではポッドが再起動し、時系列データに欠落が生じます。欠落したスクレイプを許容する rate() 関数を使用し、ロールアウト中の誤検知を避けるため、適切な for 期間を設定してメトリクス不在アラートを構成します。
• CloudWatch API のスロットリング： カスタムメトリクスやダッシュボードを過剰にクエリすると、CloudWatch API のレート制限に達することがあります。GetMetricStatistics の代わりに GetMetricData を使ってメトリクス取得をバッチ処理し、クライアント側でダッシュボードデータをキャッシュします。