IT咖啡馆｜漫谈监控简史到全栈可观测数据选型

1. 监控简史（超短版，却是血泪史）

• 1990s：SNMP 轮询 那个年代的监控几乎就是“能不能 ping 通，CPU 用了几成”。出了问题，屏幕上就一个“红灯亮了”，至于“为什么”没人能说得清。
• 2000s：Nagios/Zabbix + syslog 引入了阈值、模板、告警，看起来专业多了，但一切都依赖运维工程师的经验来堆规则。结果就是规则越写越多，告警风暴越来越严重。
• 2010s：Prometheus / ELK / APM Prometheus 让指标“说人话”，ELK 能搜日志，APM 给你调用链。问题是堆栈越来越多，监控/日志/链路各玩各的，系统割裂。
• 2020s：OTel + L/M/T + eBPF + SRE 统一采集、统一语义、SLO/SLI 成“合同”，可观测终于成了体系。但体系≠自动会飞，治理和设计没跟上，还是一样翻车。

👉 一句话总结：监控 30 年，一直在从“能不能看见”走向“能不能解释清楚”。

2. 全栈可观测，先画边界

“全栈”不只是炫酷口号，真正落地要回答三件事：

• 信号面要齐全：Metrics / Logs / Traces / Flows / Profiling / RUM / 业务指标，一个都不能漏。
• 数据路径要顺畅：Agent / Sidecar → Gateway（打标签、采样、WAL） → 存储（冷热分层） → 查询与自动化。
• 语义面要统一：所有观测数据都需要“事件包络”+“拓扑图谱”，才能相互验证、形成证据链。

全栈不是把所有数据丢进一个大桶，而是职责分层，让信息能互证。

3. 误区一：可观测 ≠ 替代监控

监控和可观测职责不同，缺一不可：

• 监控：早发现，负责“红灯要亮”，比如 SLO 守门、阈值触发、自动回滚。
• 可观测：快定位，负责“红灯为什么亮”，比如证据链、根因路径、知识复用。

没有监控，你就是数字考古；没有日志，你只是盯着彩色仪表盘壁纸发呆。

4. 误区二：回溯 ≠ 告警

把所有数据都丢进对象存储，回头一查确实什么都有。但告警要的是“现在”。

• 告警看检测延迟（Detection Latency）和修复时间（MTTR）。
• 回溯看完备性（Completeness）和可解释性（Explainability）。

生产环境里，请先保证“能准时叫醒人”，再去“讲清楚事情”。

5. 误区三：没有前提的“一分钟三步定位”都是 PPT

能“一分钟三步定位”的前提至少包括：

• 统一标签体系（tenant/env/app/... 全链路一致）
• 合理采样策略（Trace tail-based + 错误/慢调用上采样）
• 基数治理（series/fan-out 上限）
• Runbook/知识库可复用
• 双时态拓扑图能复盘当时依赖关系

缺一个，所谓“一分钟”就会变成“一小时三十步”。

6. 误区四：没有思考的维度划分 = 自造迷雾

• 网络是信号，不是真相；通信断了 ≠ 根因一定在网。
• 事件是状态变化，不是一条普通 log line。
• “应用路径/网络路径”其实就是 L7/L4 协议层的聚合指标，没必要硬叫成“路径”。

真正有价值的维度划分应该服务“证据链”：指标报错 → 事件对齐 → 追踪与日志取证 → 拓扑约束路径 → 知识库复用。

7.主流选型并排评审

要做全栈可观测，免不了要面对几个“老熟人”方案。不同技术各有来历和优势，有的天生为可观测而生，有的则是“借道而入”。

• Grafana LGTM：统一语言、生态强，但自建复杂度高，需要团队有治理能力。
• OpenObserve：轻量一体、低门槛、成本友好，适合近线层。
• Elasticsearch：全文搜索最强，但热层成本贵、JVM/分片调优难。
• ClickHouse：聚合/压缩极强，适合报表和长保留，但不适合做全文。

👉 我们的选择逻辑是：不是“选一个打天下”，而是按维度分工，哪一维遇瓶颈就替换那一维。最终，我们把运维可观测归约为“五维一图”：

1. 指标/时序
2. 日志
3. 链路
4. 拓扑
5. 知识库 / 向量

这就是“五维一图”：既是数据的统一容器，也是 AIOps 的证据链框架。

8. 双引擎落地： 为什么是 OpenObserve + PostgreSQL + Timescale + AGE + pgvector

A. 问题绑定与职责拆分（先定边界）

• 近线 I/O 面（明细多、吞吐大、时效强） 以日志/指标/追踪为主，写入量大、查询以时间窗和标签过滤为主，强调秒～分钟级可达与低成本海量留存。 → OpenObserve（OO）：对象存 + 列式（Parquet/Lance），写入顺滑、压缩比高、按时间/标签读少量必要列，性价比极佳。
• 治理/知识面（解释强、融合多、历史长） 关注结构化聚合、拓扑时态、知识复用，强调可解释与二次加工（报表、RCA、画像）。 → PostgreSQL + Timescale + AGE + pgvector：关系 + 时序连续聚合 + 图时态 + 向量检索“同库共栈”，就地 JOIN 与一次查询产出多维证据。

结论：重 I/O 的明细放 OO；可解释的摘要与证据链沉到 PG 栈。冷热分层、读写分责，天然避开“一个引擎干所有”带来的成本和复杂度爆炸。

B. 选型动机（从三条主线看最优解）

1) 资源与成本

