顶有教育Logo顶有教育科技
技术博客
监控告警发布于 2026/6/28更新于 2026/6/28约 16 分钟顶有教育科技

Prometheus 3.x + Grafana 13 + Mimir 3.0：2026 年企业监控体系完整搭建指南

2026 年监控生态迎来多个重要版本：Prometheus 3.12、Grafana 13.1、Grafana Mimir 3.0（横向扩展指标后端）、Grafana Tempo 2.9（AI 辅助链路追踪）。本文从零搭建一套完整的可观测性平台：Prometheus 采集 + Mimir 长期存储 + Grafana 统一展示，覆盖核心配置、告警规则、Recording Rules 性能优化，以及与 OpenTelemetry 的集成方案。

PrometheusGrafanaMimir监控告警可观测性KubernetesOpenTelemetry

2026 年的监控生态已经非常成熟，但“选什么、怎么搭”仍然是团队经常纠结的问题。

本文给出一套面向生产环境的监控体系搭建方案：Prometheus 负责采集，Mimir 3.0 负责长期存储和水平扩展，Grafana 13 负责统一展示，OpenTelemetry Collector 负责数据汇聚。

2026 年版本速览

Prometheus 3.12.0（2026-05-28）
  Remote Write 2.0 正式 GA（更高效的 Mimir 写入协议）
  OTLP 接收端口（原生接收 OpenTelemetry 指标）
  UTF-8 Label 支持（可以用中文标签名，虽然不推荐）
  
Grafana 13.1.0（2026-06-23）
  AI 辅助 Dashboard 生成（描述需求，自动生成 Panel）
  Scene Viz 重构（Dashboard 性能大幅提升）
  原生 OpenTelemetry 数据源（不需要转换）
  
Grafana Mimir 3.0
  架构简化（Ingester/Distributor/Querier 组件精简）
  存储成本优化（更高效的 Parquet 压缩格式）
  Prometheus 和 OTel 双协议原生支持
  
Grafana Tempo 2.9
  AI 辅助的 Trace 异常检测（自动标记异常 Span）
  TraceQL 增强（更强的查询语言）

架构设计

推荐架构（中大规模集群）：

应用 Pod
  │ (metrics endpoint /metrics)
  ▼
Prometheus（采集层）
  │ Remote Write 2.0
  ▼
Grafana Mimir（长期存储，水平扩展）
  │
  ▼
Grafana（展示与告警）
  │
  ├── Prometheus 数据源（查询 Mimir）
  ├── Loki 数据源（日志）
  ├── Tempo 数据源（链路追踪）
  └── Alert Manager（告警通知）

对于小规模集群（< 50 节点，< 1000 Pod）：
  不需要 Mimir，Prometheus 单机存储 30 天足够
  简化版：Prometheus + Grafana + AlertManager

使用 kube-prometheus-stack 快速搭建

# kube-prometheus-stack 包含：
# Prometheus Operator + Prometheus + AlertManager + 
# Grafana + node-exporter + kube-state-metrics

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 创建 values.yaml
cat > monitoring-values.yaml << 'EOF'
grafana:
  enabled: true
  adminPassword: "your-secure-password"
  persistence:
    enabled: true
    size: 10Gi
  service:
    type: ClusterIP      # 通过 Ingress/Gateway 暴露，不直接用 NodePort

prometheus:
  prometheusSpec:
    retention: 15d       # 本地保留 15 天
    retentionSize: 50GB
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi
    resources:
      requests:
        cpu: "500m"
        memory: "2Gi"
      limits:
        cpu: "2"
        memory: "8Gi"
    # 如果接入 Mimir，开启 Remote Write
    remoteWrite:
    - url: http://mimir-distributor.monitoring:8080/api/v1/push
      remoteWriteVersion: "2.0"   # Remote Write 2.0（Prometheus 3.x）

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          resources:
            requests:
              storage: 10Gi

nodeExporter:
  enabled: true

kubeStateMetrics:
  enabled: true
EOF

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --values monitoring-values.yaml \
  --wait

# 查看安装结果
kubectl get pods -n monitoring

Mimir 3.0 部署（长期存储）

