4、自监控体系设计：监控Prometheus自身、监控Loki、监控Alertmanager、监控Grafana

在可观测性平台中，监控系统本身（Prometheus、Loki、Alertmanager、Grafana）的稳定性直接决定了整个可观测性体系的可靠性。如果监控系统自身发生故障而未被及时发现，将导致所有业务指标的盲区。本章详细阐述如何为这四个核心组件设计一套完整的自监控体系，涵盖指标采集、告警规则、健康检查与自愈策略。

4.1 自监控体系总体架构

自监控体系采用“分层监控、闭环自愈”的设计原则。每一层组件既对外提供服务，也被上层或同层的监控节点所监控。核心架构包含以下四个层次：

• 指标采集层：Prometheus Server 通过内置的 /metrics 端点暴露自身运行指标，同时通过 scrape 配置采集其他组件的指标。
• 日志采集层：Loki 通过 Promtail 或直接暴露的 /metrics 端点提供日志处理状态指标。
• 告警管理层：Alertmanager 暴露告警处理、抑制、静默等内部指标。
• 可视化层：Grafana 暴露面板加载、数据源连接、HTTP 请求等指标。

4.2 监控Prometheus自身

Prometheus Server 暴露了丰富的内部指标，路径为 /metrics。以下表格列出了关键的自监控指标及其含义：

4.2.1 Prometheus 自监控告警规则示例

groups:
  - name: prometheus_self_monitoring
    rules:
      - alert: PrometheusDown
        expr: up{job="prometheus"} == 0
        for: 1m
        annotations:
          summary: "Prometheus 实例 {{ $labels.instance }} 已宕机"

      - alert: PrometheusTSDBHighSeries
        expr: prometheus_tsdb_head_series / 1000000 > 0.8
        for: 5m
        annotations:
          summary: "Prometheus TSDB 活跃序列数超过 80% 容量"

      - alert: PrometheusScrapeFailures
        expr: rate(prometheus_target_scrapes_total{job="prometheus"}[5m]) - rate(prometheus_target_scrapes_exceeded_sample_limit_total{job="prometheus"}[5m]) > 0.1
        for: 5m
        annotations:
          summary: "Prometheus 抓取失败率过高"

4.3 监控Loki

Loki 通过 /metrics 端点暴露其内部状态。关键指标包括日志摄入速率、存储操作延迟、查询性能等。以下表格列出了 Loki 自监控的核心指标：

4.3.1 Loki 自监控告警规则示例

groups:
  - name: loki_self_monitoring
    rules:
      - alert: LokiIngesterHighMemoryStreams
        expr: loki_ingester_memory_streams / 100000 > 0.8
        for: 5m
        annotations:
          summary: "Loki Ingester 内存流数量超过 80% 限制"

      - alert: LokiChunkFlushFailures
        expr: rate(loki_ingester_chunks_flush_failures_total[5m]) > 0
        for: 2m
        annotations:
          summary: "Loki chunk 刷新失败"

      - alert: LokiQueryHighLatency
        expr: histogram_quantile(0.99, rate(loki_logql_query_duration_seconds_bucket[5m])) > 10
        for: 5m
        annotations:
          summary: "Loki LogQL 查询 P99 延迟超过 10s"

4.4 监控Alertmanager

Alertmanager 负责告警的去重、分组、抑制和发送。其自监控指标主要关注告警处理状态、通知发送成功率等。以下表格列出了关键指标：

4.4.1 Alertmanager 自监控告警规则示例

groups:
  - name: alertmanager_self_monitoring
    rules:
      - alert: AlertmanagerNotificationFailures
        expr: rate(alertmanager_notifications_failed_total[5m]) > 0
        for: 2m
        annotations:
          summary: "Alertmanager 通知发送失败"

      - alert: AlertmanagerInvalidAlerts
        expr: rate(alertmanager_alerts_invalid_total[5m]) > 0
        for: 5m
        annotations:
          summary: "Alertmanager 收到无效告警"

      - alert: AlertmanagerDown
        expr: up{job="alertmanager"} == 0
        for: 1m
        annotations:
          summary: "Alertmanager 实例 {{ $labels.instance }} 已宕机"

4.5 监控Grafana

Grafana 通过 /metrics 端点暴露其内部指标，包括 HTTP 请求、面板加载、数据源连接、用户会话等。以下表格列出了 Grafana 自监控的核心指标：

4.5.1 Grafana 自监控告警规则示例

groups:
  - name: grafana_self_monitoring
    rules:
      - alert: GrafanaHighRequestLatency
        expr: histogram_quantile(0.99, rate(grafana_http_request_duration_seconds_bucket[5m])) > 5
        for: 5m
        annotations:
          summary: "Grafana HTTP 请求 P99 延迟超过 5s"

      - alert: GrafanaAlertRuleEvaluationFailures
        expr: rate(grafana_alerting_rule_evaluation_failures_total[5m]) > 0
        for: 2m
        annotations:
          summary: "Grafana 告警规则评估失败"

      - alert: GrafanaDown
        expr: up{job="grafana"} == 0
        for: 1m
        annotations:
          summary: "Grafana 实例 {{ $labels.instance }} 已宕机"

4.6 自愈策略设计

自监控体系不仅需要发现故障，还应具备自动恢复能力。以下表格总结了针对不同组件的常见自愈策略：

4.7 自监控体系部署建议

为了确保自监控体系的高可用性，建议遵循以下部署原则：

• 独立 Prometheus 实例：部署一个独立的 Prometheus 实例专门用于采集自监控指标，避免与业务监控实例共享资源。
• 联邦集群：如果业务 Prometheus 实例较多，可以使用联邦集群（Federation）将自监控指标汇总到中央 Prometheus。
• 多副本部署：Alertmanager 和 Grafana 应部署多副本，并使用负载均衡器分发流量。
• 持久化存储：自监控数据应保留至少 30 天，用于故障复盘和容量规划。
• 告警通知冗余：自监控的告警通知应使用与业务告警不同的通道（如独立的 Slack 频道或邮件列表），避免通道故障导致自监控告警丢失。