GreptimeDB 深度解析统一 Metrics、Logs、Traces 的开源可观测数据库实战指南【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb本指南以仓库根目录的 README.md 为骨架结合 config/standalone.example.toml、src/cmd/src/standalone.rs、src/common/catalog/src/consts.rs 与 Makefile 等源码佐证系统讲解 GreptimeDB 的核心定位、统一查询模型、支持的能力矩阵、Standalone/Distributed 两种部署架构、Docker 快速启动、源码构建流程与关键配置项。读完你将掌握如何用一套列式引擎同时承载指标、日志与链路追踪如何用 SQL 跨三类信号做关联查询以及如何从零部署一个可用的 GreptimeDB 实例并完成生产化配置。项目定位一个引擎承载三类可观测信号GreptimeDB是一个开源的 observability database可观测性数据库。按照 README.md 的定义它的核心设计是Metrics指标、Logs日志和 Traces链路追踪运行在同一个列式引擎之上数据统一存放于对象存储并且三者共享同一套表模型tags标签、timestamp时间戳、fields字段。这个统一表模型带来的直接价值是当指标、日志、追踪带有共同的标识符例如 service、host、trace ID时你可以在SQL 中直接关联查询而无需在多个数据库之间搬运数据。它从根本上改变了传统可观测性栈一个信号一个数据库的碎片化局面——Prometheus 管指标、Loki/Elasticsearch 管日志、Jaeger/Tempo 管追踪的三套系统并存模式在 GreptimeDB 中被收敛为一个后端。从源码角度看这一统一是有据可依的src/common/catalog/src/consts.rs 中定义了TRACE_TABLE_NAME: str opentelemetry_traces第 217 行、TRACE_ID_COLUMN: str trace_id第 202 行等常量说明 OpenTelemetry 写入的链路与日志数据落库为固定的系统约定表供查询侧直接使用。跨信号统一查询用一条 SQL 关联 Trace 与 LogREADME 中最具代表性的能力演示是用一条 JOIN 查询同时关联opentelemetry_traces与opentelemetry_logs两张表。OpenTelemetry 摄取写入的 span 进入opentelemetry_traces日志记录进入opentelemetry_logs两张表都携带trace_id列因此关联它们就是一个普通的 SQL JOIN-- 过去一小时内最慢的失败 span -- 连同这些 trace 内部产生的日志行。 SELECT t.service_name, t.span_name, t.duration_nano / 1000000 AS duration_ms, l.timestamp AS log_time, l.severity_text, l.body FROM opentelemetry_traces t JOIN opentelemetry_logs l ON l.trace_id t.trace_id WHERE t.timestamp now() - INTERVAL 1 HOUR AND t.span_status_code STATUS_CODE_ERROR ORDER BY t.duration_nano DESC LIMIT 20;这条查询能同时回答三个问题哪些服务在报错、最慢的失败操作是什么、以及报错瞬间的上下文日志长什么样——而这些在传统架构下需要分别查 Tempotrace、Prometheusmetric和 Lokilog再在应用层手工合并。指标同样可以以这种方式参与关联只要两张表共享任一标签如service、host、pod就可以用 JOIN 把指标和日志/追踪打通。README 明确说明Metrics join the same way, on any tag the tables share。与之对应src/common/catalog/src/consts.rs 还定义了SPAN_STATUS_ERROR: str STATUS_CODE_ERROR第 216 行、DURATION_NANO_COLUMN第 213 行等固定列名确保写入端src/servers/src/otlp/trace/v1.rs与查询端对数据模型的理解不会漂移。为什么值得选用典型使用场景README 列出了六类典型的采用动机可以作为技术选型时的判断依据你当前同时运行 Prometheus Loki 或 Elasticsearch希望用一个后端替代三个你在指标基数cardinality或保留时长retention上已经超出了 Prometheus 的能力但不想背上 Thanos/Mimir 的运维复杂度你正在触及 Loki 在日志量增长时的查询性能上限你需要把长周期数据保留在对象存储上而不想额外维护一套分析型数仓栈你希望用 SQL 查询遥测数据而不是被限定在某个领域查询语言如 LogQL里你在存储 GenAI 或 Agent 遥测遵循 OTel GenAI 语义约定需要把它们与基础设施信号放在一起。需要强调的是以上场景来自 README 的官方陈述是否适合你的环境应结合自身数据规模、查询模式与运维资源做评估。仓库中的 docs/benchmarks/tsbs/README.md 提供了可复现的基准测试说明docs/benchmarks/log/README.md 则给出了日志场景的压测方式建议自行验证。能力矩阵摄取、查询、存储与内置功能README 用一张表格概括了 GreptimeDB 的四大能力维度这里完整保留并补充说明维度支持内容摄取OpenTelemetry (OTLP)、Prometheus Remote Write、Loki Push、Elasticsearch Bulk、InfluxDB line protocol、gRPC查询SQL、PromQL、兼容 Jaeger 的 trace 查询、MySQL 与 PostgreSQL 线协议存储S3、GCS、Azure Blob 及 S3 兼容端点作为主存储配合内存与本地磁盘缓存内置能力保留策略retention、降采样downsampling、连续聚合continuous aggregation、显式表分区、倒排/跳过/全文索引inverted / skipping / fulltext indexes架构上GreptimeDB 是存储与计算分离disaggregated的对象存储承载全部数据内存与本地磁盘缓存则把近期与高频查询的数据保持在离计算更近的位置。这一设计在 config/standalone.example.toml 的[storage]段落得到印证——type可选File/S3/Gcs/Azblob/Oss默认File并支持endpoint、region、bucket、access_key_id等对象存储参数以及[storage.http_client]的连接池与超时控制。兼容性与迁移边界按协议逐项评估README 明确指出一个关键原则兼容性按协议逐一评估查询侧覆盖范围窄于摄取侧。具体到三大常见迁移对象系统兼容不兼容PrometheusRemote Write 摄取PromQL 查询PromQL 部分语法存在差距以官方兼容性清单为准LokiPush 摄取可通过 Grafana Alloy 做双写dual-write实现平滑切换LogQL 及 Loki 其余查询 APIElasticsearch开源核心支持_bulk摄取QueryDSL 在 Enterprise 版中部分支持其余大部分 Elasticsearch API值得注意的版本边界README 的 Limitations 一节集群部署、对象存储、Flow 引擎以及上表列出的全部摄取协议都在 Apache-2.0 开源构建中可用而重分区repartitioning、region 迁移、索引创建在开源版中属于手动操作。只读副本read replicas、工作负载隔离workload isolation与自动化重分区则是GreptimeDB Enterprise的功能连同企业级安全与治理能力一起与开源核心有明确边界。仓库的 LICENSE 与 LICENSE-ENTERPRISE 两份文件即是这一 open-core 模式的落地体现。系统架构Standalone 与分布式两种模式GreptimeDB 可以以两种模式运行见 README.md 的 Architecture 一节Standalone单机单一二进制适合开发环境与小规模部署开箱即用。Distributed分布式四个组件各自独立扩缩容Frontend协议入口OTel、Prometheus、MySQL/PostgreSQL、gRPC以及 Elasticsearch/InfluxDB/Loki 摄取 API同时承担分布式查询引擎。无状态可水平扩展。Datanoderegion 引擎内含 WAL、memtable、SST、缓存、compaction 与索引数据落盘到对象存储。弹性伸缩。Metasrv元数据、路由、重分区与安全底层由可插拔 KV 层支撑etcd 或 RDS。Flownode可选连续流计算流式计算与物化视图。Standalone 模式虽然只用一个进程但内部组件是完整的。查看 src/cmd/src/standalone.rs 的Instance结构体第 190-199 行可以看到它同时持有datanode: Datanode、frontend: Frontend、flownode: FlownodeInstance与procedure_manager即单机版将 Datanode、Frontend、Flownode 与过程管理procedure全部内嵌于同一进程启动顺序为启动 telemetry → 启动 leader servicesprocedure manager 与 WAL provider见第 905-931 行的DefaultStandaloneLeaderServicesController→ 启动前端插件 → 启动 Frontend → 启动 Flownode第 226-245 行。这从实现层面印证了单机 分布式组件的合体。快速上手Docker 一键启动 StandaloneREADME 给出的最快体验方式是 Docker一条命令拉起完整实例docker run -p 127.0.0.1:4000-4003:4000-4003 \ -v $(pwd)/greptimedb_data:/greptimedb_data \ --name greptime --rm \ greptime/greptimedb:latest standalone start \ --http-addr 0.0.0.0:4000 \ --grpc-bind-addr 0.0.0.0:4001 \ --mysql-addr 0.0.0.0:4002 \ --postgres-addr 0.0.0.0:4003启动后Dashboard 位于http://localhost:4000/dashboard。四个端口的职责与 config/standalone.example.toml 中的默认配置一一对应4000HTTP对应[http] addr 127.0.0.1:4000承载 HTTP API 与 Dashboard、OpenTSDB/InfluxDB/Jaeger/OTLP 等协议端点4001gRPC对应[grpc] bind_addr 127.0.0.1:4001SDK 写入的主要通道4002MySQL对应[mysql] addr 127.0.0.1:4002enable true默认开启4003PostgreSQL对应[postgres] addr 127.0.0.1:4003enable true默认开启。故障排查提示来自 README连接不上数据库检查4000、4001、4002、4003四个端口是否被防火墙拦截或被其他服务占用。启动失败用docker logs greptime查看容器日志定位原因。命令行参数与配置加载优先级从 src/cmd/src/standalone.rs 的StartCommand第 276-309 行可以看到standalone start支持的命令行参数包括--http-addr、--grpc-bind-addr别名--rpc-bind-addr/--rpc-addr、--mysql-addr、--postgres-addr、-i/--influxdb-enable、-c/--config-file、--tls-mode/--tls-cert-path/--tls-key-path/--tls-watch、--user-provider、--env-prefix默认GREPTIMEDB_STANDALONE、--data-home以及 Unix 下的-d/--daemon后台运行。配置来源的优先级在代码注释中明确写为第 340 行cli config file environment variables default values。load_options通过GreptimeOptions::load_layered_options(config_file, env_prefix)分层加载第 328-332 行再用命令行参数覆盖。值得注意的一个安全细节merge_with_cli_options会校验 gRPC 监听地址不得与 Datanode 默认保留的 gRPC 地址冲突第 383-391 行避免 Standalone 模式下端口自撞。从源码构建环境要求与构建命令前置条件根据 README 的 Build From Source 一节构建需要Rust 工具链nightly 版本由仓库根目录的 rust-toolchain.toml 固定当前锁定channel nightly-2026-03-21Protobuf 编译器protoc 3.15C/C 构建基础gcc/g/autoconf以及 glibc 开发包Ubuntu 上为libc6-devFedora 上为glibc-develPython 工具链可选仅部分测试脚本需要。构建与运行make # build greptime binary cargo run -- standalone start # start in standalone modemake目标对应 Makefile 中的build目标第 88-89 行实际执行cargo build -p cmd --locked。Makefile 还支持通过CARGO_PROFILE、FEATURES、TARGET、RELEASE等变量控制构建参数例如make build RELEASEtrue产出 release 版本。常用开发命令make fmt # 格式化 Rust 代码cargo fmt --all make clippy # lint 检查警告即失败cargo clippy --workspace --all-targets --all-features -- -D warnings make test # 单元 集成测试使用 cargo-nextest make sqlness-test # SQL 回归测试cargo sqlness bare从 Makefile 可见更多细节make test第 201-202 行依赖nextest目标自动安装 cargo-nextest并带--retries 3与pg_kvbackend,mysql_kvbackendfeature第 33 行make sqlness-test对应 tests/ 目录下的.sql/.result用例对例如 tests/cases/standalone 与 tests/cases/distributedmake fuzz则运行 tests-fuzz 下的模糊测试目标。完整的开发工作流请参考 CONTRIBUTING.md。配置要点以 Standalone 示例配置为准config/standalone.example.toml 是 Standalone 模式最完整的配置参考下面提炼几个生产化部署时最常调整的区块。服务端基础行为default_timezone UTC服务器默认时区default_column_prefix greptime自动创建时间索引、value 与 native histogram 列的默认列名前缀Legacy OTLP summary 列保留历史greptime_前缀auto_create_table写入时自动建表的全局开关默认trueuser_provider认证用户提供器例如static_user_provider:file:/path/to/users或static_user_provider:cmd:greptime_usergreptime_pwd密码验证器支持plain、pbkdf2_sha256、mysql_native_password、pg_scram_sha256等多种格式且各格式与 MySQL/PostgreSQL 协议的兼容性存在差异配置前请阅读示例文件中的详细注释max_in_flight_write_bytes默认0即不限、write_bytes_exhausted_policywait默认 10s /fail写入并发与背压控制init_regions_in_background false、init_regions_parallelism 16启动时 region 初始化策略默认等全部 region 初始化完成后再对外服务max_concurrent_queries 0最大并发查询数0 表示不限。协议服务端口与 TLS[http]默认127.0.0.1:4000、[grpc]默认127.0.0.1:4001、[mysql]默认127.0.0.1:4002enable true、[postgres]默认127.0.0.1:4003enable true四段配置与前述 Docker 命令的端口一一对应。每段都带有独立的 TLS 子配置mode/cert_path/key_path/watchMySQL 的 TLS mode 支持disable/prefer/require/verify-ca/verify-full。此外[http]还支持timeout、body_limit默认64MB、enable_cors与cors_allowed_origins。协议开关[opentsdb]、[influxdb]含default_merge_mode可选last_non_null/last_row、[jaeger]、[otlp]含experimental_enable_exponential_histogram、trace_ingest_chunk_size等、[prom_store]含with_metric_engine、prom_validation_mode等分别控制各类摄取协议的启用。例如把 Prometheus Remote Write 数据写入 metric engine 由with_metric_engine true决定。WAL 与存储[wal] provider可选raft_engine本地文件系统 WAL默认或kafka远程 WAL数据存于 Kafka。raft_engine 相关参数包括dir默认./greptimedb_data/wal、file_size默认128MB、purge_threshold默认1GB、sync_write等kafka 相关参数包括broker_endpoints、auto_create_topics、num_topics默认 64、replication_factor、max_batch_bytes以及[wal.sasl]、[wal.tls]认证配置。[storage] typeFile默认/S3/Gcs/Azblob/Oss。data_home默认./greptimedb_data使用对象存储时配置bucket、root、endpoint、region及对应云厂商凭证字段。copy_root用于 Standalone 模式下 SQL 访问本地文件的安全沙箱根目录默认data_home/copy分布式部署则始终拒绝 SQL 访问本地文件。查询引擎与 Mito 区域引擎[query]区块的parallelism0 表示 CPU 核数、memory_pool_size默认50%支持绝对大小或系统内存百分比控制查询并发与算子内存。[region_engine.mito]是核心区域引擎常见调整项包括global_write_buffer_size默认自动1/8 系统内存、上限 1GB、sst_meta_cache_size、vector_cache_size、page_cache_size等各级缓存、auto_flush_interval默认10m、max_background_compactions等后台任务并发以及enable_write_cache/write_cache_path/write_cache_size默认5GiB组成的写缓存。[region_engine.mito.inverted_index]、[region_engine.mito.fulltext_index]、[region_engine.mito.bloom_filter_index]三类索引均支持create_on_flush/create_on_compaction/apply_on_query的auto/disable开关。日志与观测[logging]控制日志目录默认./greptimedb_data/logs、级别、是否同时输出 stdout、是否启用 OTLP 追踪[slow_query]可开启慢查询日志system_table或log两种记录方式阈值默认 10s[event_recorder]记录 DDL 等管理事件默认 TTL 90 天可通过event_types选择记录类型。生态工具与扩展README 的 Tools Extensions 一节列出了与 GreptimeDB 配套的周边项目仓库内可直接参考的有grafana/README.md官方监控 Dashboard 与指标说明、docs/benchmarks/tsbs/README.md 与 docs/benchmarks/log/README.md基准测试复现、docker/docker-compose/cluster-with-etcd.yaml基于 etcd 的分布式集群编排示例。仓库外还有 Kubernetes Operator、Helm Charts、Web Dashboard、多语言 gRPC Ingester SDKGo / Java / C / Erlang / Rust / .NET / TypeScript以及 Grafana 数据源插件等均可从官方文档获取。项目状态、许可与参与方式项目状态GreptimeDB 已 GAgenerally availableAPI 稳定并有规律的发版节奏README 披露其在生产环境已有大规模部署案例如云厂商日志管理场景中运营 80 集群、管理数百 TB 日志、迁移后日志存储成本显著下降。以上为 README 转述具体到自身场景仍建议实测。许可证GreptimeDB 是 open-core 项目。核心采用 Apache License 2.0一小部分外围的企业级功能由enterpriseCargo feature 门控默认不构建受 LICENSE-ENTERPRISE 约束相关源文件带有显式的 Enterprise License 头。参与贡献完整的贡献流程见 CONTRIBUTING.md贡献者致谢见 AUTHOR.md。技术实现上项目构建在 Apache Arrow内存模型、Apache Parquet文件存储、Apache DataFusion查询引擎与 Apache OpenDAL数据访问抽象等开源组件之上。【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考