当前位置: 首页 > web >正文

@Pushgateway 数据自动清理

文章目录

  • Pushgateway 数据自动清理
    • 一、Pushgateway 数据清理的必要性
    • 二、自动清理方案
      • 方案1:使用带TTL功能的Pushgateway分支版本
      • 方案2:使用Shell脚本定期清理
      • 方案3:结合Prometheus记录规则自动清理
    • 三、最佳实践建议
    • 四、验证与维护
    • 五、示例
    • 1. 基于时间的自动清理
      • 1.1 使用 Pushgateway 的 API 定期清理
      • 1.2 使用 Pushgateway 的 `--persistence.file` 和 `--persistence.interval` 参数
    • 2. 基于任务的自动清理
      • 2.1 任务完成后自动清理
      • 2.2 使用 Kubernetes Finalizers (如果运行在 K8s 中)
    • 3. 高级自动清理方案
      • 3.1 使用 Pushgateway 的 Admin API (需要启用)
      • 3.2 使用 Prometheus 记录规则标记过期数据
    • 4. 示例最佳实践建议

Pushgateway 数据自动清理

Pushgateway 作为 Prometheus 生态中的一个重要组件,主要用于临时和批处理作业的指标推送。然而,Pushgateway 默认不会自动清理过期指标数据,这可能导致指标堆积、内存占用过高甚至服务崩溃。以下是 Pushgateway 数据自动清理的完整解决方案。

一、Pushgateway 数据清理的必要性

Pushgateway 设计上不会自动删除推送给它的任何指标数据,这带来几个主要问题:

  1. 指标数据会无限期保留,即使相关作业已终止
  2. 随着时间推移,Pushgateway 内存占用会不断增长,可能导致服务崩溃
  3. Prometheus 会持续拉取这些过期数据,影响监控准确性

二、自动清理方案

方案1:使用带TTL功能的Pushgateway分支版本

一个社区维护的Pushgateway分支版本支持TTL(Time-To-Live)功能:

docker run -d -p 9091:9091 dmathai/prom-pushgateway-ttl:latest --metric.timetolive=60s

参数说明:

  • --metric.timetolive:设置指标的存活时间(如60s),超过此时间的指标会自动删除

优点:实现简单,无需额外维护
缺点:非官方版本,可能存在兼容性问题

方案2:使用Shell脚本定期清理

以下脚本可删除超过指定时间(如60秒)未更新的指标:

