greptime.com

一句话介绍

Greptime 是一款面向可观测性场景的统一数据库，由美国公司 Greptime Inc. 开发，旨在用一个后端同时处理指标、日志和追踪数据。它主打替代 Prometheus 和 Loki 的组合方案，并原生支持 OpenTelemetry 协议，吸引那些希望简化技术栈、降低运维复杂度的开发团队。

业务详解

Greptime 提供的是一个专门针对可观测性数据（Metrics、Logs、Traces）优化的云原生时序数据库服务。其核心卖点是“统一”：传统上，企业需要部署 Prometheus（指标）、Loki（日志）和 Jaeger（追踪）等多个系统，而 Greptime 试图用单一数据库来承载这三类数据，减少数据孤岛和运维负担。

公司成立于 2022 年左右，团队分布在美国和中国，属于可观测性数据库赛道的新兴玩家。它在开源社区有一定影响力，其核心产品 GreptimeDB 是开源项目，同时提供托管的云服务 GreptimeCloud。行业地位目前处于“挑战者”阶段，主要吸引对成本敏感、技术栈较新、愿意尝试统一方案的初创公司或中型企业。客户类型以互联网、SaaS、物联网和游戏行业的开发者为主。

适合谁用

• 中小型开发团队：尤其是那些正在使用 Prometheus + Loki + Jaeger 组合，但觉得维护多个系统太麻烦的团队。他们希望用一个更简洁的方案来降低运维成本。
• 物联网与边缘计算场景：Greptime 对边缘设备的数据采集和存储有专门优化，适合需要处理大量时序数据的 IoT 项目。
• SaaS 和微服务架构用户：如果你的应用已经接入 OpenTelemetry，Greptime 可以无缝接收标准协议数据，省去额外的适配工作。
• 预算有限的个人或小型项目：相比 Datadog 等昂贵方案，Greptime 的定价相对友好，但需注意其功能成熟度。

不适合的场景：对数据持久化、合规性要求极高的金融或医疗行业；需要深度集成特定云厂商生态（如 AWS CloudWatch）的用户；对复杂告警和仪表盘有强需求的传统运维团队。

关键功能与亮点

• 统一存储指标、日志和追踪：用一个数据库代替三个系统，减少数据冗余和查询复杂度。你可以用类似 PromQL 的语法查询指标，同时关联对应的日志和追踪数据。
• 原生支持 OpenTelemetry：直接接收 OTel 协议数据，无需额外转换。对于已部署 OTel Collector 的团队来说，集成非常顺滑。
• 云原生架构：基于 Rust 开发，性能出色；支持 Kubernetes 部署，易于水平扩展。官方云服务 GreptimeCloud 提供托管体验。
• 分布式与高可用：支持多副本、跨区域部署，数据自动分片，适合处理大规模时序数据。
• SQL 与 PromQL 双查询接口：既可以用传统 SQL 分析，也可以用 PromQL 做指标查询，降低学习成本。
• 开源与自托管选项：GreptimeDB 开源，你可以自行部署在自有服务器上，避免云厂商锁定。云服务版本则提供更省心的管理体验。

价格分析

Greptime 的定价在同类产品中属于中等偏下。其云服务起步价为每月 290 美元，这包含了一定的存储和查询额度。相比 Datadog（按主机收费，每月轻松上千美元）或 Grafana Cloud（免费额度有限，超量较贵），Greptime 的起价对初创团队更友好。但需要注意：

• 该价格仅为基础套餐，超出额度（如存储量、查询次数）需额外付费，具体超出费用官网未明确列出，建议联系销售确认。
• 暂未看到年付折扣信息，长期使用成本需自行计算。
• 开源版本完全免费，但需要自行承担服务器和运维成本。如果团队有 DevOps 能力，自托管可能是更省钱的选择。

