Mi&Bee Blog
English

可观测技术存储选型指南：场景驱动的决策框架

可观测性技术 可观测性, 存储选型, TSDB, 日志, 调用链, Profiling, 架构决策 可观测技术系列 4084 字 9 分钟阅读

前面 7 篇分别深入剖析了 TSDB、日志、调用链、RUM、Profiling 和 eBPF 等各个可观测性领域的存储架构。本篇将这些知识融会贯通，提供一份面向场景的存储选型决策框架。不同团队的规模、技术栈、预算和需求层次各不相同——没有"最佳"存储，只有"最适合你的"存储。本篇可以作为实用参考工具书，帮助你在具体场景下快速筛选方案。

新手类比：选择可观测性存储就像选车——没有 “最好” 的车，只有最适合你旅程的车。创业公司需要经济实用的紧凑型（Loki + VictoriaMetrics）；有合规要求的企业需要重型卡车（Elasticsearch）；平台团队想要多功能面包车（ClickHouse 统一存储）。关键维度：数据量、查询模式、预算和团队规模。

下方动画展示不同场景如何导向不同的存储推荐：

场景驱动的存储选型信号问题是否场景 A：创业公司 — 成本敏感，云原生指标高基数?VictoriaMetricsPrometheus日志预算敏感?LokiES / ClickHouse创业公司技术栈：Prometheus + Loki — 约 $3K/月场景 B：企业 — 合规要求，全文检索，1-3年留存指标高基数?VictoriaMetricsPrometheus日志需要全文检索?LokiES / OpenSearch企业技术栈：VM + ES — 约 $15-30K/月场景 C：平台团队 — 统一存储，跨信号关联所有信号需要跨信号 SQL JOIN?ClickHouse（统一列式存储）平台技术栈：ClickHouse 单引擎 — 约 $8-15K/月关键洞察：没有"最佳"存储——只有最适合你场景的存储维度：数据量、查询模式、预算、团队规模、合规要求

动画说明：三个场景循环展示决策矩阵。创业公司（绿色）：成本敏感路径 → Prometheus + Loki。企业（橙色）：合规驱动 → VictoriaMetrics + Elasticsearch。平台团队（紫色）：统一存储 → ClickHouse。核心要点：没有"最佳"存储，只有最适合你具体场景的存储。

本系列持续更新，后续将覆盖采集架构、查询优化、可视化、AI 辅助可观测性等主题。

跨领域存储技术对比

在深入选型之前，先总览各领域的代表项目及其核心存储理念。下表涵盖了可观测性六大领域的 14 个代表性方案。

领域代表项目核心存储理念底层格式索引策略对象存储
TSDBPrometheusGorilla压缩+mmap自定义chunk倒排(label→series)否（单节点）
TSDBVictoriaMetricsShared-Nothing LSMLSM partsmergeset是（冷存储）
TSDBInfluxDB 3.0FDAP列式Parquet/Arrow运行时重建是（S3）
日志Loki只索引标签chunk+TSDB索引标签索引是（S3）
日志ES/OpenSearch全文倒排Lucene segment倒排索引否（本地盘）
日志ClickHouse列式扫描MergeTree跳数索引是（分层）
调用链Tempo只索引TraceIDParquetBloom+index是（S3）
调用链Jaeger(ES)倒排索引Lucene segment倒排索引否
调用链SkyWalking多索引混合BanyanDBINVERTED+TREE否
RUMSentry列式OLAPClickHouse列存+bloom是（Replay）
RUMDatadog宽事件列存Husky fragment列存是（S3）
ProfilingPyroscope V2对象存储+Metastore自定义列式segment内存index是（S3）
ProfilingParca动态列式Parquet/Arrow全局排序否
eBPFPixie采集侧聚合内存N/A否

点评：从表中可以看出一条清晰的演进路径——对象存储正在成为后端标配，底层格式趋向 Parquet/Arrow 列式，传统本地盘+倒排索引的组合在成本和扩展性上逐渐被边缘化。eBPF 方案走的是另一条路：将存储压力前置到采集侧聚合。

选型建议矩阵

下表按具体场景给出推荐方案和核心理由。每个场景的假设条件已经在前面各篇中讨论过，此处直接给出结论。

