cloud-monitoring

云监控

此技能使 Agent 能够为云基础设施和应用设计并配置全面的监控与可观测性解决方案。Agent 了解可观测性的三大支柱——指标、日志和追踪，并能使用 Prometheus、Grafana、CloudWatch、Datadog 和 OpenTelemetry 等工具设置仪表板、告警规则、SLI、SLO 和 SLA。Agent 还会应用告警最佳实践，尽量减少告警疲劳，同时确保及时发现关键问题。

工作流

1. 确定监控目标： Agent 与用户协作，明确需要监控的内容及原因。这包括识别关键服务、建立服务级别指标（SLI），例如请求延迟、错误率和吞吐量，以及设定服务级别目标（SLO），以定义可接受的性能阈值。服务级别协议（SLA）则作为对客户的合同承诺进行记录。

2. 选择监控工具和埋点方案： Agent 根据云服务提供商和应用架构，推荐合适的监控技术栈。这可能包括使用 Prometheus 收集指标、使用 Grafana 进行可视化、使用 Loki 或 CloudWatch Logs 聚合日志，以及使用 Jaeger 或 AWS X-Ray 进行分布式追踪。Agent 会在应用代码中配置 OpenTelemetry SDK，以输出标准化遥测数据。

3. 配置指标采集和仪表板： Agent 定义并部署指标抓取器、导出器和自定义指标。它会构建仪表板，以展示黄金信号（延迟、流量、错误、饱和度）和基础设施指标（CPU、内存、磁盘、网络）。仪表板按服务层级组织，方便团队快速排查问题。

4. 制定告警规则： Agent 配置基于有意义的条件触发的告警，例如错误预算消耗速率超过阈值、延迟持续飙升或 Pod 重启，而不是仅依赖原始指标阈值。采用多窗口、多消耗速率告警，在检测速度与抑制误报之间取得平衡。告警路由配置为将关键告警发送至 PagerDuty 或 Opsgenie，将警告发送至 Slack。

5. 设置日志聚合和追踪关联： Agent 配置集中式日志收集，采用结构化日志格式（JSON）、日志保留策略，并针对错误模式设置基于日志的告警。通过共享追踪 ID 将分布式追踪与日志和指标关联起来，使单个告警能够直接关联到相关请求追踪和日志条目。

6. 检查并迭代： Agent 定期审核告警噪声水平、仪表板使用情况和 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

用法

向 Agent 提供你的云服务提供商、需要监控的服务、首选监控技术栈，以及任何现有的 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 使用率过高导致用户体验下降时，它才是问题。
• 使用多时间窗口的消耗速率： 不要只根据单一阈值触发告警，而应使用 SLO 消耗速率告警，并设置快速（5m）和慢速（1h）时间窗口。这样既能快速检测到真实事件，又能忽略短暂的突发峰值。
• 尽量减少告警疲劳： 每条告警都应可采取行动。如果告警触发后，值班工程师没有明确的应对措施，就应移除该告警，或将其改为仪表板组件。每个值班班次收到的告警页数应少于 5 条。
• 实施结构化日志记录： 在所有服务中使用 JSON 格式的日志，并统一字段（timestamp、level、service、trace_id、message）。这样便于高效查询日志，并与追踪数据进行关联。
• 设置保留策略： 配置分级保留策略——高分辨率指标保留 15 天，降采样后的指标保留 1 年，日志根据合规要求保留 30–90 天。这样既能控制存储成本，又能保留历史数据以供查看。
• 为所有数据添加标签： 为所有指标、日志和追踪数据添加统一标签（service、environment、team、version），以便在整个可观测性技术栈中进行筛选、分组和关联。

边缘情况

• 指标基数爆炸： 带有高基数标签（例如用户 ID、请求 URL）的自定义指标可能会压垮 Prometheus，导致内存溢出崩溃。请将标签值限制在有界集合内，并使用记录规则预先聚合高基数查询。
• 分布式追踪中的时钟偏差： 如果服务的时钟不同步，追踪 span 可能会显示顺序错误或持续时间为负。确保所有主机都使用 NTP 同步，并在追踪可视化中容忍轻微的时间偏差。
• 故障期间的告警风暴： 单次基础设施故障可能同时触发数十条相关告警。在 Alertmanager 中配置告警分组和抑制规则，让父级告警（例如“节点宕机”）抑制子级告警（例如“该节点上的 pod 不健康”）。
• 部署期间缺少指标： 滚动部署会导致 pod 重启，从而使时间序列数据出现间断。请使用能够容忍抓取数据缺失的 rate() 函数，并为缺失指标告警设置适当的 for 时长，以避免在滚动发布期间产生误报。
• CloudWatch API 限流： 查询过多自定义指标或仪表板可能会触发 CloudWatch API 速率限制。请使用 GetMetricData 而不是 GetMetricStatistics 批量获取指标，并在客户端缓存仪表板数据。