GreptimeDB
在自有基础设施上用一个列式引擎统一存储和查询指标、日志与链路数据。
证据较清楚地说明了摄取协议、查询接口、组件拓扑、对象存储以及会写入仓库或发布文档的工作流；检出步骤禁用持久化凭据，Helm 更新工作流需手动触发且权限有明确范围，Git 依赖也固定到修订。扣分原因是没有面向 Agent 的权限清单、逐项确认机制或数据分类与密钥处理规范；快速启动会开放四个服务端口并挂载可写目录，外部 SKILL.md 指令未固定修订且其行为不可见。安全政策和 TLS 依赖只能提供部分敏感数据及供应链保障，Actions 依赖使用可变版本标签，也未提供依赖审计证据。原子替换测试和渐进式双写迁移提供局部恢复线索，但没有数据库操作的完整回滚或灾难恢复说明。项目、作者和上游依赖归属清楚，但发布者身份仍属未知。
README、Cargo 工作区结构和所给测试在版本、平台校验、配置更新及兼容版本管理方面基本一致；测试覆盖错误输入、缺失文件、HTTP 失败、架构不匹配和幂等更新。扣分原因是本次仅为静态阅读，不能确认测试实际通过或服务行为；Docker latest、外部文档、镜像仓库、GitHub API、对象存储及大量第三方依赖仍影响可用性。README 仅提供连接和启动故障的基础排查，测试虽要求明确异常，但没有证据表明整个数据库或 Agent 工作流都提供统一、可操作的失败消息。
文档对 Prometheus/Loki/Elasticsearch 迁移、长保留、边缘设备、GenAI 遥测、单机与分布式部署等受众和场景描述充分，并明确列出协议兼容缺口、开源与企业版边界、手工运维事项以及可选组件，因此场景和能力边界可给高分。环境适配涵盖多种对象存储、协议、部署模式和构建前置条件，但所示开发镜像校验仅支持 Linux amd64/arm64，具体资源需求和更多操作系统约束未给出。没有提供实际 Agent 触发器、调用选择规则或仓库内可审查的 Agent 指令；仅让 Agent 读取外部 SKILL.md，故 trigger_precision 为零。
README 目录和章节组织完整，提供 Docker 快速启动、源码构建、常用开发命令、FAQ、架构、兼容性、版本通道、限制、社区及支持入口。Apache-2.0 核心许可证有完整正文，企业功能及独立许可证边界也被明确说明，因此许可证、安装说明、信息架构、示例和已知限制证据充分。扣分在于 stable/canary/nightly 和工作区版本虽清楚，但 latest、main 及 nightly 引用具有可变性；材料链接到 releases、版本参考和路线图，却未提供修订内的完整变更日志。维护渠道、安全邮箱、贡献指南和商业支持均有说明，但发布者未被企业注册表验证，且所给材料没有明确的个人维护责任或响应时限。
统一摄取指标、日志和链路并用 SQL/PromQL 查询，对已有多后端观测栈具有明确增量价值；协议表、架构图、仪表板和客户端兼容性使产出在普通数据库使用中较可用。扣分原因是没有定义 Agent 调用的结构化输出契约、成功条件或结果质量保证。成本收益由减少后端数量、对象存储长保留及案例中的存储成本下降主张支持，但案例和基准主要是项目方引用，且材料未量化运行资源、迁移成本、企业功能费用或 Agent 执行成本。
主要能力可追溯到 README 的协议与架构说明，并由 Cargo 组件列表、许可证、安全政策和针对平台、原子配置更新、版本窗口的测试形成一定交叉印证；兼容与版本边界也明确区分支持项和不支持项。扣分原因是性能、生产规模、成本节约、GA 和稳定 API 等关键主张依赖未随材料提供的外部基准、案例或发布页面，无法在本次静态材料中独立核对。文档通常能区分事实、兼容缺口和企业边界，但部分营销性结论没有同时呈现方法、原始数据或不确定性。
- README 中面向 Agent 的入口要求读取并遵循外部 SKILL.md；该文件内容和固定修订均不在证据中，使用前应单独审查并固定版本。
- 快速启动映射四个端口并挂载可写数据目录；在非本地或共享环境使用前，应限制网络暴露、文件权限和对象存储凭据。
- 不要仅凭 README 的性能、规模和成本案例做生产选型；应在目标负载、保留期和对象存储配置下独立验证。
- 开源版的重分区、区域迁移和索引创建是手工操作，且材料未给出完整回滚或灾难恢复流程。
- 依赖面较大，包含多个 Git 修订依赖和使用版本标签的 GitHub Actions；部署前应进行锁文件、许可证、漏洞和工作流来源审计。
这个 Agent 能做什么，适合哪些场景？
GreptimeDB 是一个面向可观测性数据的开源列式数据库，以对象存储承载指标、日志和链路数据，并用标签、时间戳和字段组成的统一表模型组织这些信号。它可通过 OpenTelemetry OTLP、Prometheus Remote Write、Loki Push、Elasticsearch Bulk、InfluxDB 行协议和 gRPC 接收数据，并提供 SQL、PromQL、Jaeger 兼容查询以及 MySQL/PostgreSQL 线协议。系统既能以单一二进制独立运行，也能部署为由 Frontend、Datanode、Metasrv 和可选 Flownode 组成的分布式集群；计算与存储解耦，内存和本地磁盘负责缓存，对象存储保存数据。开源版本包含集群部署、对象存储、Flow 引擎、保留策略、降采样、连续聚合、显式分区和多种索引，但重新分区、区域迁移和索引创建需要手工操作。它适合希望整合多个遥测后端、延长数据保留时间或使用 SQL 关联多类信号的团队，但需要评估查询协议兼容缺口以及企业版功能边界。
数据首先通过 Frontend 暴露的 OpenTelemetry、Prometheus Remote Write、Loki Push、Elasticsearch Bulk、InfluxDB、gRPC 或数据库线协议进入系统。Frontend 负责协议入口和分布式查询，Datanode 使用 WAL、memtable、SST、缓存、压缩与索引处理数据区域并持久化到 S3、GCS、Azure Blob 或兼容 S3 的对象存储；Metasrv 负责元数据、路由、重新分区和安全，并依赖可插拔的 etcd 或 RDS 键值层。可选 Flownode 执行连续流计算和物化视图。用户随后可用 SQL 跨指标、日志和链路数据进行关联，用 PromQL 查询指标，或发起 Jaeger 兼容的链路查询；系统还可执行保留、降采样和连续聚合。
- 同时运行 Prometheus 与 Loki 或 Elasticsearch 的平台团队，希望用一个后端接收多类遥测数据并减少独立系统的运维面。
- 因高基数或长期保留而超出 Prometheus 适用范围的 SRE 团队，希望将数据放在对象存储上，同时避免引入 Thanos 或 Mimir 的额外组件。
- 需要用共同的 service、host 或 trace ID 在 SQL 中关联指标、日志和链路的可观测性工程团队。
- 计划逐步迁移的团队，可先迁移单一信号，并利用 Prometheus Remote Write、Loki Push 或 Elasticsearch Bulk 保留现有采集链路。
- 需要把采用 OTel GenAI 约定的生成式 AI 或代理遥测与基础设施信号共同保存的团队。
- 需要从单机小规模部署起步，并可能扩展到计算与对象存储解耦集群的自托管用户。
这个 Agent 有哪些优点和局限？
- 一个列式引擎和统一表模型同时处理指标、日志与链路，具有共同标识符的数据可直接通过 SQL 关联，无需在数据库之间搬运。
- 支持 OTLP、Prometheus Remote Write、Loki Push、Elasticsearch Bulk、InfluxDB 行协议和 gRPC，可按信号逐步迁移而不必重建采集器。
- 对象存储是主存储，计算与存储解耦，并通过内存和本地磁盘缓存近期或常查数据，适合长期保留。
- 可从单二进制独立模式扩展到 Frontend、Datanode、Metasrv 和 Flownode 独立伸缩的分布式架构。
- Apache-2.0 核心已包含集群、对象存储、Flow 引擎、保留策略、降采样、连续聚合、显式分区和多类索引。
- 协议兼容并不完整：PromQL 存在覆盖缺口，Loki 仅支持 Push 写入而不支持 LogQL 和其余查询 API。
- 开源核心只提供 Elasticsearch
_bulk写入；部分 QueryDSL 位于企业版，多数其他 Elasticsearch API 不受支持。 - Apache-2.0 版本中的重新分区、区域迁移和索引创建需要人工操作；读副本、工作负载隔离和自动重新分区属于企业版。
- 分布式部署涉及 Frontend、Datanode、Metasrv、可选 Flownode、对象存储以及 etcd 或 RDS 键值层，运维复杂度高于单机数据库。
- 从源码构建依赖锁定的 Rust nightly、Protobuf 和本地 C/C++ 工具链，准备成本高于直接运行预构建容器。
如何安装或部署这个 Agent？
最快的已记录方式需要 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该命令暴露 HTTP 4000、gRPC 4001、MySQL 4002 和 PostgreSQL 4003，并将数据写入当前目录的 greptimedb_data。此本地启动命令未要求凭据。若从源码构建，需要项目锁定的 Rust nightly、Protobuf 编译器 3.15 或更高版本，以及 gcc、g++、autoconf 和 glibc 开发包；执行 make 构建，再执行 cargo run -- standalone start。
如何使用这个 Agent？
容器启动后，在浏览器打开 http://localhost:4000/dashboard 验证服务。将采集端配置为向相应入口发送 OpenTelemetry OTLP、Prometheus Remote Write、Loki Push、Elasticsearch Bulk、InfluxDB 行协议或 gRPC 数据；给出的本地示例没有提供各协议的具体写入请求或认证配置。查询时可使用 SQL、PromQL、Jaeger 兼容查询，或通过 MySQL/PostgreSQL 线协议连接。若无法连接，检查 4000、4001、4002 和 4003 端口是否被防火墙阻断或被其他服务占用；若启动失败，运行 docker logs greptime 查看容器日志。
这个 Agent 与同类方案有什么区别？
与 Prometheus、Loki 或 Elasticsearch 的多后端组合相比，GreptimeDB 的差异在于用同一个列式引擎和表模型承载三类遥测，并允许 SQL 跨信号查询。对于已超出 Prometheus 基数或保留能力的团队，它被定位为避免 Thanos/Mimir 运维面的方案，但 PromQL 仅部分兼容。Loki 可通过 Push 和 Grafana Alloy 双写逐步迁移，但没有 LogQL；Elasticsearch 的开源兼容范围主要是 _bulk 写入，不能视为完整替代。
常见问题
开源版本是否支持分布式集群和对象存储？
哪些能力需要企业版？
迁移后能继续使用完整的 Loki、Prometheus 或 Elasticsearch API 吗？
_bulk，但不支持多数其他 API。本地容器无法启动或连接时应检查什么？
docker logs greptime 检查启动日志。