OBSERVABILITY 1.0
三套系统，三类问题
- 每种信号都要独立采集链路
- 预聚合在故障发生前就丢失了细节
- 无法在一次查询中完成跨信号关联
- 规模越大，组件越多，本地磁盘越散
- 三套仪表盘、三套告警配置
一个引擎，Wide Events
- 全信号统一 OTLP 接入端点
- 存储原始宽事件，按需派生任意指标
- 一条 SQL 同时 JOIN 指标、日志、链路
- 无状态计算 + 对象存储，最高可降本 50 倍
- 一个数据源，一个运维面
Skip to content 
OBSERVABILITY 2.0 → 查看深度对比→ 查看深度对比→ 查看深度对比→ 查看深度对比→ 查看深度对比→
真正的问题不是某个指标工具。
而是你在同时维护三套系统。
深度对比
每个页面都包含架构差异、迁移路径与真实基准数据。
Prometheus / Mimir / Thanos
为了扩展一个指标系统，要维护 Distributor + Ingester + Compactor + Store-Gateway + Querier？
GREPTIMEDB ADVANTAGES
- 原生存算分离，无需 Thanos Sidecar
- PromQL + SQL，同时替代指标数仓能力
- 兼容 Remote Write，30 分钟重定向即可开始
Grafana Loki
Loki 只索引标签。每次日志正文查询都是暴力扫描——规模大了就超时。
GREPTIMEDB ADVANTAGES
- 全文索引，不再暴力扫描日志正文
- 基准测试中查询性能提升 10 倍
- 存储成本降低 30%，Grafana 数据源兼容
Elasticsearch
倒排索引为文本检索而优化。用于链路和日志存储时，额外开销显著——存储膨胀最高可达 45 倍。
GREPTIMEDB ADVANTAGES
- 列存 + 对象存储——为高效检索链路和日志提供灵活索引
- 兼容 Jaeger UI，无需重写仪表盘
- Apache 2.0 许可证（ES 为 ELv2 / SSPL / AGPLv3）
Victoria Stack
VictoriaMetrics + VictoriaLogs + VictoriaTraces——每个信号一个独立产品，三套系统各自运维。
GREPTIMEDB ADVANTAGES
- 一个引擎，一条 SQL 跨信号 JOIN 查询
- 单一摄入端点，单一运维面
- 对象存储优先 vs 本地磁盘优先架构
ClickHouse
分析能力很强。可观测性通过 ClickStack 运行，与 OLAP 核心是独立的层。
GREPTIMEDB ADVANTAGES
- PromQL、OTLP、Jaeger 在同一个二进制
- 以时间戳为核心的存储布局，为时序访问模式设计
- 动态 schema——新 span 属性自动建列
