服务公告

服务公告 > 综合新闻 > Monitoring：监控性能优化

Monitoring：监控性能优化

发布时间:2026-04-21 09:01

标签：监控性能优化

一、前言

搞过监控的人都懂，Prometheus跑久了tsdb目录膨胀、查询超时、告警延迟这些问题一个都跑不掉。本篇不废话，直接讲怎么在不加硬件的前提下让监控跑得顺滑。CentOS/RHEL和Ubuntu路径分别标注，看清楚再动手。

二、操作步骤

步骤1：定位性能瓶颈

先看监控进程本身占多少资源，别上来就调参瞎改。

# CentOS/RHEL & Ubuntu 查看Prometheus进程状态
ps aux | grep prometheus | grep -v grep

# 预期输出（数值因机器而异）：
# root  12345  2.3  1.2  524288  98765  ?   Ssl  Jan15  128:32  /usr/local/bin/prometheus --config.file=/etc/prometheus/prometheus.yml
#                           ^CPU%  ^内存%

# CentOS/RHEL 查看磁盘IO
iostat -x 1 5

# Ubuntu 查看磁盘IO
iostat -x 1 5

# 预期输出关键字段：
# Device  rkB/s   wkB/s  %util
# sda     156.23  412.45  15.32

# 查看TSDB目录大小
du -sh /var/lib/prometheus/

# 预期输出：
# 45.7G  /var/lib/prometheus/

步骤2：优化采集间隔和抓取超时

采集间隔不是越小越好，60秒够用就别设成15秒，硬盘就是这么被写爆的。

# 编辑 prometheus.yml 配置文件
# CentOS/RHEL: /etc/prometheus/prometheus.yml
# Ubuntu: /etc/prometheus/prometheus.yml

# 在 scrape_configs 下修改全局配置
global:
  scrape_interval: 60s      # 默认60秒，高频监控的target可单独设置
  scrape_timeout: 30s      # 抓取超时设为间隔的一半

# 给关键服务单独设高频采集，普通服务保持60s
scrape_configs:
  - job_name: 'kubernetes-nodes'
    scrape_interval: 30s   # k8s节点保持30s
    static_configs:
      - targets: ['192.168.1.10:9100']

步骤3：配置TSDB容量和压缩

存储块大小和保留策略直接影响磁盘占用和查询速度。

# 在 prometheus.yml 同目录创建有效配置
# CentOS/RHEL: /etc/prometheus/prometheus.yml
# Ubuntu: /etc/prometheus/prometheus.yml

# 添加命令行参数或创建单独的启动脚本
# 推荐参数配置：
--storage.tsdb.path=/var/lib/prometheus/
--storage.tsdb.retention.time=15d    # 15天够用，别贪多
--storage.tsdb.block-duration=2h      # 块大小2小时，减少小文件数量
--storage.tsdb.min-block-duration=2h

# CentOS/RHEL 重启服务
systemctl restart prometheus
systemctl status prometheus

# Ubuntu 重启服务
systemctl restart prometheus
systemctl status prometheus

# 预期输出：
# ● prometheus.service - Prometheus Monitoring System
#    Loaded: loaded (/lib/systemd/system/prometheus.service; enabled)
#    Active: active (running) since Thu 2024-01-18 10:30:15 CST

步骤4：开启查询日志和慢查询分析

慢查询是CPU飙升的主因，开了查询日志你才知道谁在拖后腿。

# 在 prometheus.yml 中启用查询日志
# CentOS/RHEL & Ubuntu 配置相同

storage:
  tsdb:
    path: /var/lib/prometheus/

# 启动参数添加（注意：这会产生日志文件，单独挂载存储）
--web.enable-lifecycle
--log.level=info
--query.max-samples=50000000

# 查看Prometheus日志确认配置生效
# CentOS/RHEL
journalctl -u prometheus -f --since "5 minutes ago"

# Ubuntu
journalctl -u prometheus -f --since "5 minutes ago"

# 预期输出：
# level=info ts=2024-01-18T10:35:22.456Z caller=main.go:XXX msg="Starting Prometheus" version="(version=2.45.0)"
# level=info ts=2024-01-18T10:35:22.789Z caller=main.go:XXX msg="TSDB started"

步骤5：优化告警规则减少重复计算

告警规则写得烂，每条规则都全表扫描，CPU不飙才怪。

# CentOS/RHEL & Ubuntu 告警规则示例
# /etc/prometheus/rules/*.yml

groups:
- name: node_exporter_alerts
  interval: 30s
  rules:
  # 坏例子：这样写会重复计算相同表达式
  # - alert: HighCPU
  #   expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
  #   for: 5m

  # 好例子：复用 recording rules
  - record: instance:node_cpu_usage:avg_rate5m
    expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

  - alert: HighCPU
    expr: instance:node_cpu_usage:avg_rate5m > 80
    for: 5m

  - alert: CriticalCPU
    expr: instance:node_cpu_usage:avg_rate5m > 95
    for: 1m

步骤6：配置远程写入压缩

