infra

可观测性数据存储选型：TSDB、列式存储、对象存储与成本优化

系统性可观测性数据存储架构指南：时序数据库对比（Prometheus/Mimir/VictoriaMetrics/Thanos Cortex/InfluxDB/TimescaleDB）、列式存储（ClickHouse/Druid/Pinot）在可观测性中的应用、日志存储对比（Loki/ES/S3+Athena/ClickHouse）、对象存储成本模型与分层策略、数据保留策略（热/温/冷/冻结）、压缩算法与降采样（Downsampling）、OTel Collector 存储后端路由、多云存储成本对比、数据合规与主权。

Leeting Yan 4 分钟阅读 1918 字

可观测性的最大隐性成本是存储。 一个中等规模的 K8s 集群每月可能产生数 TB 的 Metrics、数十 TB 的 Logs 和数百 GB 的 Traces。选择合适的存储backend、合理的数据保留策略和压缩方案，能让可观测性成本降低 50-80%。

一、可观测性数据特征

三种数据的存储特征对比：

Metrics（指标）：
├── 数据量：中（每个时间点一条记录）
├── 写入：高并发、批量、顺序写
├── 查询：时间范围 + 标签过滤 + 聚合
├── 更新：不更新，只追加
├── 保留：短（15-90 天），降采样后长期
└── 压缩：高（时序数据重复性强）

Logs（日志）：
├── 数据量：大（原始文本，非结构化/半结构化）
├── 写入：高并发、流式写入
├── 查询：全文搜索 + 时间范围 + 标签过滤
├── 更新：不更新，只追加
├── 保留：中（7-30 天热数据）+ 冷归档
└── 压缩：中（文本压缩率 5-10x）

Traces（追踪）：
├── 数据量：大（每个 Span 3-10KB，采样后）
├── 写入：高并发、批量
├── 查询：Trace ID 精确查找 + 标签过滤
├── 更新：不更新，只追加
├── 保留：短（3-15 天）+ 错误 Trace 长期
└── 压缩：中（JSON/Proto，重复标签可压缩）

二、时序数据库对比

2.1 主流 TSDB

数据库协议兼容扩展模式存储后端查询语言适用场景
PrometheusPromQL单机/联邦本地磁盘PromQL中小规模、K8s 原生
VictoriaMetricsPromQL/Influx集群本地/S3MetricsQL✅ 大规模、低成本
ThanosPromQL联邦S3/GCS/AzurePromQL多集群聚合
MimirPromQL集群对象存储PromQLGrafana Cloud
CortexPromQL集群S3/GCS/BigTablePromQL多租户 SaaS
InfluxDB v2InfluxQL/Flux集群本地FluxIoT + 监控
TimescaleDBSQL单机/分布式PostgreSQLSQLSQL 友好

2.2 选型决策树

规模评估：
├── 日指标量 < 100M
│   └── Prometheus 单机 ✅
│
├── 日指标量 100M - 10B
│   └── VictoriaMetrics 或 Thanos Sidecar
│
├── 日指标量 > 10B 或多租户
│   └── Mimir / Cortex / VictoriaMetrics Cluster
│
├── 需要 SQL 查询能力
│   └── TimescaleDB
│
├── IoT + 监控混合场景
│   └── InfluxDB v2

2.3 VictoriaMetrics 详细配置

# docker-compose.yml — VictoriaMetrics Cluster
version: '3'
services:
  vminsert:
    image: victoriametrics/vminsert:latest
    ports:
      - "8480:8480"
    command:
      - --storageNode=vmstorage-1:8401
      - --storageNode=vmstorage-2:8401
      - --replicationFactor=2

  vmselect:
    image: victoriametrics/vmselect:latest
    ports:
      - "8481:8481"
    command:
      - --storageNode=vmstorage-1:8401
      - --storageNode=vmstorage-2:8401
      - --dedup.minScrapeInterval=1ms

  vmstorage-1:
    image: victoriametrics/vmstorage:latest
    volumes:
      - vmdata1:/storage
    command:
      - --storageDataPath=/storage
      - --retentionPeriod=30d

  vmstorage-2:
    image: victoriametrics/vmstorage:latest
    volumes:
      - vmdata2:/storage
    command:
      - --storageDataPath=/storage
      - --retentionPeriod=30d

volumes:
  vmdata1:
  vmdata2:

三、日志存储

3.1 方案对比