场景推荐方案理由
云原生监控，Prometheus生态VictoriaMetrics兼容远程读写，Shared-Nothing易扩展，性能极高
已有Postgres栈，需ACID+SQLTimescaleDB无缝集成Postgres，连续聚合，完整事务语义
大规模监控，高基数场景InfluxDB 3.0 / VictoriaMetrics避免内存索引膨胀
海量低成本日志，标签查询为主Loki对象存储+极小索引，与Grafana/Prometheus生态一体
复杂全文检索，成熟生态ES/OpenSearch倒排索引最强，ILM完善
日志+强聚合分析ClickHouse列存向量化聚合最快
海量trace低成本长期保留Tempo对象存储，TraceID查询快，Parquet+TraceQL
已有ES，需强大搜索聚合JaegerCNCF生态，自适应采样
一站式APM（拓扑+指标+trace）SkyWalkingOAP实时分析，BanyanDB针对性优化
前端错误监控+性能SentryClickHouse列存，成熟Grouping，Replay
SaaS全托管RUMDatadog RUM分层事件模型，Husky宽事件列存
开源全栈RUMGrafana Faro复用LGTM生态，全开源
大规模continuous profilingPyroscope V2已验证19.5PB，对象存储+读写解耦
eBPF全系统剖析，零插桩Parca19Hz eBPF采集，FrostDB动态列
统一存储替代分治多库ClickHouse单引擎统一存储，SQL JOIN原生关联

场景驱动的选型决策树

以下三张图将上述矩阵转化为可操作的决策路径。按照你最核心的信号类型选择入口分支。

图 1：指标监控选型

mermaid
flowchart TD
    A[指标监控] --> B[小规模单节点]
    A --> C[大规模或需ACID]
    B --> D[Prometheus]
    C --> E[VictoriaMetrics]
    C --> F[TimescaleDB]
    style A fill:#FF9800,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#4CAF50,color:#fff
    style E fill:#4CAF50,color:#fff
    style F fill:#4CAF50,color:#fff

说明：指标监控选型的核心分水岭是规模。小规模单节点场景（如单机或少量服务器）Prometheus 足够胜任；一旦涉及多集群、大规模云环境或需要长期存储，VictoriaMetrics 的 Shared-Nothing 架构更具扩展性。如果你的技术栈已经深度绑定 PostgreSQL 且需要完整事务语义，TimescaleDB 是自然选择。

图 2：日志选型

mermaid
flowchart TD
    A[日志场景] --> B[标签查询]
    A --> C[检索或聚合分析]
    B --> D[Loki]
    C --> E[ES/OpenSearch]
    C --> F[ClickHouse]
    style A fill:#FF9800,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#4CAF50,color:#fff
    style E fill:#4CAF50,color:#fff
    style F fill:#4CAF50,color:#fff

说明：日志选型取决于你的查询模式。如果主要查询方式是按标签（namespace、pod、service 等）过滤，Loki 的极小索引和对象存储后端能带来极低的 TCO。如果需要全文检索（如关键词搜索日志正文）或复杂的文本匹配，ES/OpenSearch 的倒排索引是更成熟的选择。如果日志数据量大且需要频繁做聚合分析（如统计错误率趋势、P99 延迟分布），ClickHouse 的列式向量化执行引擎性能最优。

图 3：调用链选型

mermaid
flowchart TD
    A[调用链场景] --> B[低成本长期]
    A --> C[需强搜索或APM]
    B --> D[Tempo]
    C --> E["Jaeger(ES)"]
    C --> F[SkyWalking]
    style A fill:#FF9800,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#4CAF50,color:#fff
    style E fill:#4CAF50,color:#fff
    style F fill:#4CAF50,color:#fff

说明：调用链存储选型要在查询能力与成本之间做权衡。如果核心需求是海量 trace 的低成本长期保留且查询模式以 TraceID 为主，Tempo 的对象存储方案最具性价比。如果团队已经使用 Elasticsearch 生态且需要强大的 trace 搜索聚合能力，Jaeger(ES) 可以复用现有基础设施。如果需要一站式 APM 能力（服务拓扑、指标关联、调用链分析），SkyWalking 的 OAP 实时分析平台提供了更丰富的开箱即用功能。

可观测性存储成本与查询能力象限

