核心架构：指标(Metrics)+日志(Logs)+链路(Traces) 三维可观测统一闭环，故障定位从单点查错升级全链路溯源，配套告警、看板、检索标准化落地。
一、组件分工边界
| 组件 | 核心职责 | 采集对象 |
|---|---|---|
| Prometheus | 时序指标存储、告警规则、数据聚合 | CPU/内存/网络、业务 QPS、延迟、错误率、饱和度指标 |
| Grafana | 统一可视化看板、告警聚合、权限视图、数据大盘 | 汇总三类数据，统一展示与告警触发 |
| Loki | 轻量日志存储、日志检索、日志过滤 | 容器/应用/系统结构化日志，精简存储 |
| Jaeger | 分布式链路追踪 | 请求调用链、服务拓扑、接口耗时、异常节点 |
二、整体数据流转
业务/主机埋点采集 → 统一网关转发 → 分别入库 Prometheus/Loki/Jaeger → Grafana 统一查询展示 → 告警触发 → 链路+日志+指标联合排障
三、标准部署架构
1. 推荐部署模式
K8s 集群内云原生部署，采用Prometheus Operator + Loki Stack + Jaeger Operator 托管，配置 GitOps 统一管理。
组件拓扑：
- 采集端：NodeExporter、KubeStateMetrics、应用 Exporter、Promtail
- 存储端：Prometheus、Loki、Jaeger
- 展示端：Grafana 统一入口
- 告警端：AlertManager、Grafana 告警
2. 目录规范（GitOps 托管）
observability/
├── prometheus/ # 指标、告警、规则配置
├── loki/ # 日志存储、采集配置
├── jaeger/ # 链路追踪配置
├── grafana/ # 仪表盘、数据源、告警模板
├── exporters/ # 各类采集器
└── dashboards/ # 标准化看板JSON四、Prometheus 最佳实践
1. 采集规范
- 全覆盖采集
- 节点：NodeExporter 主机基础指标
- 集群：KubeStateMetrics K8s 资源指标
- 业务：应用自定义 Exporter，埋点 QPS、错误、耗时
- 中间件：MySQL、Redis、MQ 专属采集器
- 采集间隔分级
- 基础监控：15s
- 业务核心指标：5s
- 大盘统计类：30s~1min
- 标签标准化
统一标签：env、cluster、service、namespace、instance，便于筛选聚合
2. 存储与分片
- 本地短期存储+远程远端存储长期归档
- 按集群/业务分片 Prometheus 实例，避免单实例过载
- 数据保留策略：监控指标保留 15~30 天
3. 告警规则设计
- 告警分级
P0：核心服务宕机、集群不可用 → 5 分钟响应
P1：性能骤降、连接打满 → 30 分钟响应
P2：资源水位偏高 → 当日处理
P3：日常巡检类 → 定期处理 - 告警编写原则
- 阈值结合业务水位，不滥用临界告警
- 合并同类告警，抑制告警风暴
- 告警附带实例、服务、故障原因字段
- 统一告警路由
AlertManager 分组投递，区分钉钉/企业微信/邮件渠道
4. 性能优化
- 缩减无用指标，降低 cardinality 基数
- 配置查询超时、采样限制，避免慢查询拖垮服务
- 预聚合高频查询指标，提升大盘加载速度
五、Loki 日志最佳实践
1. 采集规范
- 统一使用Promtail作为日志采集客户端
- 日志强制结构化输出 JSON 格式，关键字段：时间、服务、级别、追踪 ID、错误信息
- 过滤 DEBUG 冗余日志，只保留业务关键日志
2. 索引与存储
- 标签精简，仅保留检索常用维度，减少索引开销
- 分块压缩存储，控制单块大小
- 日志留存：业务日志保留 30~90 天
3. 检索规范
- 依据 TraceID 串联日志与调用链路
- 按服务、命名空间、日志级别快速过滤
- 禁止全量模糊检索，限定时间范围缩小查询域
4. 权限与清洗
- 自动脱敏手机号、账号、密钥等敏感信息
- 按业务线划分日志访问权限
六、Jaeger 链路追踪最佳实践
1. 采样策略
- 生产环境概率采样：核心接口采样率 100%，普通接口 10%~30%
- 异常请求强制全采样，保证故障链路可追溯
2. 埋点标准
- 全链路透传 TraceID、SpanID
- 统一记录接口耗时、调用状态、上下游服务名
- 数据库、缓存、第三方调用单独生成 Span 节点
3. 排障应用
- 通过慢链路定位超时接口
- 依据异常 Span 快速找到报错服务
- 服务拓扑分析调用依赖与瓶颈点
4. 存储清理
链路数据保留 7~15 天，自动清理过期追踪数据
七、Grafana 统一平台最佳实践
1. 数据源统一接入
依次添加 Prometheus、Loki、Jaeger 三类数据源，全局共用
2. 看板分层设计
- 大盘层：全局集群、业务总览、健康状态
- 服务层：单服务 QPS、延迟、错误、资源占用
- 明细层：接口详情、日志、调用链路详情
- 复用官方开源模板，统一企业看板样式
3. 联动查询核心能力
- 指标图表一键跳转对应时间段日志
- 通过 TraceID 直接打开调用链路详情
- 三者数据时间轴对齐，同步排查故障
4. 权限管控
- 按团队、命名空间划分视图权限
- 只读权限开放查询，编辑权限收紧
- 看板、配置文件全部 Git 版本化
5. Grafana 告警补充
叠加图表级告警，和 Prometheus 告警互补，统一通知渠道
八、四组件联动排障流程
- 告警触发：Grafana/AlertManager 收到异常通知
- 指标初判：查看大盘，确认服务、节点、资源异常范围
- 链路定位：Jaeger 查询异常 Trace，确定出错服务与接口
- 日志佐证：Loki 检索对应时间、TraceID 日志，获取报错堆栈
- 根因定位：结合指标+链路+日志，定位代码/资源/依赖问题
九、安全规范
- 各组件开启身份认证，禁止匿名访问
- 监控接口、查询接口限制内网访问，屏蔽公网入口
- 日志脱敏、指标不暴露业务核心敏感数据
- 配置文件、看板 JSON 纳入 Git 版本管控，变更留痕审计
十、高可用与稳定性
- 核心组件多副本部署，消除单点故障
- 采集端容错设计，短暂断连不丢失数据
- 配置资源配额，避免监控服务抢占业务资源
- 定期备份告警规则、仪表盘、数据源配置
十一、常见避坑点
- 指标基数过高，查询卡顿、存储暴涨
- 日志无结构化，无法高效检索关联链路
- 链路采样过低，故障场景无追踪数据
- 看板杂乱无分层，排查效率极低
- 告警泛滥无分级，真实故障被淹没
十二、落地部署步骤
- Operator 方式批量部署整套可观测组件
- 配置 Exporter、Promtail 完成指标、日志采集接入
- 业务代码接入埋点，开启分布式追踪
- Grafana 配置数据源，导入标准化业务看板
- 编写分级告警规则，调试告警通知渠道
- 演练指标-日志-链路联合排障，固化排查流程
- 全部配置纳入 GitOps，统一迭代更新维护