方案查询速度存储成本扩展性适用
ELK/EFK快高（3-5x）中搜索强、预算充足
Loki + S3中极低（~1x）高✅ 云原生首选
ClickHouse极快低高结构化日志分析
S3 + Athena慢极低极高归档查询
S3 + QuickSight中低高报表分析

3.2 ClickHouse 日志存储

-- ClickHouse 日志表
CREATE TABLE app_logs
(
    timestamp DateTime64(3),
    level LowCardinality(String),
    service LowCardinality(String),
    host LowCardinality(String),
    trace_id String,
    message String,
    attributes Map(String, String),
    INDEX idx_trace_id trace_id TYPE bloom_filter GRANULARITY 4,
    INDEX idx_message message TYPE tokenbf_v1(32768, 3, 0) GRANULARITY 4
)
ENGINE = MergeTree()
ORDER BY (service, level, timestamp)
PARTITION BY toYYYYMMDD(timestamp)
TTL timestamp + INTERVAL 30 DAY;

-- 查询示例
SELECT
    service,
    count() as error_count,
    avg(duration_ms) as avg_duration
FROM app_logs
WHERE timestamp > now() - INTERVAL 1 HOUR
  AND level = 'ERROR'
GROUP BY service
ORDER BY error_count DESC;

四、对象存储与分层

4.1 成本模型

存储类型AWS S3GCSAzure Blob本地 MinIO
Standard$0.023/GB/月$0.020$0.0184硬件成本
Infrequent$0.0125/GB/月$0.010$0.0100—
Glacier$0.004/GB/月$0.0012$0.0010—
检索费用按请求计费按请求按请求无
分层策略：
┌─────────────────────────────────────────────────┐
│  Hot（热数据）—— 7 天                            │
│  ├── 本地 SSD / 高性能存储                        │
│  ├── 查询延迟 < 1s                                │
│  └── 成本：高                                     │
├─────────────────────────────────────────────────┤
│  Warm（温数据）—— 7-30 天                        │
│  ├── 对象存储 Standard                            │
│  ├── 查询延迟 < 10s                               │
│  └── 成本：中                                     │
├─────────────────────────────────────────────────┤
│  Cold（冷数据）—— 30-90 天                        │
│  ├── 对象存储 Infrequent Access                   │
│  ├── 查询延迟：可接受分钟级                       │
│  └── 成本：低                                     │
├─────────────────────────────────────────────────┤
│  Archive（归档）—— 90 天+                        │
│  ├── Glacier / Deep Archive                       │
│  ├── 查询延迟：小时级（需解冻）                   │
│  └── 成本：极低                                   │
└─────────────────────────────────────────────────┘

4.2 数据生命周期自动化

# AWS S3 Lifecycle Policy
{
  "Rules": [
    {
      "ID": "observability-data",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 7,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 30,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

# Thanos 对象存储配置（自动分层）
type: S3
config:
  bucket: "thanos-metrics"
  endpoint: "s3.amazonaws.com"
  region: "us-east-1"
  access_key: "${AWS_ACCESS_KEY}"
  secret_key: "${AWS_SECRET_KEY}"
  # Thanos Compactor 自动压缩旧数据

五、降采样（Downsampling）

降采样策略：

原始数据（1s 粒度）                     降采样后（5min 粒度）
14:00:00 ── 100                       14:00:00 ── avg(100, 102, 101, ..., 99) = 100.5
14:00:01 ── 102                       14:05:00 ── avg(...)
14:00:02 ── 101                       ...
...                                    存储减少：300x
14:04:59 ── 99

Thanos Compactor 降采样配置：
  - 原始数据保留 15 天
  - 5min 降采样保留 60 天
  - 1h 降采样保留 1 年

VictoriaMetrics 自动降采样：
  - 通过 retentionPeriod 自动管理
  - 支持自定义降采样规则

六、成本优化总结

策略效果实施难度
合理采样（Trace 1%，Log ERROR 级别）成本 -80%低
对象存储分层成本 -60%低
降采样成本 -90%（历史数据）中
标签基数控制成本 -50%中
聚合规则（Recording Rule）查询加速 + 存储优化中
冷热分离成本 -40%中
按租户/团队分摊成本可见性低

参考与延伸阅读

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「infra」更多文章

  1. 云原生 APM 与性能剖析：Continuous Profiling 与火焰图
  2. Kubernetes 可观测性实战：集群、Pod、网络、存储全链路监控
  3. eBPF 可观测性：内核可编程追踪与性能剖析