• OO：低成本近线
  • 主数据走对象存，热盘占比小；列式压缩 + 只读必要列，单位 TB 成本低。
  • 日志/追踪天然按时间分桶，冷热快速切换，30～180 天近线留存不心疼。
• PG/Timescale：长期“可解释”数据低体量
  • 连续聚合/物化，把“1m/5m/1h”窗口固化，聚合数据量≈原始明细的数个百分点。
  • 只把资源事实 + 聚合边权 + 摘要/Runbook 向量存入 PG，能省就省。

2) 性能与可观测体验

• OO 处理时间窗 + 标签的典型检索：TOPK、错误率、分位数，近线秒级。
• Timescale 连续聚合命中，历史报表/趋势避免全表扫。
• AGE 在 PG 内做双时态图（valid_from/to），支持“回放当时依赖”，RCA 可追溯。
• pgvector 与结构化维度共库，先 SQL 过滤（租户/时间/服务）再 ANN，检索更稳更准。

3) 架构与演进

• 双引擎物理解耦、职责清晰，可按维度替换：
  • 需要标准语言统一 → L/M/T 可替换为 LGTM；
  • 聚合/报表极重 → 外挂 ClickHouse 做OLAP；
  • 全文搜索诉求强 → 辅以 Elasticsearch 专做全文取证。
• 替换只动那一维，其余维度不受影响，演进摩擦小。

C. 每个组件“为什么是它”

• OpenObserve（OO）
  • 一体化 Logs/Metrics/Traces，对象存优先 + 列式落盘，TCO 友好；
  • 适合“热 3–14 天 / 近线 30–180 天”的运营节奏；
  • 与 OTel/Gateway 天然衔接，易于打标签、采样、WAL 抗突发。
• PostgreSQL（基础）
  • 可靠的关系底座，事务与审计完备，RLS 做租户隔离；
  • 统一承载 Timescale/AGE/pgvector 扩展，减少系统碎片化。
• Timescale（时序/连续聚合）
  • time_bucket + 连续聚合 + 压缩，把计算沉淀为数据；
  • 支持迟到重算与层级聚合，配合“edge_5m / edge_1h”形成运行时服务图的“边权”。
• AGE（图谱/双时态）
  • 在 PG 内用 openCypher 表达点/边/时态；
  • “IaC 实体 + 配置期望 + 运行时派生边”同库回放，RCA 时路径约束容易落地。
• pgvector（知识/相似案例）
  • 只对摘要/Runbook/模板建向量索引，结合结构化过滤就地检索；
  • 故障时按“向量相似度 × 图证据 × 指标异常度 × 时间接近度”重排序，给出可执行答案。

D. 替代方案为什么“不如它”（简述）

• Elasticsearch：全文最强，但热层贵/写放大/JVM/ILM 调优重；做长保留近线成本不友好。
• ClickHouse：聚合/压缩王者，但全文/多模态弱；适合外挂做报表而非近线三栈。
• LGTM（Loki/Mimir/Tempo）：语言统一、生态强，但自建角色多/基数治理复杂；当团队已深度 Grafana 时非常合适，否则一体化落地成本略高。 → OO + PG 栈在“成本/复杂度/可解释性/演进自由度”之间更平衡。

E. 风险与对策（落地级别的提醒）

1. 标签基数失控（OO/LGTM 共同风险）
   • 对策：网关白名单 + 哈希/截断；限 series/fan-out；无时间前缀查询直接拒绝。
2. PromQL 兼容差异
   • 对策：金丝雀面板验证；关键 Recording Rules 固化在网关/任务层。
3. 对象存小块抖动
   • 对策：批量写/块合并（chunk ≥ 64MB）、前端缓存、查询并发/并行度治理。
4. Timescale 聚合准确性
   • 对策：窗口晚闭合 10–15 分钟；迟到重算；多级聚合（1m→5m→1h）。
5. AGE 图规模增长
   • 对策：边分层（事实边长期/派生边短期聚合）；按域拆图；必要时可迁出图引擎，PG 仍做事实仓。
6. pgvector 嵌入漂移
   • 对策：季度重嵌入；只对摘要建索引；ANN 使用 HNSW/IVF + 精排。

F. 目标度量（落地要追的 KPI）

• 近线查询：P95 < 3s（5m 窗口 TOPK / 错误率 / P95）
• 写入可用：日志接入成功率 ≥ 99.9%，追踪丢样受控（采样率策略化）
• 成本上限：近线存储 ¥/TB·月 有预算红线（按对象存计费）
• RCA 时效：S1 级事故，证据链拼齐 ≤ 10 分钟（指标→事件→链路→日志→知识）

G. 一段“如何用它定位问题”的现实场景

晚高峰，订单失败率升高。 1）OO 指标告警：error_rate(order→payment) > 5%； 2）Timescale 边权显示该边 P95 飙升，AGE 图约束路径只在 payment 域异常； 3）OO Trace 聚焦慢调用样本，错误集中在 payment-v2； 4）事件流显示 10 分钟前 payment-v2 灰度 30% → 60%； 5）pgvector 召回“去年双11同类回滚案例”，建议：先降灰、回滚配置、清理连接池。 → 复盘材料自动汇总成证据链，可直接沉入知识库。

结语

从 SNMP 红灯 到 OTel 统一语义，从割裂堆栈到五维一图，监控与可观测的演进其实就是一场“把数据放在合适引擎里”的长期博弈。

OO 扛吞吐与近线；PG/TS/AGE/pgvector 沉淀聚合、图谱与知识。 当某一维遇到新需求或瓶颈，只替换那一维——这就是我们选型的核心哲学：冷得住、算得动、改得快。