适合需要保留 6 个月以上指标数据的场景。

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# Mimir 单体模式（small-scale，开发/测试）
helm install mimir grafana/mimir-distributed \
  --namespace monitoring \
  --set mimir.structuredConfig.common.storage.backend=filesystem \
  --set mimir.structuredConfig.blocks_storage.filesystem.dir=/data/blocks \
  --set mimir.structuredConfig.compactor.data_dir=/data/compactor

# Mimir 生产模式（使用对象存储）
cat > mimir-values.yaml << 'EOF'
mimir:
  structuredConfig:
    common:
      storage:
        backend: s3    # 或 oss（阿里云）、cos（腾讯云）
        s3:
          endpoint: oss-cn-hangzhou.aliyuncs.com    # 阿里云 OSS 示例
          bucket_name: my-mimir-blocks
          access_key_id: <ACCESS_KEY>
          secret_access_key: <SECRET_KEY>
    
    limits:
      ingestion_rate: 100000    # 每秒最多接收 10 万个样本
      max_global_series_per_user: 10000000    # 最多 1000 万个时间序列
      
    compactor:
      data_dir: /data/compactor
EOF

helm install mimir grafana/mimir-distributed \
  --namespace monitoring \
  --values mimir-values.yaml

关键指标采集配置

ServiceMonitor（Prometheus Operator 方式）

# 监控自定义应用（推荐方式）
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
  namespace: monitoring
  labels:
    release: kube-prometheus-stack    # 必须匹配 Prometheus 的 serviceMonitorSelector
spec:
  namespaceSelector:
    matchNames:
    - production
  selector:
    matchLabels:
      app: myapp
      monitor: "true"          # 需要给 Service 打这个 label
  endpoints:
  - port: metrics
    path: /metrics
    interval: 30s
    scrapeTimeout: 10s
    honorLabels: true
# 给 Service 打上对应 Label
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: production
  labels:
    app: myapp
    monitor: "true"          # 与 ServiceMonitor 匹配
spec:
  selector:
    app: myapp
  ports:
  - name: http
    port: 80
  - name: metrics
    port: 9090            # 指标端口

PrometheusRule（告警规则）

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: production-alerts
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
  - name: pod-alerts
    interval: 30s
    rules:
    # Recording Rule（预计算，加速 Dashboard 查询）
    - record: job:container_cpu_usage_seconds_total:rate5m
      expr: |
        sum by (job) (
          rate(container_cpu_usage_seconds_total{container!=""}[5m])
        )
    
    # 告警规则
    - alert: PodCrashLooping
      expr: |
        rate(kube_pod_container_status_restarts_total[15m]) * 60 * 15 > 0
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 正在 CrashLoop"
        description: "容器 {{ $labels.container }} 在过去 15 分钟重启了 {{ $value | humanize }} 次"
    
    - alert: PodOOMKilled
      expr: |
        kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
      for: 0m
      labels:
        severity: critical
      annotations:
        summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 被 OOMKill"
        description: "容器 {{ $labels.container }} 因内存不足被系统终止，请检查 Memory Limit 配置"
    
    - alert: HighMemoryUsage
      expr: |
        (
          container_memory_working_set_bytes{container!=""}
          / container_spec_memory_limit_bytes{container!=""}
        ) > 0.90
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "容器内存使用率超过 90%"
        description: "{{ $labels.namespace }}/{{ $labels.pod }}/{{ $labels.container }} 内存使用率：{{ $value | humanizePercentage }}"
    
  - name: node-alerts
    rules:
    - alert: NodeDiskPressure
      expr: |
        (
          node_filesystem_avail_bytes{mountpoint="/",fstype!="tmpfs"}
          / node_filesystem_size_bytes{mountpoint="/"}
        ) < 0.15
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "节点 {{ $labels.instance }} 磁盘使用率超过 85%"
        description: "剩余可用空间：{{ $value | humanizePercentage }}"
    
    - alert: NodeHighLoad
      expr: node_load15 / count by (instance) (node_cpu_seconds_total{mode="idle"}) > 1.5
      for: 15m
      labels:
        severity: warning
      annotations:
        summary: "节点 {{ $labels.instance }} 15 分钟负载过高"

AlertManager 通知配置

# alertmanager-config.yaml
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: production-config
  namespace: monitoring
