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

可观测性的最大隐性成本是存储。 一个中等规模的 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

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 方案对比

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 成本模型

分层策略：
┌─────────────────────────────────────────────────┐
│  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 自动管理
  - 支持自定义降采样规则

六、成本优化总结

七、数据压缩算法对比与选型

可观测性数据的压缩率直接影响存储成本和查询性能。不同数据类型对压缩算法的敏感度差异显著。

7.1 Metrics 数据的压缩特点

时序数据天然适合压缩：相邻时间点的数值变化小，标签重复出现，时间戳单调递增。主流 TSDB 采用的压缩策略：

Gorilla XOR 压缩：对浮点数时间序列效果极佳。原理是相邻值间的 XOR 差异通常只有低位变化，通过记录前导零数量和有效位实现高压缩。典型场景下，8 字节的 float64 可被压缩到不足 1 比特/点。

7.2 Logs 数据的压缩策略

日志数据冗余度高但结构化程度低，文本压缩算法表现迥异：

• Snappy：Google 开发，追求解压速度而非极限压缩率。适合需要频繁查询的热数据（Loki 默认）。
• ZSTD (Zstandard)：Facebook 开发，在压缩率和速度间取得优秀平衡，支持多级别（1-22）。适合温数据归档。
• LZ4：极快解压，适合实时流式写入场景。
• Brotli：极限压缩率，但解压较慢。适合冷数据长期归档（90天+）。

选型建议：热数据（7天内）用 Snappy 或 LZ4 保证查询速度；温数据（7-30天）用 ZSTD(level=3)；冷数据（30天+）用 ZSTD(level=9) 或 Brotli。

7.3 压缩与查询延迟的 trade-off

压缩率越高，查询时需要解压的数据量越大。在实际场景中，需要权衡存储节省与查询性能：

实践建议：将压缩任务交给专门的 Compactor 组件（如 Thanos Compactor、VictoriaMetrics 后台进程），而非在写入路径实时压缩，以避免影响数据采集的实时性。

参考与延伸阅读

• VictoriaMetrics 文档
• Thanos Store Gateway
• Grafana Mimir
• ClickHouse 日志处理