总体来看，Greptime 的定价策略是“用统一方案降低总拥有成本”，对于数据量中等（每日几十 GB）的团队，性价比不错。但数据量极大时，成本可能不如专用方案（如单用 ClickHouse 做日志）可控。

中国用户怎么用

• 网络通畅性：GreptimeCloud 服务部署在美国，国内直连延迟较高（通常在 200ms 以上），且存在丢包风险。如果使用云服务，建议搭配 CDN 或代理，否则写入和查询体验会受影响。自托管开源版本则无此问题，只要服务器在国内即可。
• 支付方式：官网未明确列出支持的支付方式。由于是海外商家，大概率支持信用卡（Visa/Mastercard），但不支持支付宝、微信支付。如果需要对公转账或开具中国发票，建议提前联系客服确认——目前没有公开信息表明他们能提供中国发票。
• 是否需要科学上网：访问官网和使用云服务管理控制台，可能需要稳定的科学上网环境。但如果你只使用自托管版本，则完全不需要。
• 国内替代品：国内可观测性领域有阿里云 ARMS、腾讯云 Prometheus 服务、开源方案如 VictoriaMetrics + Loki 组合。Greptime 在国内的直接竞品较少，其“统一存储”概念与 TDengine（涛思数据）的时序数据库有部分重叠，但 TDengine 更侧重 IoT 场景而非可观测性。

优缺点对比

优点：

• ✅ 统一存储：减少技术栈复杂度，维护一个系统总比三个省心。
• ✅ 原生 OTel 支持：对现代可观测性架构友好，集成简单。
• ✅ 开源可选：避免云厂商锁定，适合有自建能力的团队。
• ✅ 性能不错：Rust 开发，写入和查询速度在同类中属于上游。
• ✅ 定价相对透明：起步价低于主流商业方案。

缺点：

• ❌ 生态成熟度不足：相比 Prometheus + Grafana 的组合，Greptime 的插件、告警规则、仪表盘模板较少，社区资源有限。
• ❌ 国内网络差：云服务延迟高，不适合国内直接使用。
• ❌ 支付和发票不友好：对中国用户基本没有本地化支持，企业报销困难。
• ❌ 退款政策不明确：官网无明确退款保证，试用需谨慎。
• ❌ 高级功能缺失：如复杂的告警降噪、SLO 管理、APM 深度追踪等，与 Datadog 等成熟产品有差距。

同类产品对比

• Prometheus + Loki + Jaeger：这是最经典的开源组合。优点是生态成熟、社区庞大、文档丰富；缺点是维护三个系统，查询时无法关联数据。Greptime 的核心优势就是打破这种孤岛。
• Datadog：商业可观测性巨头，功能极其全面，但价格昂贵（每主机每月 15-30 美元起），且数据量越大成本越失控。Greptime 更适合预算有限、功能需求初级的团队。
• VictoriaMetrics + ClickHouse：另一种流行方案，VictoriaMetrics 做指标，ClickHouse 做日志/追踪。性能极强，但同样需要维护两个系统。Greptime 的优势在于统一性，但单点性能可能不如专用方案。

总结建议

适合场景：

• 你是一个技术选型激进的小团队，希望用一套方案搞定可观测性，且愿意接受生态不完善的代价。
• 你的数据量中等（每日几 GB 到几十 GB），且主要使用 OpenTelemetry 采集数据。
• 你有 DevOps 能力，愿意尝试自托管开源版本（这样不受网络和支付限制）。

不适合场景：

• 你需要成熟的告警、SLO 管理、APM 深度追踪等高级功能。
• 你的团队在中国大陆，且需要云服务、需要开发票、需要低延迟访问。
• 你的数据量极大（每日 TB 级），统一方案可能成为性能瓶颈。

建议操作：先试用 GreptimeDB 开源版本，在本地或国内服务器上搭建体验。如果功能满足需求，再考虑是否升级到云服务。对于国内企业用户，除非有海外节点或代理能力，否则不推荐直接使用其云服务。