OBSERVABILITY 1.0
三套系统，三类问题
- 每种信号都要独立采集链路
- 预聚合在故障发生前就丢失了细节
- 无法在一次查询中完成跨信号关联
- 规模越大，组件越多，本地磁盘越散
- 三套仪表盘、三套告警配置
一个引擎，Wide Events
- 所有信号本质都是带时间戳的事件
- 存储原始事件，按需派生任意指标
- 一条 SQL 同时 JOIN 指标、日志、链路
- 无状态计算 + 对象存储，最高可降本 50 倍
- 一个数据源，一个运维面
Skip to content 
OBSERVABILITY 2.0 → 
理想汽车
国家电网
TensorFusion
D6理想汽车国家电网TensorFusionD6理想汽车国家电网TensorFusionD6
v1.0.0-rc.2
化繁为一的可观测性数据库
只需一个数据库即可支持整个可观测数据存储：指标、日志、Trace 和宽事件，通过 OpenTelemetry 等标准协议写入，用 SQL 和 PromQL 查询，以对象存储为主要存储。
可观测场景统一引擎
通过标准协议与高速采集管道，统一指标、日志、链路与宽事件。内置流处理、物化视图与分布式查询引擎，全部运行在对象存储之上。从底层开始构建的 Observability 2.0 数据库。
数据源
Metrics
Wide Events
Traces
Logs
标准开放协议
OpenTelemetry
Prometheus Remote Write
超高速写入
数据库内计算
预处理
Pipeline
Pipeline
流式处理 &
物化视图
物化视图
告警/触发规则
GreptimeDB
压缩聚合、低成本、可扩展的数据存储
对象存储
应用
APM
Dashboard
Dashboard
O11y Data Analytics
AI & Machine Learning
Alerting
标准协议
SQL
PromQL
多种查询方式
客户之声
从 Loki 迁移到 GreptimeDB 实现了海量日志数据的高性能大规模查询，提供多云部署灵活性，并显著简化了应用和部署架构。
查询性能
10x
TCO 降低
30%
消除超时请求
实现秒级响应
理想汽车国家电网TensorFusionD6hebo.ai
理想汽车国家电网TensorFusionD6hebo.ai
理想汽车国家电网TensorFusionD6hebo.ai
为什么这一架构行之有效
每个设计选择都源自同一个洞察——可观测性信号本质上都是带时间戳的事件。
宽事件需要列存 + 对象存储
- 每行数百个字段的高维事件数据
- 列存引擎高效压缩和查询稀疏列
- 对象存储为主，计算独立扩展
随流量波动的数据需要弹性基础设施
- 宽事件按请求产生——可观测基础设施必须跟应用一样弹性
- 存算分离——流量尖峰时加计算节点，存储在 S3 上自然增长
- 即使写入高峰期，数据也能亚秒级可见
统一事件需要统一查询与派生
- SQL + PromQL 同时支持日常仪表盘和即席探索
- 一条查询 JOIN 指标、日志和链路
- 通过 Flow 引擎从原始事件派生指标
基于 Rust、Arrow 与 DataFusion
- 内存安全、高性能的 Rust 基础
- Apache Arrow 和 DataFusion 实现向量化查询
- 开放数据格式，无厂商锁定