spec:
  route:
    receiver: default-receiver
    groupBy: ['alertname', 'namespace']
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 4h
    routes:
    - matchers:
      - name: severity
        value: critical
      receiver: critical-receiver
      repeatInterval: 1h
    - matchers:
      - name: severity
        value: warning
      receiver: warning-receiver
  
  receivers:
  - name: default-receiver
    webhookConfigs:
    - url: 'http://dingtalk-webhook/send'    # 钉钉通知
  
  - name: critical-receiver
    webhookConfigs:
    - url: 'http://dingtalk-webhook/send'
    # 同时发 PagerDuty（如果用的话）
    pagerdutyConfigs:
    - routingKey: '<pagerduty-key>'
  
  - name: warning-receiver
    webhookConfigs:
    - url: 'http://dingtalk-webhook/send'

Grafana 13 + AI 辅助 Dashboard

# 访问 Grafana
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80 &
# 浏览器访问 http://localhost:3000

# Grafana 13 新功能：AI 辅助生成 Panel
# 在 Dashboard 编辑器中，点击 "Generate panel" 按钮
# 输入自然语言描述：
# "显示过去 1 小时内所有命名空间的 Pod CPU 使用率，按命名空间分组"
# Grafana 会自动生成对应的 PromQL 和可视化配置
推荐导入的 Dashboard ID（Grafana 官方）：
  15760 - Kubernetes / Views / Global（集群整体视图）
  13770 - 1 Kubernetes All-in-one Cluster Monitoring（全面）
  3119  - Kubernetes cluster monitoring（经典）
  6417  - Kubernetes Cluster（资源使用）
  
  导入方式：
  Grafana UI → Dashboards → Import → 填入 Dashboard ID

与 OpenTelemetry 集成

Prometheus 3.x 原生支持接收 OTLP 指标，不需要 OTel Collector 中转。

# prometheus.yml 中开启 OTLP 接收
# （在 Prometheus Operator 中通过 additionalScrapeConfigs 配置）
otlp:
  promote_resource_attributes:
  - service.instance.id
  - service.name
  - service.namespace
  - service.version

# 应用直接把 OTel 指标发到 Prometheus
# OTEL_EXPORTER_OTLP_ENDPOINT=http://prometheus:9090/api/v1/otlp/v1/metrics

小结

2026 年的 Prometheus + Grafana 生态已经非常成熟。对于中小规模集群，kube-prometheus-stack 一键安装就能获得完整的监控体系；对于需要长期保留数据或多 Prometheus 实例聚合的场景，Mimir 3.0 提供了经过生产验证的水平扩展能力。

Grafana 13 的 AI 辅助功能让 Dashboard 创建门槛降低了，但理解 PromQL 和指标体系依然是运维工程师的核心能力——AI 生成的 Panel 需要人工验证逻辑是否正确。

根据分类和标签推荐，继续阅读相近主题。

监控告警OpenTelemetry 2026 正式毕业：四大可观测性支柱统一实战指南

2026 年 5 月，CNCF 宣布 OpenTelemetry 正式毕业，成为云原生可观测性的事实标准。OTel 现在统一了四大信号：Traces（链路追踪）、Metrics（指标）、Logs（日志）、Continuous Profiling（持续性能剖析，2026 年进入 RC）。本文讲解 OpenTelemetry 的核心架构、SDK 接入（Python/Go）、Collector 配置与部署、与 Prometheus/Jaeger/Grafana 的集成，以及在 Kubernetes 上的完整可观测性方案落地。

监控告警K8s 可观测性黄金法则：RED/USE 方法与 SLO 实战

系统讲解生产可观测性体系的方法论与实践：RED 方法（Rate/Error/Duration）面向用户服务监控、USE 方法（Utilization/Saturation/Error）面向基础设施资源监控、SLO（服务等级目标）设计与错误预算计算、Prometheus 中的 SLI 指标配置、AlertManager 基于错误预算的告警策略，帮助从"指标收集"升级到"面向 SLO 的可观测性体系"。

监控告警Loki 日志聚合实战：Promtail 采集、LogQL 查询与生产部署

系统讲解 Grafana Loki 日志系统的生产部署：Loki 架构与存储原理（标签索引 vs 全文索引）、Promtail 多场景日志采集配置（Kubernetes/文件/系统日志）、LogQL 查询语言从基础到进阶、Loki 日志告警配置、Loki 分布式部署与存储配置（S3/阿里云 OSS 后端）。