prometheus API清理数据

清理数据

通过查看官网的 查询 http api 文档里有写点我跳转

存储原理

数据写入流程

新收集的指标数据首先写入内存中的 WAL（Write-Ahead Log，预写日志）

同时数据会被保存在内存中的 Head Block（头块）中

WAL 用于在 Prometheus 崩溃后恢复数据

Block（块）的概念

Block 是 Prometheus 存储的基本单位

每个 Block 包含：

• 指标数据（chunks）

• 索引文件（index）

• 元数据文件（meta.json）

• Block 是不可变的，一旦写入就不能修改

数据压缩过程

内存中的数据     ┌─── Head Block（2小时）───┐
               │  实时写入的最新数据        │
               └──────────┬──────────────┘
                          压缩
                          ↓
磁盘中的数据     ┌─── 2小时块 ─┬─ 2小时块 ──┐
               │            │           │
               └────────────┴───────────┘
                         压缩
                          ↓
最终的大块      ┌────── 24小时块 ───────────┐
              │                          │
              └──────────────────────────┘

压缩原理

当 Head Block 中的数据超过 `min-block-duration`（默认2小时）
这部分数据会被压缩并写入磁盘成为一个新的 Block
多个小的 Block 会被进一步压缩成更大的 Block，最大不超过 `max-block-duration`（默认24小时）

为什么要这样设计

- 性能考虑
  - 新数据在内存中，查询性能最好
  - 较老的数据被压缩，节省存储空间
- 数据完整性
  - Block 不可变性确保数据一致性
  - WAL 确保数据不会丢失
- 查询效率
  - 分块存储允许并行查询
  - 索引加速数据检索

压缩时间的影响

min-block-duration

优点：更频繁地将数据持久化到磁盘
缺点：产生更多小块，增加存储开销

max-block-duration

优点：更好的压缩率，节省空间
缺点：查询大时间范围的数据可能较慢

实际应用建议

保持默认值（2h/24h）通常是最佳选择
如果有大量高基数指标，可以考虑增加 `max-block-duration`
如果磁盘I/O是瓶颈，可以增加 `min-block-duration`
这就是为什么之前我建议使用默认值的原因 - 它们在大多数场景下都能提供很好的性能和资源使用平衡。只有在你遇到特定的性能问题或有特殊的存储需求时，才需要调整这些值。

介绍

目录结构

01JMJSDS2TWEE8XZKSSTRZBCK8
├── chunks
│   └── 000001
├── index
├── meta.json
└── tombstones
这都是什么意思

01JMJSDS2TWEE8XZKSSTRZBCK8
	这是一个数据块（block）的唯一标识符
	使用 ULID (Universally Unique Lexicographically Sortable Identifier) 格式
	这个 ID 包含了时间戳信息，可以用来确定块的创建时间
chunks/
	存储实际的时间序列数据
		000001 是分片文件，包含压缩后的原始指标数据 数据以高效的压缩格式存储
index
	索引文件，用于快速查找时间序列数据
	包含标签和时间戳的索引信息
	帮助 Prometheus 快速定位和检索数据
meta.json
	块的元数据文件
	包含版本信息、时间范围、压缩级别等信息
	用于管理和维护数据块
tombstones
	记录已删除数据的标记文件
	当你执行 delete_series 时，删除的数据会在这里标记
	实际的空间要等到压缩后才会释放
当我们执行删除操作时：
首先在 tombstones 中标记要删除的数据
等待压缩过程将这些标记的数据真正清理
压缩会创建新的数据块，不包含被标记删除的数据
旧的数据块最终会被删除
这就是为什么删除后需要等待压缩完成才能看到实际的磁盘空间释放。

加args参数开启api删除

–web.enable-admin-api

默认情况下，管理时间序列的 API 是被禁用的，要启用它，我们需要在 Prometheus 的启动参数中添加–web.enable-admin-api

如果不提及开始和结束时间，数据库中匹配系列的所有数据将会被清除。

kubectl edit sts -n rbd-system rbd-monitor

标记要删除的数据（delete_series）

下面的 API 调用并不会立即删除数据，实际数据任然还存在磁盘上，会在后面进行数据清理。

$ curl -X POST -g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={node_load1=".*"}&start>2025-02-21T00:00:00Z&end>2025-02-23T00:00:00Z'

删除所有标签

curl -X POST -g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={__name__=~".+"}&start>2025-02-21T00:00:00Z&end>2025-02-23T00:00:00Z'

清理标记的数据（clean_tombstones）

数据清理接口十分简单，不需要参数:
curl -XPOST http://10.43.39.64:9999/api/v1/admin/tsdb/clean_tombstones

最后整理为脚本可用

我这里的 IP 是 service 的 IP 端口是 9999 ，大家可根据需求自行更改下面脚本，获取服务IP和端口

#!/bin/bash
set -e

# 设置时间变量
START_TIME="2020-02-01T00:00:00Z"
END_TIME="2025-02-23T00:00:00Z"

# 重试函数
# 参数1: 描述信息
# 参数2: curl命令
retry_curl() {
    local description=$1
    local curl_cmd=$2
    local max_retries=3
    local retry_count=0

    echo "步骤: $description..."
    while [ $retry_count -lt $max_retries ]; do
        if eval "$curl_cmd" -s -w "%{http_code}" -o /dev/null | grep -q "204"; then
            echo "✅ $description 成功"
            return 0
        else
            retry_count=$((retry_count + 1))
            if [ $retry_count -eq $max_retries ]; then
                echo "❌ $description 失败，已重试${max_retries}次"
                return 1
            fi
            echo "⚠️ $description 失败，${retry_count}/${max_retries}次重试..."
            sleep 3
        fi
    done
}

# 获取服务IP和端口
PROMETHEUS_SVC=$(kubectl get svc -n rbd-system -l name=rbd-monitor -o jsonpath='{.items[0].spec.clusterIP}')
if [ -z "$PROMETHEUS_SVC" ]; then
    echo "❌ 未找到 rbd-monitor 服务"
    exit 1
fi

# 检查API是否启用
if kubectl get pods -n rbd-system -l name=rbd-monitor -o yaml | grep -q -- "--web.enable-admin-api"; then
    echo "✅ --web.enable-admin-api 已启用"
    echo "开始清理数据..."
    
    # 标记要删除的数据
    if ! retry_curl "标记要删除的数据" "curl -X POST -g \"http://${PROMETHEUS_SVC}:9999/api/v1/admin/tsdb/delete_series?match[]={__name__=~\\\".+\\\"}&start>${START_TIME}&end<${END_TIME}\""; then
        exit 1
    fi
    
    # 等待一下确保删除操作完成
    sleep 2
    
    # 执行真实清理
    if ! retry_curl "执行真实清理" "curl -X POST \"http://${PROMETHEUS_SVC}:9999/api/v1/admin/tsdb/clean_tombstones\""; then
        exit 2
    fi

    echo "步骤3: 重启 Prometheus 以释放磁盘空间..."
    # 获取 pod 名称
    POD_NAME=$(kubectl get pods -n rbd-system -l name=rbd-monitor -o jsonpath='{.items[0].metadata.name}')
    # 删除 pod，让 k8s 重建
    kubectl delete pod -n rbd-system $POD_NAME
    
    echo "清理操作已完成！请等待 Prometheus 重启完成后检查磁盘空间。"
    echo "提示：如果空间没有立即释放，可能需要等待一段时间让 Prometheus 完成内部压缩。"
else
    echo "❌ --web.enable-admin-api 未启用，请在prometheus配置中添加此参数"
    exit 1
fi