#!/bin/bash
baseurl=localhost:9091
for uri in $(curl -sS $baseurl/api/v1/metrics | jq -r '.data[].push_time_seconds.metrics[0] |select((now - (.value | tonumber)) > 60) |(.labels as $labels | ["job", "instance"] | map(.+"/"+$labels[.]) | join("/"))
'); docurl -XDELETE $baseurl/metrics/$uri
done

部署步骤

  1. 确保系统已安装jqcurl工具
  2. 将脚本保存为/opt/scripts/pushgateway_clean.sh
  3. 添加执行权限:chmod +x /opt/scripts/pushgateway_clean.sh
  4. 设置crontab定期执行(如每分钟):
*/1 * * * * /bin/bash /opt/scripts/pushgateway_clean.sh >/dev/null 2>&1

注意事项

  • 脚本假设所有Group都包含jobinstance标签
  • 如果Group包含其他标签,需要修改脚本中的标签列表
  • Group Labels有特定顺序,顺序不正确会导致删除失败

方案3:结合Prometheus记录规则自动清理

  1. 首先在Prometheus中创建记录规则,识别过期指标:
# prometheus.yml 中添加
rule_files:- 'pushgateway_rules.yml'
# pushgateway_rules.yml 内容
groups:
- name: pushgateway_cleanuprules:- record: pushgateway:stale_metricsexpr: time() - push_time_seconds > 60
  1. 使用Prometheus API查询过期指标并删除:
#!/bin/bash
STALE_METRICS=$(curl -s 'http://prometheus:9090/api/v1/query?query=pushgateway:stale_metrics' | jq -r '.data.result[].metric.job')for JOB in $STALE_METRICS; docurl -X DELETE "http://pushgateway:9091/metrics/job/$JOB"
done

三、最佳实践建议

  1. 合理设置指标生命周期

    • 短周期作业:设置较短的TTL(如5-10分钟)
    • 长周期作业:设置与作业周期匹配的TTL
  2. 标签设计规范

    • 确保每个作业有唯一的job名称
    • 包含有意义的instance标签
    • 避免使用易变的标签值
  3. 监控Pushgateway自身

    • 监控pushgateway_http_requests_total了解API调用情况
    • 监控pushgateway_metrics_count了解指标数量变化
  4. 持久化配置
    如果需要保留某些关键指标,可以启用持久化:

    docker run -d -p 9091:9091 -v /data:/data prom/pushgateway --persistence.file=/data/pushgateway.data
    

四、验证与维护

  1. 验证自动清理效果

    • 定期检查pushgateway_metrics_count指标
    • 通过Pushgateway Web界面(默认9091端口)查看当前指标
  2. 日志监控

    • 监控清理脚本的执行日志
    • 设置告警规则,当清理失败时通知
  3. 定期审查

    • 每季度审查TTL设置是否仍符合业务需求
    • 根据业务变化调整清理策略

通过实施以上SOP,可以有效管理Pushgateway中的指标数据,避免因数据堆积导致的问题,同时确保监控系统的稳定运行。

五、示例

1. 基于时间的自动清理

1.1 使用 Pushgateway 的 API 定期清理

#!/bin/bash
# cleanup_old_metrics.shPUSHGATEWAY="http://pushgateway.address:9091"
RETENTION_HOURS=24  # 保留24小时内的数据# 获取当前时间戳
CURRENT_TS=$(date +%s)# 获取所有指标组
METRIC_GROUPS=$(curl -s "${PUSHGATEWAY}/api/v1/metrics" | jq -r '.data[].pushTimeUnixSeconds')# 遍历并清理过期数据
for group in $METRIC_GROUPS; doPUSH_TIME=$(echo $group | jq -r '.pushTimeUnixSeconds')AGE_HOURS=$(( (CURRENT_TS - PUSH_TIME) / 3600 ))if [ $AGE_HOURS -gt $RETENTION_HOURS ]; thenJOB_NAME=$(echo $group | jq -r '.labels.job')INSTANCE=$(echo $group | jq -r '.labels.instance')echo "Deleting ${JOB_NAME}/${INSTANCE} (age: ${AGE_HOURS}h)"curl -X DELETE "${PUSHGATEWAY}/metrics/job/${JOB_NAME}/instance/${INSTANCE}"fi
done

设置定时任务

# 每天凌晨1点执行清理
0 1 * * * /path/to/cleanup_old_metrics.sh

1.2 使用 Pushgateway 的 --persistence.file--persistence.interval 参数

启动 Pushgateway 时添加:

./pushgateway \--persistence.file=/tmp/pushgateway \--persistence.interval=5m \--web.enable-admin-api

这样 Pushgateway 会定期将内存中的数据持久化到文件,并在启动时恢复。

2. 基于任务的自动清理

2.1 任务完成后自动清理

#!/bin/bash
# job_script.shJOB_NAME="my_batch_job"
INSTANCE=$(hostname)
PUSHGATEWAY="http://pushgateway.address:9091"# 注册退出时清理的钩子
function cleanup {echo "Cleaning up Pushgateway metrics..."curl -X DELETE "${PUSHGATEWAY}/metrics/job/${JOB_NAME}/instance/${INSTANCE}"
}
trap cleanup EXIT# 推送指标
echo "job_status{state=\"running\"} 1" | curl --data-binary @- "${PUSHGATEWAY}/metrics/job/${JOB_NAME}/instance/${INSTANCE}"# 执行实际任务
your_actual_task_here# 更新最终状态
echo "job_status{state=\"finished\"} 1" | curl --data-binary @- "${PUSHGATEWAY}/metrics/job/${JOB_NAME}/instance/${INSTANCE}"

2.2 使用 Kubernetes Finalizers (如果运行在 K8s 中)

apiVersion: batch/v1
kind: Job
metadata:name: example-job
spec:template:spec:containers:- name: mainimage: your-imagecommand: ["/bin/sh", "-c"]args:- |# 推送指标echo "job_running 1" | curl --data-binary @- http://pushgateway/metrics/job/example-job/instance/${HOSTNAME}# 执行任务your-task-here# 退出前清理curl -X DELETE http://pushgateway/metrics/job/example-job/instance/${HOSTNAME}restartPolicy: Never

3. 高级自动清理方案

3.1 使用 Pushgateway 的 Admin API (需要启用)

启动 Pushgateway 时添加 --web.enable-admin-api 参数,然后可以使用:

# 清理所有指标
curl -X PUT "${PUSHGATEWAY}/api/v1/admin/wipe"

3.2 使用 Prometheus 记录规则标记过期数据

在 Prometheus 配置中添加记录规则:

rule_files:- 'pushgateway_rules.yml'

pushgateway_rules.yml 内容:

groups:
- name: pushgateway_cleanuprules:- record: pushgateway_metric_expiredexpr: |time() - pushgateway_metric_push_time > 86400  # 24小时过期unless ON(job, instance) pushgateway_metric_value

然后可以基于此规则触发清理操作

4. 示例最佳实践建议

  1. 分层清理策略

    • 短期任务:任务完成后立即清理
    • 中期监控:设置24小时保留期
    • 长期数据:考虑直接写入Prometheus或其他TSDB
  2. 监控清理过程

    # 监控Pushgateway指标组数量
    curl -s "${PUSHGATEWAY}/metrics" | grep 'pushgateway_metrics_entries'
    
  3. 避免清理风暴

    • 大规模清理时添加延迟
    • 考虑分批清理
  4. 日志记录

    • 记录所有清理操作
    • 监控清理失败情况

通过以上方案,可以实现Pushgateway数据的自动化生命周期管理,避免无用数据积累。

http://www.xdnf.cn/news/10020.html

相关文章:

  • 碰一碰发视频系统--基于H5场景开发
  • 选择if day5
  • QPS 和 TPS 详解
  • 竞争加剧,美团的战略升维:反内卷、科技与全球化
  • C++ 游戏开发详细流程
  • 大规模JSON反序列化性能优化实战:Jackson vs FastJSON深度对比与定制化改造
  • Elasticsearch 分析器介绍
  • Camera相机人脸识别系列专题分析之六:MTK ISP6S平台人脸识别fdnode流程FdNodeImp.cpp详解
  • Xamarin劝退之踩坑笔记
  • 苹果签名!
  • 数据清理的例子
  • 【仿生机器人】仿生机器人认知-情感系统架构设计报告
  • 【Java工程师面试全攻略】Day4:JVM原理与性能调优深度解析
  • 达梦数据库:同1台服务器如何启动不同版本的DMAP服务
  • 【Docker管理工具】部署Docker管理面板DweebUI
  • 思维革命:DeepSeek-R1-0528 如何用一次小更新颠覆大模型格局
  • 每日算法-250530
  • 企业级安全实践:SSL/TLS 加密与权限管理(二)
  • 支持功能安全ASIL-B的矩阵管理芯片IS32LT3365,助力ADB大灯系统轻松实现功能安全等级
  • Tailwind CSS 实战:基于 Kooboo 构建 AI 对话框页面(五):语音合成输出与交互增强
  • JVM 性能调优
  • Day40打卡 @浙大疏锦行
  • 低功耗架构突破:STM32H750 与 SD NAND (存储芯片)如何延长手环续航至 14 天
  • 使用vscode进行c/c++开发的时候,输出报错乱码、cpp文件本身乱码的问题解决
  • 外包项目交付后还能怎么加固?我用 Ipa Guard 给 iOS IPA 增加了一层保障
  • 数据库暴露--Get型注入攻击
  • C++?多态!!!
  • Git的简单介绍分析及常用使用方法
  • openppp2 -- 1.0.0.25225 优化多线接入运营商路由调配
  • 电路笔记(通信):CAN 仲裁机制(Arbitration Mechanism) 位级监视线与特性先占先得非破坏性仲裁