如果用了远程存储，写入端压缩能省一半带宽和CPU。

# 在 prometheus.yml 中添加远程写入配置
# CentOS/RHEL & Ubuntu 配置相同

remote_write:
- url: http://remote-storage:9200/write
  queue_config:
    capacity: 10000
    max_shards: 5
    min_shards: 1
    max_samples_per_send: 2000
  write_relabel_configs:
  # 过滤不需要写入远程的指标
  - source_labels: [__name__]
    regex: '(go_gc_duration_seconds|go_goroutines)'
    action: drop
  # 启用压缩
  remote_timeout: 30s
  basic_auth:
    username: prometheus
    password: YOUR_PASSWORD

步骤7：验证优化效果

改完配置不验证等于白干，跑压测看实际提升。

# CentOS/RHEL & Ubuntu 使用Prometheus自带压测工具
# 下载promtool（Prometheus包自带）
promtool test rules /etc/prometheus/rules/*.yml

# 预期输出：
#   SUCCESS: 5 rules processed
#   FAILED: 0 rules
#   DURATION: 12.345ms

# 查看当前资源使用情况
top -p $(pgrep prometheus | tr '\n' ',')

# 预期输出（优化后应该CPU下降30%以上）：
# PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM
# 12345 root     20   0 524288 98765 8192 S  1.2  1.2

步骤8：定期维护清理旧数据

# CentOS/RHEL & Ubuntu 手动清理过期数据（谨慎操作！）
# ⚠️ 警告：生产环境不要手动删数据块，用--storage.tsdb.retention.time自动清理

# 先检查数据块情况
ls -la /var/lib/prometheus/wal/

# 预期输出：
# drwxr-x-xr-x 4 prometheus prometheus 4096 Jan 18 10:00 .
# drwxr-xr-x 5 prometheus prometheus 4096 Jan 18 10:00 ..
# drwxr-xr-x 2 prometheus prometheus 4096 Jan 15 00:00 wal
# drwxr-xr-x 2 prometheus prometheus 4096 Jan 15 00:00 checkpoint.00001

三、常见问题FAQ

Q1：Prometheus进程CPU占用一直90%以上，查询还超时，怎么破？

老手告诉你别急着加内存，先看是不是查询range跨度太大。超过6小时的range查询CPU直接爆。解决办法：前端加Thanos做查询缓存，或者在Grafana限制查询时间范围别超过4小时。还有个土办法是把prometheus.yml里query.max-samples调低，强制限制单次查询样本数。

Q2：TSDB磁盘占用增长太快，2小时一块太小了怎么办？

blocksize不是越小越好，太小了会产生大量小文件，查询时要合并的块就多。改成4h或直接用默认的2h但把retention.time缩短到7天。实在扛不住就上Thanos的TSDB压缩，或者换Cortex这种集群方案。单独加硬盘是最后的选择。

Q3：告警一直延迟触发，有时候几分钟才收到，什么原因？

告警延迟基本两个原因：要么是评估间隔太长，要么是Prometheus本身在排队处理。你先看日志里有没有"context deadline exceeded"这种错误。有的话就是采集超时导致评估队列堆积。解决办法是减少全局scrape数量，把非关键指标踢掉，评估间隔别设太长，告警规则里的for字段要合理，别所有人都设for: 0m。

Q4：remote_write写入远程存储失败，队列积压怎么清？

remote_write队列积压说明远程端有问题，先检查远程存储服务是否正常。临时解决：在prometheus.yml里把max_shards设成1，capacity设小点，别让内存爆了。然后慢慢调。或者直接关掉remote_write，先保证本地可用。切记不要频繁调参重启，会丢数据。

四、总结

监控性能优化核心就三点：采集别贪多、存储别贪大、查询别贪长。90%的问题都是因为配置贪心导致资源溢出。改配置前先看瓶颈在哪，别瞎调参数。生产环境建议用Thanos或Cortex做长期方案，单机Prometheus最多扛几百个target，超过这个量级必须上集群。

延伸阅读：

Prometheus官方Tuning Guide：https://prometheus.io/docs/prometheus/latest/querying/basics/
Thanos官方文档：https://thanos.io/
监控老鸟经验：告警规则永远用recording rules预处理，别让告警表达式直接跑原始metrics

服务公告

Monitoring：监控性能优化

发布时间:2026-04-21 09:01

一、前言

二、操作步骤

步骤1：定位性能瓶颈

步骤2：优化采集间隔和抓取超时

步骤3：配置TSDB容量和压缩

步骤4：开启查询日志和慢查询分析

步骤5：优化告警规则减少重复计算

步骤6：配置远程写入压缩

步骤7：验证优化效果

步骤8：定期维护清理旧数据

三、常见问题FAQ

Q1：Prometheus进程CPU占用一直90%以上，查询还超时，怎么破？

Q2：TSDB磁盘占用增长太快，2小时一块太小了怎么办？

Q3：告警一直延迟触发，有时候几分钟才收到，什么原因？

Q4：remote_write写入远程存储失败，队列积压怎么清？

四、总结

相关推荐