传统可观测性栈是三套系统起手Prometheus 收指标Loki 或 Elasticsearch 收日志Jaeger 或 Tempo 收链路。三套系统三份运维存储各管各的想关联着查还要在应用层拼。GreptimeDB 的思路是把指标、日志、链路当成同一类数据都是带时间戳的表一个用 Rust 写的列式引擎统一吃下SQL 查指标之外的一切PromQL 查指标长期数据放对象存储上。项目在 GitHub 上是 GreptimeTeam/greptimedbApache 2.0 协议2026 年 10 月 star 数在 6700 上下背后是同名的商业公司社区版功能相当完整。下面按架构、对象存储接入、部署验证的顺序展开配置细节给全。只想先把它跑起来的可以直接跳到「接 RustFS」那一节配置原样复制就能用。读这篇只需要抓住 GreptimeDB 的一个核心取舍把对象存储当默认持久层而不是把数据锁在本地盘或专用存储集群里。一个引擎吃下指标、日志、链路GreptimeDB 对三种可观测性数据用的是同一个数据模型都是表都走同一个写入管道都存在同一个列式存储引擎里。指标走 PromQL日志和链路走 SQL官方管这个定位叫 Observability 2.0。对使用者的意义是Loki 迁过来的日志、Prometheus Remote Write 推过来的指标、OpenTelemetry 上报的链路最后都落成同一套表结构关联查询就是一句 JOIN。接入协议覆盖得比较全SQLMySQL 和 PostgreSQL 线协议都能直连、PromQL、Prometheus Remote Write、OpenTelemetry OTLP、InfluxDB line protocol还有 Jaeger 兼容查询接口。对存量监控系统来说切换成本主要在数据回填和告警规则迁移客户端上报链路基本不用改。落地形态上指标就是常见的时序表日志表通常带一个 body 列配全文索引链路数据落成 span 表来源协议不同最终都走同一条 insert 路径进表。内置的运维能力是它的卖点之一数据保留策略TTL、降采样、持续聚合社区版都有TTL 到期自动清降采样和持续聚合负责把细粒度数据物化成粗粒度表派生指标不用再搭一条数据处理链路。索引侧提供倒排、跳数和全文索引分布式表还能按列值范围分区。存储引擎层面默认的 Mito 引擎之外还有一个面向高基数指标的 Metric 引擎同一份数据模型下按负载选引擎。公平地说对象存储这层 Loki 也在用chunk 本来就往 S3 放。区别不在「用不用对象存储」而在引擎统一度Loki 只管日志指标和链路还得另起系统而 GreptimeDB 把三类数据的写入、索引、TTL、降采样收进一个引擎查询面也统一成 SQL 加 PromQL。存算分离对象存储是主存储但不是唯一状态GreptimeDB 有两种跑法。Standalone 是一个进程包揽全部角色适合开发和小规模分布式模式拆成三个核心组件再加一个可选的流计算运行时。Frontend 接客户端协议、做鉴权和查询规划按元数据路由读写Metasrv 管 catalog、schema、表、Region 路由和调度元数据Datanode 承载 Region、执行读写、跑 compaction把小文件合并重写成大文件的后台任务把不可变数据文件持久化到配置的存储后端。Flownode可选跑 Flow 任务做持续计算把派生数据物化到 sink 表源表和 sink 表各自保有独立的 schema、TTL 和存储设置。写入路径是标准的存算分离套路Frontend 按元数据把数据行拆到承载目标 Region 的 DatanodeDatanode 先写内存和 WAL写前日志重启后靠重放它恢复还没落盘的写入达到 flush 条件后把不可变数据文件写进存储后端。查询时 Frontend 规划、Datanode 执行能用本地缓存就用本地缓存最后 Frontend 汇总。这里有个值得注意的设计声明官方架构文档专门写了一句对象存储不是系统中唯一的状态。WAL 记录已接收的写入Metasrv 管集群元数据和路由本地磁盘缓存远端数据。也就是说可用性和故障转移取决于三件事的组合WAL 用哪种模式、Metasrv 怎么部署、Region 怎么放置。换成人话对象存储解决了「数据不丢」但「服务不中断」还是要自己设计 WAL 和元数据层的部署。集群部署模式下 Metasrv 需要一个 KV 后端支持 etcd、PostgreSQL 和 MySQLStandalone 则不需要。Region 是分布式模式下数据和负载的基本单元一张大表按时间或列值切出多个 Region 摊到不同 Datanode 上扩缩容和故障转移都发生在 Region 这一层。对对象存储后端来说它的写入模式算是天生友好flush 产物是不可变的列存文件parquet对象存储上没有原地更新这回事写入就是追加新文件旧文件的生命周期由 compaction 管理。这正是对象存储最擅长吃的负载——大文件、顺序读写、不可变。接 RustFS从 storage 配置到部署验证存储后端在配置文件的[storage]段里声明支持本地文件、AWS S3 及一切 S3 兼容服务官方文档点名 MinIO、腾讯云 COS、百度云 BOS 等、阿里云 OSS、Azure Blob 和 GCS。接一个 S3 兼容后端的标准写法[storage] type S3 bucket greptimedb-data root /greptimedb endpoint http://rustfs:9000 region us-east-1 access_key_id greptime-admin secret_access_key 改成强密钥两个对自托管友好的细节。第一enable_virtual_host_style默认是false也就是默认走 path-style 请求http://rustfs:9000/bucket/key这种形式RustFS、MinIO 这类自建后端直连不用任何额外配置。第二除了默认的[storage]还能用[[storage.providers]]声明多个存储 provider建表时通过STORAGE选项给不同的表指定不同的桶热表和冷表、指标表和日志表分开存放一个实例就能管多个桶。缓存是对象存储后端的重头。官方给的读缓存配置是 mito 引擎里的两项[[region_engine]] [region_engine.mito] write_cache_size 10GiB enable_refill_cache_on_read truewrite_cache_size是写缓存的容量上限enable_refill_cache_on_read开着时查询遇到缓存未命中会自动把对象存储上的文件拉回本地缓存后续访问就不再回源。官方文档的建议是默认行为已经合理想省网络流量和存储成本再关。和这类存算分离架构的普遍现象一致读体验高度取决于缓存命中率热数据落在本地磁盘冷数据访问则需要回源对象存储。请求费用侧也可以按这个访问模式估对桶的写入主要是 flush 时批量上传不可变文件读取主要是查询时按需 Get 回源命中本地缓存的部分不出网。时序负载写入吞吐大flush 频率和对象数量随写入量线性走compaction 会带来额外的读和写容量规划时把对象数和请求量都按吞吐口径算别只看存储字节数。存储侧的配置和请求费用口径都清楚了接下来把它部署起来实际验证一遍。standalone 模式下两容器就能跑通一条 composeservices:rustfs:image:rustfs/rustfs:latestrestart:unless-stoppedports:-9000:9000-9001:9001volumes:-rustfs-data:/dataenvironment:RUSTFS_ACCESS_KEY:greptime-adminRUSTFS_SECRET_KEY:改成强密钥RUSTFS_ADDRESS::9000RUSTFS_CONSOLE_ADDRESS::9001greptimedb:image:greptime/greptimedb:latestrestart:unless-stoppeddepends_on:-rustfsports:-4000:4000-4002:4002volumes:-./greptimedb-standalone.toml:/etc/greptimedb/config.toml:rocommand:standalone start--config-file /etc/greptimedb/config.toml--http-addr 0.0.0.0:4000--rpc-addr 0.0.0.0:4001--mysql-addr 0.0.0.0:4002volumes:rustfs-data:greptimedb-standalone.toml就是上一节的[storage]配置。depends_on只管启动顺序不等就绪GreptimeDB 先起来连不上 RustFS 会靠restart: unless-stopped自动重试。端口上 4000 是 HTTP 和仪表盘4001 是 gRPC4002 是 MySQL 协议4003 是 PostgreSQL 协议上面只映射了常用的两个。这套 compose 只为本地验证上生产还要补凭证管理、TLS、监控和分布式模式下 Metasrv 加 etcd 的部署。验证数据真的落在 RustFS 上很简单用任意 MySQL 客户端连 4002 端口建表写入然后到 RustFS 控制台9001 端口看桶里有没有greptimedb/前缀下的 parquet 文件mysql-h127.0.0.1-P4002CREATETABLEdemo_host(host STRING,cpuDOUBLE,tsTIMESTAMPTIMEINDEX);INSERTINTOdemo_hostVALUES(node-1,0.42,2026-10-11 12:00:00);SELECT*FROMdemo_host;GreptimeDB 的建表语法要求显式声明TIME INDEX列这是它和普通 MySQL 库在 DDL 上的主要区别其余 SQL 习惯基本平移。成本口径与版本边界第一官方页面上的成本数字要按口径听官网宣称对象存储加压缩能把存储成本降到原来的 1/50还给了 OceanBase Cloud 从 Loki 迁移后 300TB 日志存储成本下降 60% 的案例这些是官方口径和客户陈述不是第三方 benchmark自己的账要自己算。第二standalone 模式进程挂掉时写路径的恢复靠 WAL 重放所以即便数据文件在对象存储上WAL 放哪本地盘还是远端决定了重启后能不能把内存里没 flush 的写入捞回来别把 WAL 和数据文件混为一谈。第三开源版和企业版有条能力分界线读副本、工作负载隔离、自动重分区、Region 负载均衡在企业版开源版跑大规模集群时Region 的均衡和隔离要自己操心。第四WAL 有本地、远端、Noop 三种模式选型直接决定可用性和故障转移行为上对象存储后端不等于可以随便关 WAL这块要按官方 WAL 文档对场景过一遍。第五分布式模式多一个 etcd或 Postgres/MySQL依赖元数据层的运维复杂度是实打实的小规模场景用 standalone 模式更省事。什么团队适合适合的场景要把 Prometheus、Loki、Jaeger 三件套合并成一栈的团队指标保留周期长、希望长期数据躺对象存储上的监控平台已经在用 RustFS 或 MinIO 做数据湖、想让可观测性数据也进同一个桶的架构。采集侧不用另建管道OpenTelemetry Collector 把 OTLP 直接指过来就行Prometheus 的 Remote Write 也是原生接口。不合适的纯实时告警对亚秒级写入延迟极其敏感的极端场景先用自己工作负载压测再说以及没有精力运维 etcd 和分布式元数据层的小团队standalone 加对象存储是更务实的起点。把它和 HelixDB 这类新一代数据系统放在一起看趋势已经非常清楚新一代数据系统不再自带存储集群列存文件往对象存储一放本地盘只做缓存。对象存储在这一代架构里的角色从「归档层」变成了「主存储」。底座选一个 S3 协议实现扎实、Apache 2.0 开源的对象存储上面跑什么引擎都有的换RustFS 在这类组合里就是干这个的。源码在 github.com/GreptimeTeam/greptimedb中文文档在 docs.greptime.cn。RustFS 的 Docker 部署见 docs.rustfs.com仓库在 github.com/rustfs/rustfs。