2. Prometheus 生态概览：核心组件关系与数据流
在构建日志检索、准入门禁、自监控与告警自愈体系之前，必须先理解 Prometheus 生态中各组件的角色与协作方式。本章从组件职责、数据流向、部署拓扑三个维度，梳理 Prometheus、Loki、Alertmanager、Grafana 之间的核心关系。
2.1 组件职责矩阵
下表列出四个核心组件在可观测性体系中的定位、数据来源与输出目标：
| 组件 | 核心职责 | 数据来源 | 输出目标 | 数据形态 |
|---|---|---|---|---|
| Prometheus | 指标采集、存储、告警规则评估 | Exporter、Pushgateway、服务自身 | Alertmanager、Grafana、Remote Storage | 时序指标（Metric + Label） |
| Loki | 日志聚合、索引、查询 | Promtail、Fluent Bit、Docker 日志驱动 | Grafana（LogQL 查询） | 日志行 + Label 索引 |
| Alertmanager | 告警去重、分组、静默、路由、通知 | Prometheus（Alerting Rules） | 邮件、Slack、PagerDuty、Webhook | 告警事件（Alert JSON） |
| Grafana | 统一可视化、仪表盘、告警管理 | Prometheus、Loki、Elasticsearch 等 | 用户浏览器、告警通知 | 图表、表格、日志面板 |
关键认知： Prometheus 负责“数字型”指标，Loki 负责“文本型”日志，Alertmanager 负责“事件型”告警，Grafana 负责“展示型”界面。四者互补，构成完整的可观测性三角。
2.2 数据流全景图
下图展示从数据采集到告警通知、从指标查询到日志关联的完整数据流。箭头方向代表数据推送或拉取的方向。
2.3 组件间数据流详解
根据上图，数据流可拆解为三条主线：
2.3.1 指标采集与告警链路
- Prometheus Server 通过
scrape_config配置，定期从 Exporter 或应用自身暴露的/metrics端点拉取指标。 - Prometheus 将指标存储在本地 TSDB 中，并持续评估 Recording Rules 和 Alerting Rules。
- 当告警规则触发，Prometheus 将告警事件推送到 Alertmanager。
- Alertmanager 执行去重、分组、静默、抑制后，通过配置的 Receiver（邮件、Slack、PagerDuty、Webhook）发送通知。
2.3.2 日志采集与查询链路
- Promtail（或其他日志采集器）从日志文件、stdout、journald 等来源读取日志行。
- Promtail 为日志行附加 Label（如
job、instance、container），通过 HTTP 推送到 Loki。 - Loki 对日志内容进行压缩存储，仅对 Label 建立索引，不对日志全文建索引（区别于 Elasticsearch）。
- 用户通过 Grafana 使用 LogQL 查询日志，Grafana 将查询请求转发给 Loki 的 HTTP API。
2.3.3 统一可视化链路
- Grafana 配置多个数据源：Prometheus（指标）、Loki（日志）、以及可能的 Jaeger（链路）。
- 在同一个 Dashboard 中，用户可以将指标趋势图与日志面板并排展示，实现 指标→日志→链路 的关联分析。
- Grafana 也支持基于 Prometheus 指标的告警规则配置，但生产环境通常将告警规则放在 Prometheus 侧，Grafana 仅做可视化。
实践要点： 在准入门禁场景中，Prometheus 负责采集准入请求的 QPS、延迟、错误率；Loki 负责存储准入日志（如拒绝原因、用户身份）；Alertmanager 负责在错误率突增时发送告警；Grafana 提供统一的“准入控制面板”，同时展示指标曲线和日志详情。
2.4 部署拓扑模式
根据规模与职责分离需求，常见三种部署模式：
| 模式 | 适用场景 | 组件部署方式 | 优缺点 |
|---|---|---|---|
| 单机 All-in-One | 开发测试、小规模 | Prometheus + Loki + Alertmanager + Grafana 同主机 | 部署简单，但单点故障，扩展性差 |
| 分层部署 | 中等规模、多团队 | Prometheus 按业务拆分；Loki 独立集群；Alertmanager 全局共享 | 职责清晰，可独立扩缩容；运维复杂度增加 |
| 微服务 + 联邦 | 大规模、多数据中心 | Prometheus 联邦 + Thanos/Cortex；Loki 微服务模式；Grafana 统一入口 | 高可用、长期存储、全局视图；架构复杂 |
避坑提示： 不要将 Prometheus 和 Loki 部署在同一台磁盘 IO 密集的主机上。Prometheus 的 WAL 写入与 Loki 的日志写入会争抢磁盘带宽，导致采集延迟或日志丢失。建议至少分离数据盘或使用独立节点。
2.5 组件间通信协议与端口
下表列出组件间默认通信方式，便于网络策略配置与故障排查：
| 源组件 | 目标组件 | 协议 | 默认端口 | 说明 |
|---|---|---|---|---|
| Prometheus Server | Exporter / 应用 | HTTP | 9100 / 自定义 | Prometheus 主动拉取 /metrics |
| Prometheus Server | Alertmanager | HTTP/gRPC | 9093 | 推送告警事件 |
| Promtail | Loki | HTTP/gRPC | 3100 | 推送日志流 |
| Grafana | Prometheus | HTTP | 9090 | 查询指标数据 |
| Grafana | Loki | HTTP | 3100 | 查询日志数据 |
| Alertmanager | 通知渠道 | SMTP/HTTP | 25/443 | 发送告警通知 |
2.6 本章小结
- Prometheus 生态以 指标 为中心，Loki 以 日志 为中心，Alertmanager 以 事件 为中心，Grafana 以 可视化 为中心。
- 数据流分为三条主线：指标采集→告警通知、日志采集→日志查询、统一可视化。
- 部署模式需根据规模选择，生产环境推荐分层或联邦模式，避免单点瓶颈。
- 组件间通信协议以 HTTP/gRPC 为主，端口规划需提前纳入网络策略。