Prometheus 远程写入与长期存储方案从本地磁盘到可扩展的监控数据湖一、Prometheus 存储的天花板单机 TSDB 的扩展性瓶颈Prometheus 的本地 TSDB 在单机场景下表现优秀——高效的压缩算法、快速的查询性能。但当监控规模增长到数千个 Pod、数十万个时间序列时本地存储的天花板就暴露了单实例写入吞吐量达到上限、磁盘空间持续增长、历史数据无法跨节点查询、节点故障导致数据丢失。更关键的是合规审计和容量规划需要数月甚至数年的历史数据而 Prometheus 默认只保留 15 天。远程写入Remote Write和长期存储方案通过将 Prometheus 采集的数据实时发送到远端存储系统解决了本地存储的扩展性、持久性和可查询性问题。二、远程写入与长期存储架构flowchart TD A[Prometheus 实例] -- A1[本地 TSDB] A -- A2[Remote Write] A2 -- B[远程存储适配层] B -- B1[Thanos Receive] B -- B2[VictoriaMetrics] B -- B3[Cortex/Mimir] B1 -- C[对象存储] B2 -- C B3 -- C C -- C1[MinIO/S3] C -- C2[降采样层] C2 -- D[长期查询] D -- D1[Grafana 统一查询] D -- D2[容量规划报表] D -- D3[合规审计数据]2.1 Prometheus 远程写入配置# prometheus.yml — 远程写入配置 # 设计意图将采集数据实时发送到远端存储保证数据持久化 global: evaluation_interval: 30s scrape_interval: 15s remote_write: - url: http://thanos-receive:19291/api/v1/receive queue_config: # 写入队列参数 capacity: 10000 max_shards: 50 min_shards: 5 max_samples_per_send: 500 batch_send_deadline: 5s # 重试与背压 min_backoff: 30ms max_backoff: 100ms retry_on_http_429: true # 标签过滤只写入关键指标降低存储成本 write_relabel_configs: - source_labels: [__name__] regex: go_.* action: drop - source_labels: [__name__] regex: scrape_.* action: drop remote_read: - url: http://thanos-query:19192/api/v1/read read_recent: true2.2 Thanos 长期存储部署# thanos-receive-deployment.yaml — Thanos Receive 部署 # 设计意图接收 Prometheus 远程写入写入对象存储 apiVersion: apps/v1 kind: Deployment metadata: name: thanos-receive namespace: monitoring spec: replicas: 3 selector: matchLabels: app: thanos-receive template: metadata: labels: app: thanos-receive spec: containers: - name: thanos-receive image: thanosio/thanos:v0.35.0 args: - receive - --grpc-address0.0.0.0:10901 - --http-address0.0.0.0:10902 - --remote-write.address0.0.0.0:19291 - --tsdb.path/data - --tsdb.retention48h - --labelreceive_replica$(POD_NAME) - --objstore.config-file/etc/thanos/objstore.yml env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name ports: - containerPort: 10901 name: grpc - containerPort: 10902 name: http - containerPort: 19291 name: remote-write volumeMounts: - name: data mountPath: /data - name: objstore-config mountPath: /etc/thanos volumes: - name: data emptyDir: {} - name: objstore-config configMap: name: thanos-objstore-config2.3 对象存储配置与降采样# thanos-objstore-config.yaml — 对象存储配置 # 设计意图将监控数据持久化到 MinIO/S3支持降采样降低长期存储成本 type: s3 config: bucket: thanos-metrics endpoint: minio.monitoring.svc:9000 access_key: ${MINIO_ACCESS_KEY} secret_key: ${MINIO_SECRET_KEY} insecure: true # 上传优化 put_user_metadata: X-Amz-Acl: bucket-owner-full-control trace: enable: false # 分块上传 multipart_upload: max_concurrent_uploads: 4 part_size: 64MB# thanos-compactor.yaml — 降采样与数据压缩 # 设计意图对历史数据降采样降低长期存储成本 thanos compact \ --data-dir/data \ --objstore.config-file/etc/thanos/objstore.yml \ --http-address0.0.0.0:10902 \ --retention.resolution-raw30d \ --retention.resolution-5m180d \ --retention.resolution-1h365d \ --downsample.concurrency4 \ --compact.concurrency4 \ --wait \ --wait-interval5m2.4 存储成本估算脚本# storage_estimator.py — 监控存储成本估算 # 设计意图根据时间序列数量和保留策略估算存储成本 from dataclasses import dataclass dataclass class StorageEstimate: resolution: str retention_days: int samples_per_day: int bytes_per_sample: float total_gb: float monthly_cost_cny: float def estimate_storage( series_count: int, scrape_interval_seconds: int 15, ) - list[StorageEstimate]: 估算不同分辨率的存储成本 BYTES_PER_SAMPLE 3.6 # Prometheus 平均每样本字节数 S3_COST_PER_GB 0.12 # MinIO/S3 每GB月成本元 estimates [] resolutions [ (raw, 1, 30), # 原始分辨率保留30天 (5m, 20, 180), # 5分钟降采样保留180天 (1h, 240, 365), # 1小时降采样保留365天 ] for name, downsample_factor, retention in resolutions: samples_per_day series_count * (86400 // scrape_interval_seconds) // downsample_factor total_bytes samples_per_day * retention * BYTES_PER_SAMPLE total_gb total_bytes / (1024 ** 3) monthly_cost total_gb * S3_COST_PER_GB estimates.append(StorageEstimate( resolutionname, retention_daysretention, samples_per_daysamples_per_day, bytes_per_sampleBYTES_PER_SAMPLE, total_gbround(total_gb, 2), monthly_cost_cnyround(monthly_cost, 2), )) return estimates四、边界分析与架构权衡远程写入的延迟与可靠性Remote Write 通过队列异步发送数据网络抖动或远端存储不可用时数据缓存在本地队列。队列满后新数据会被丢弃。建议设置合理的队列容量和分片数并监控prometheus_remote_write_queue_highest_sent指标。降采样的精度损失5 分钟降采样只保留平均值、最大值、最小值和计数丢失了原始数据的分布细节。对于 P99 延迟分析降采样后的最大值仍可用但分布信息不可恢复。建议关键服务保留更长时间的原始数据。Thanos vs VictoriaMetrics vs MimirThanos 架构复杂但与 Prometheus 生态兼容性好VictoriaMetrics 部署简单、性能优秀但查询语法有差异Mimir 是 Grafana Labs 出品与 Grafana 深度集成。中小规模1000万序列推荐 VictoriaMetrics大规模1000万序列推荐 Mimir。对象存储的一致性MinIO 部署需要确保强一致性否则可能导致数据块损坏。建议使用纠删码模式而非多副本模式兼顾可靠性与存储效率。五、总结Prometheus 远程写入与长期存储方案通过将采集数据实时发送到远端存储系统解决了本地 TSDB 的扩展性和持久性问题。落地要点配置 Remote Write 队列参数保证写入可靠性Thanos Receive 接收数据并写入对象存储Compactor 执行降采样降低长期存储成本根据规模选择合适的远端存储方案。关键权衡原始数据保留 30 天满足实时分析5 分钟降采样保留 180 天满足趋势分析1 小时降采样保留 365 天满足合规审计。