2. 可观测性平台基础架构回顾：Prometheus、Grafana、Loki、Tempo、Alertmanager 的核心组件与数据流
在将可观测性平台纳入 Argo CD 管理之前，必须清晰理解其底层组件的职责与数据流转路径。本章回顾五个核心开源项目——Prometheus、Grafana、Loki、Tempo、Alertmanager——的架构定位与协作关系，为后续的模板化 GitOps 管理奠定基础。
2.1 核心组件一览
| 组件 | 类型 | 核心职责 | 数据来源 | 存储后端 |
|---|---|---|---|---|
| Prometheus | 指标系统 | 采集、聚合、告警规则评估 | Exporter / Pushgateway / 服务端点 | TSDB（本地磁盘） |
| Grafana | 可视化层 | 仪表盘渲染、告警可视化、多数据源统一 | Prometheus / Loki / Tempo 等 | 无状态（依赖外部数据源） |
| Loki | 日志系统 | 日志采集、索引、查询 | Promtail / Fluent Bit / 容器 stdout | 对象存储（S3/GCS/MinIO） |
| Tempo | 链路追踪 | Trace 接收、存储、查询 | OpenTelemetry Collector / Jaeger Agent | 对象存储 + 本地缓存 |
| Alertmanager | 告警管理 | 告警去重、分组、静默、路由通知 | Prometheus Alertmanager API | 无状态（内存 + 可选持久化） |
关键认知： 这五个组件并非孤立部署，而是通过标准 API 和协议形成“指标 → 日志 → 链路”三位一体的可观测性数据平面。Argo CD 管理的模板必须覆盖每个组件的配置、数据源连接以及存储路径。
2.2 数据流全景
下图展示了从数据采集到告警通知的完整数据流。箭头方向代表数据推送或拉取关系，颜色分组标识不同的数据域。
2.3 组件间协议与端口
跨组件通信依赖标准协议。下表列出关键端口与协议，在 Kubernetes 环境下需通过 Service 和 NetworkPolicy 显式开放。
| 源组件 | 目标组件 | 协议 | 默认端口 | 用途 |
|---|---|---|---|---|
| Prometheus | Exporter / 应用 | HTTP | 9100 / 8080 | 指标拉取（/metrics） |
| Prometheus | Alertmanager | HTTP | 9093 | 推送告警 |
| Promtail | Loki | gRPC / HTTP | 9095 / 3100 | 日志推送 |
| OTel Collector | Tempo | gRPC | 4317 | Trace 上报（OTLP） |
| Grafana | Prometheus / Loki / Tempo | HTTP | 9090 / 3100 / 3200 | 数据源查询 |
| Alertmanager | 通知接收方 | HTTP / SMTP | 443 / 587 | 告警通知 |
2.4 存储与持久化策略
可观测性平台对存储有显著差异。Argo CD 管理的 Helm 模板必须为每个组件声明正确的 PVC 或对象存储配置。
- Prometheus TSDB： 本地块存储，推荐 SSD。默认保留 15 天。通过
--storage.tsdb.retention.time调整。 - Loki 存储： 对象存储（S3 / GCS / MinIO）存储日志块和索引。支持多租户隔离。
- Tempo 存储： 对象存储存储 Trace 数据，本地缓存加速查询。支持
backend: s3或backend: gcs。 - Alertmanager： 无状态，告警静默和抑制规则可持久化到本地文件或数据库。
- Grafana： 无状态，仪表盘和配置通过数据库（SQLite / MySQL / PostgreSQL）持久化。
模板化注意事项： 在跨团队移植时，存储后端类型（如 MinIO 地址、S3 bucket 名称）必须作为模板参数暴露，不能硬编码。Argo CD 的 ApplicationSet 可通过集群级变量注入这些差异。
2.5 告警路由与通知链
Alertmanager 是告警流的核心枢纽。其数据流可拆解为三个阶段：
- 接收： Prometheus 根据告警规则评估后，通过 Alertmanager API 推送告警。
- 处理： Alertmanager 执行去重（重复告警合并）、分组（按标签聚合）、静默（匹配静默规则）、抑制（高优先级告警抑制低优先级）。
- 路由： 根据
route配置匹配标签，将告警发送到对应接收器（Slack、PagerDuty、Email、Webhook）。
下图展示告警路由的内部决策流程：
2.6 跨团队移植的配置要点
模板化清单： 在 Argo CD 管理场景下，以下配置项必须参数化，避免硬编码：
- 数据源 URL（Prometheus / Loki / Tempo 的 Service 地址）
- 存储后端类型与连接信息（S3 endpoint / bucket / region）
- 告警接收器凭证（Slack / PagerDuty routing key）
- 保留策略（指标保留天数、日志保留时长、Trace 保留时长）
- 资源限制（CPU / 内存 / 存储大小）
通过本章回顾，团队应能识别每个组件的配置边界与数据依赖关系。下一阶段将基于此架构设计 Helm Chart 模板结构，使 Argo CD 能够以 GitOps 方式统一管理多集群的可观测性栈。