GitLab 官方镜像内部集成 Prometheus 历史数据过大的问题处理

发表于

最近发现线上使用的 GitLab 所在的服务器磁盘空间不足，分析后发现是 GitLab 内部集成的 Prometheus 的历史监控数据导致的，居然比 GitLab 其他所有目录占用的空间都还要大，研究了半天，发现了三种方法可以解决这个问题。

方法一，解决产生问题的人，直接不启用 Prometheus，修改 GitLab 配置文件里的以下参数

1
2
3
prometheus_monitoring['enable'] = true

改为 false

一了百了，彻底解决问题，然后直接删除 /var/opt/gitlab/prometheus 目录下的文件，释放磁盘空间（注：笔者使用的是 GitLab 提供的官方 docker 镜像，此路径为镜像内部路径）。

方法二，使用 Prometheus 启动参数 storage.tsdb.retention 控制历史监控信息保留天数。

这个方法也是很直接的思路，但是因为 Gitlab 的部署方式比较特别，真的非常难找到这个启动参数是在哪里设置的，相关文档中笔者也没有找到。从 Prometheus 的进程上观察发现官方镜像是使用了 runsv 作为服务启动管理的，这样找到 runsv 相关的配置文件是否就可以了呢，测试后发现，runsv 的相关配置文件是由 GitLab 生成的，就是说每次重启 GitLab 后，这个相关配置文件就会被重置，这一点有折腾过 GitLab 集成软件的朋友可能遇到过。

于是怎么办呢，和另外一位资深运维工程师讨论后，决定使用狸猫换太子的方式处理：

直接替换 Prometheus 的二进制文件，用一个 shell 脚本替换它然后将需要新增的传入参数在这个脚本中配置好，具体操作如下：

1
2
3
4
5
6
7
8
9
10
mkdir -p /opt/gitlab/embedded/bin/prometheus-sbin
mv /opt/gitlab/embedded/bin/prometheus /opt/gitlab/embedded/bin/prometheus-sbin

cat <<EOF >/opt/gitlab/embedded/bin/prometheus
#!/bin/bash
/opt/gitlab/embedded/bin/prometheus-sbin/prometheus \\
\$* --storage.tsdb.retention=15d
EOF

chmod +x /opt/gitlab/embedded/bin/prometheus

操作完成后重启 GitLab 即可。之后在相关数据路径下 /var/opt/gitlab/prometheus 可确认 Prometheus 只保留了十五天的历史监控数据。

方法三，修改 GitLab 配置使用外部 Prometheus 接收监控数据，这里就不详细展开了。