以下表格从"成本"和"查询能力"两个维度定位各方案：

象限代表方案月成本参考（1TB/天）查询延迟特征适用场景
低成本-高查询能力VictoriaMetrics + S3, Tempo + S3$2,000-5,000秒级（冷查）~ 毫秒级（热查）大规模指标、trace 长期保留
高成本-高查询能力ClickHouse (NVMe), ES/OpenSearch (SSD)$5,000-20,000毫秒级全文检索、实时聚合分析、高并发查询
低成本-有限查询Prometheus（单节点）, Loki（对象存储）$500-2,000秒级~分钟级小规模监控、日志归档、按标签过滤
高成本-极高查询Datadog, SplukSaaS 按量计费毫秒级全托管、无运维、SLA 保障

成本估算基于开源方案自建，实际成本需结合云厂商定价、节点规格、副本因子和 retention 策略综合评估。

成本估算框架

以下给出不同数据规模下的参考成本区间。所有数字均为近似估算，实际部署以 PoC 验证为准。

数据规模日摄入量推荐方案月存储成本参考主要成本构成
小<100 GB/天Prometheus + 本地盘$500-2,000服务器、本地磁盘
中100 GB - 1 TB/天VictoriaMetrics + S3$2,000-8,000计算节点、对象存储、网络传输
大1 TB - 10 TB/天ClickHouse + 分层存储$8,000-30,000热节点(NVMe)、冷节点(S3)、内存
超大>10 TB/天定制化架构 + 对象存储$30,000+专用团队、多级缓存、跨区域复制

注：以上为开源方案自建成本估算。托管/SaaS 方案成本通常为自建的 2-5 倍，但省去了运维人力。

成本优化建议：

  • 利用分层存储（热/温/冷）降低冷数据成本
  • 合理配置 retention 和采样策略，避免存储无限增长
  • 评估压缩比——不同方案对同一数据的压缩比可差 3-10 倍

常见反模式与陷阱

实践中，即使是经验丰富的团队也容易踩入以下陷阱：

高基数标签爆炸：在 Prometheus 或 Loki 中将高基数值（如 user_id、request_id、IP 地址）设为标签，导致索引膨胀数十倍乃至数百倍。高基数场景应优先考虑 VictoriaMetrics 或 ClickHouse 等对高基数更友好的方案，或通过 labels 降基预处理来缓解。

全文索引成本失控：ES/OpenSearch 的全文倒排索引能力强大，但无节制地索引所有日志字段会导致存储膨胀 3-5 倍且写入吞吐骤降。应该只在需要搜索的字段上建索引，不需要搜索的字段用 index: false 关闭索引。

采样策略不当导致数据失真：激进采样（如 “只存 1% 的 trace”）虽然能大幅降低成本，但在低频事件（如 P99 延迟尖刺）上会完全丢失信号。需要根据业务场景设计分层采样策略：错误/慢 trace 全采，正常 trace 降采样。

忽视跨信号关联：分治选型（指标用 Prometheus、日志用 ES、trace 用 Jaeger）本身不是问题，但如果不规划跨信号的关联机制（如通过 exemplar 和 trace_id 注入），事故排查时将陷入"每个信号各自为政"的困境。建议优先考虑支持 OpenTelemetry 语义的信号和统一关联查询的方案。

系列总结与展望

本系列截至目前已覆盖以下主题：

篇主题
1可观测性存储架构总览
2时序数据库存储
3日志存储架构
4调用链存储架构
5RUM 时序存储
6Profiling 存储架构
7eBPF 与统一架构趋势
8存储选型指南

本系列是开放式系列，将持续更新。后续可能的主题包括：

  • 采集架构设计与优化（Agent 管理、数据管道、背压处理）
  • 查询性能优化（索引设计、缓存策略、查询路由）
  • 可观测性可视化方案（Dashboard、告警、SRE SLO 面板）
  • AI 辅助可观测性（异常检测、根因分析、智能告警降噪）
  • 多集群联邦部署与跨区域复制

感谢阅读，欢迎持续关注。

来源

本系列各篇的完整来源请参见对应文章。本篇的对比数据和选型建议整合自以下资料：

所属系列: 可观测技术系列
← 上一篇 eBPF 采集存储与可观测性统一架构趋势