OBSERVABILITY 1.0
三套工具，三类复杂度
- 每种信号都要独立采集链路
- 无法在一次查询中完成跨信号关联
- 规模越大，组件越多，运维越重
- 数据分散在多套本地磁盘体系
- 三套仪表盘、三套告警配置
OBSERVABILITY 2.0
一个引擎，Wide Events
- 全信号统一 OTLP 接入端点
- 一条 SQL 同时 JOIN 指标、日志、链路
- 基于 S3 的无状态计算节点弹性扩展
- 对象存储为主，最高可降本 50 倍
- 一个数据源，一个运维面
Skip to content 
查看深度对比→ 查看深度对比→ 查看深度对比→ 查看深度对比→ 查看深度对比→
真正的问题不是某个指标工具。
而是你在同时维护三套系统。
深度对比
每个页面都包含架构差异、迁移路径与真实基准数据。
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，比 Grafana 栈好——但仍然是三套系统。
GREPTIMEDB ADVANTAGES
- 一个引擎，一条 SQL 跨信号 JOIN 查询
- 单一摄入端点，单一运维面
- 对象存储优先 vs 本地磁盘优先架构
ClickHouse
分析能力很强。可观测性通过 ClickStack 运行，与 OLAP 核心是独立的层。
GREPTIMEDB ADVANTAGES
- PromQL、OTLP、Jaeger 在同一个二进制
- 以时间戳为核心的存储布局，为时序访问模式设计
- 动态 schema——新 span 属性自动建列
渐进迁移，而不是一次性重构
先从最痛的信号开始。写入重定向分钟级，完整迁移取决于协议兼容性。
重定向写入
将写入端点（Remote Write、OTLP、Loki Push API）指向 GreptimeDB。指标、日志、链路都适用。零停机。
~30 分钟
迁移仪表盘和查询
PromQL / Jaeger 兼容栈——切换数据源，小时级。其他栈——用内置仪表盘或迁移查询，天到周级。
小时到周级
回填并下线旧系统
导出历史数据批量导入 GreptimeDB。验证后逐步下线旧系统。
天到周级
