1. 问题背景与现象分析上周五下午3点我们团队的GitLab实例突然出现响应超时前端页面加载卡在502错误API接口返回504状态码。当时正值代码提交高峰十几个开发团队同时受到影响。通过监控系统快速定位发现服务器根分区使用率已达98%而正常情况下这个数值应该维持在70%以下。这种情况在自建GitLab环境中并不罕见。当磁盘空间不足时GitLab的核心组件特别是Unicorn和Sidekiq会因无法写入临时文件而进入阻塞状态。具体表现为Web界面加载超时超过30秒Git push/pull操作中途失败后台任务如CI/CD流水线卡在pending状态管理员面板无法打开关键提示GitLab对磁盘空间敏感度远高于内存和CPU资源因为它的日志系统、仓库数据和临时文件都需要持续写入磁盘。当可用空间低于5%时服务稳定性会急剧下降。2. 根因诊断与排查路径2.1 快速定位问题源通过SSH登录服务器后我立即执行了以下诊断命令# 查看磁盘空间总体使用情况 df -h # 定位大文件目录按大小降序 du -sh /* | sort -rh | head -10 # 检查GitLab日志目录大小 du -sh /var/log/gitlab/*输出显示/var/log/gitlab目录占用了42GB空间其中sidekiq.log和gitlab-rails/production.log两个文件各超过15GB。这是典型日志轮转配置失效的表现。2.2 日志暴增的深层原因进一步分析日志内容发现# 查看日志高频条目 tail -n 1000 /var/log/gitlab/gitlab-rails/production.log | \ awk {print $8} | sort | uniq -c | sort -nr | head -5输出显示大量Java项目的CI构建日志被完整记录每条记录包含完整的Maven依赖树打印。这是由于项目中的.gitlab-ci.yml错误配置了CI_DEBUG_TRACE: true参数导致构建过程的所有输出都被追加到GitLab主日志。3. 紧急处理方案实施3.1 安全清理日志文件直接删除日志文件可能导致正在运行的进程崩溃。正确的做法是# 清空日志内容但保留文件句柄避免服务重启 truncate -s 0 /var/log/gitlab/sidekiq.log truncate -s 0 /var/log/gitlab/gitlab-rails/production.log # 清理旧的日志归档保留最近7天 find /var/log/gitlab -name *.gz -mtime 7 -exec rm {} \;这个操作立即释放了38GB磁盘空间根分区使用率降至65%。3.2 服务重启的正确姿势单纯执行gitlab-ctl restart可能造成数据不一致。推荐的分步操作# 停止服务优雅关闭 sudo gitlab-ctl stop # 确保所有进程已终止 ps aux | grep gitlab | grep -v grep || echo All stopped # 启动服务完整初始化 sudo gitlab-ctl start # 验证服务状态 sudo gitlab-ctl status | grep -E run|down整个过程耗时约3分钟期间GitLab会短暂不可用建议通过维护页面通知用户。4. 长效预防措施配置4.1 日志轮转策略优化编辑GitLab的日志配置文件/etc/gitlab/gitlab.rblogging[logrotate] { rotate 30, rotate_every day, keep_for 30 days, compress true, delaycompress true, maxsize 100M, minsize 10M }然后执行sudo gitlab-ctl reconfigure使配置生效。这个设置确保单个日志超过100MB立即轮转每天强制轮转一次保留最近30天的日志启用gzip压缩旧日志4.2 磁盘空间监控告警在Prometheus中添加以下告警规则如果使用GitLab自带监控alert: GitLabDiskCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 85 for: 5m labels: severity: critical annotations: summary: GitLab 磁盘空间不足 (instance {{ $labels.instance }}) description: 根分区使用率已达 {{ $value }}%5. 高级运维技巧5.1 日志分级管理通过调整日志级别减少无效输出# 在gitlab.rb中设置 gitlab_rails[log_level] info # 默认是debug sidekiq[log_level] warn5.2 临时文件定向将临时文件重定向到独立分区gitlab_rails[shared_path] /mnt/volume-gitlab/shared gitlab_rails[uploads_directory] /mnt/volume-gitlab/uploads5.3 自动清理策略设置定期清理任务crontab# 每天凌晨清理构建缓存 0 2 * * * find /var/opt/gitlab/gitlab-rails/shared/artifacts -type f -mtime 30 -delete6. 故障恢复验证清单操作完成后务必检查所有GitLab服务状态是否正常gitlab-ctl status | grep -v run echo 有服务未启动磁盘空间是否回到安全阈值df -h | awk $6 / {print $5}用户基础功能测试curl -I http://localhost/users/sign_in | grep 200 OK git ls-remote http://localhost/group/project.git HEAD这次故障处理给我最深的体会是GitLab的日志管理需要像对待数据库一样重视。现在我会在每次版本升级后专门检查日志配置并在监控大盘上添加磁盘空间的趋势图表。对于关键业务系统建议额外配置一个独立磁盘分区专门存放日志这样即使日志暴增也不会影响主系统运行。
1. 问题背景与现象分析上周五下午3点我们团队的GitLab实例突然出现响应超时前端页面加载卡在502错误API接口返回504状态码。当时正值代码提交高峰十几个开发团队同时受到影响。通过监控系统快速定位发现服务器根分区使用率已达98%而正常情况下这个数值应该维持在70%以下。这种情况在自建GitLab环境中并不罕见。当磁盘空间不足时GitLab的核心组件特别是Unicorn和Sidekiq会因无法写入临时文件而进入阻塞状态。具体表现为Web界面加载超时超过30秒Git push/pull操作中途失败后台任务如CI/CD流水线卡在pending状态管理员面板无法打开关键提示GitLab对磁盘空间敏感度远高于内存和CPU资源因为它的日志系统、仓库数据和临时文件都需要持续写入磁盘。当可用空间低于5%时服务稳定性会急剧下降。2. 根因诊断与排查路径2.1 快速定位问题源通过SSH登录服务器后我立即执行了以下诊断命令# 查看磁盘空间总体使用情况 df -h # 定位大文件目录按大小降序 du -sh /* | sort -rh | head -10 # 检查GitLab日志目录大小 du -sh /var/log/gitlab/*输出显示/var/log/gitlab目录占用了42GB空间其中sidekiq.log和gitlab-rails/production.log两个文件各超过15GB。这是典型日志轮转配置失效的表现。2.2 日志暴增的深层原因进一步分析日志内容发现# 查看日志高频条目 tail -n 1000 /var/log/gitlab/gitlab-rails/production.log | \ awk {print $8} | sort | uniq -c | sort -nr | head -5输出显示大量Java项目的CI构建日志被完整记录每条记录包含完整的Maven依赖树打印。这是由于项目中的.gitlab-ci.yml错误配置了CI_DEBUG_TRACE: true参数导致构建过程的所有输出都被追加到GitLab主日志。3. 紧急处理方案实施3.1 安全清理日志文件直接删除日志文件可能导致正在运行的进程崩溃。正确的做法是# 清空日志内容但保留文件句柄避免服务重启 truncate -s 0 /var/log/gitlab/sidekiq.log truncate -s 0 /var/log/gitlab/gitlab-rails/production.log # 清理旧的日志归档保留最近7天 find /var/log/gitlab -name *.gz -mtime 7 -exec rm {} \;这个操作立即释放了38GB磁盘空间根分区使用率降至65%。3.2 服务重启的正确姿势单纯执行gitlab-ctl restart可能造成数据不一致。推荐的分步操作# 停止服务优雅关闭 sudo gitlab-ctl stop # 确保所有进程已终止 ps aux | grep gitlab | grep -v grep || echo All stopped # 启动服务完整初始化 sudo gitlab-ctl start # 验证服务状态 sudo gitlab-ctl status | grep -E run|down整个过程耗时约3分钟期间GitLab会短暂不可用建议通过维护页面通知用户。4. 长效预防措施配置4.1 日志轮转策略优化编辑GitLab的日志配置文件/etc/gitlab/gitlab.rblogging[logrotate] { rotate 30, rotate_every day, keep_for 30 days, compress true, delaycompress true, maxsize 100M, minsize 10M }然后执行sudo gitlab-ctl reconfigure使配置生效。这个设置确保单个日志超过100MB立即轮转每天强制轮转一次保留最近30天的日志启用gzip压缩旧日志4.2 磁盘空间监控告警在Prometheus中添加以下告警规则如果使用GitLab自带监控alert: GitLabDiskCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 85 for: 5m labels: severity: critical annotations: summary: GitLab 磁盘空间不足 (instance {{ $labels.instance }}) description: 根分区使用率已达 {{ $value }}%5. 高级运维技巧5.1 日志分级管理通过调整日志级别减少无效输出# 在gitlab.rb中设置 gitlab_rails[log_level] info # 默认是debug sidekiq[log_level] warn5.2 临时文件定向将临时文件重定向到独立分区gitlab_rails[shared_path] /mnt/volume-gitlab/shared gitlab_rails[uploads_directory] /mnt/volume-gitlab/uploads5.3 自动清理策略设置定期清理任务crontab# 每天凌晨清理构建缓存 0 2 * * * find /var/opt/gitlab/gitlab-rails/shared/artifacts -type f -mtime 30 -delete6. 故障恢复验证清单操作完成后务必检查所有GitLab服务状态是否正常gitlab-ctl status | grep -v run echo 有服务未启动磁盘空间是否回到安全阈值df -h | awk $6 / {print $5}用户基础功能测试curl -I http://localhost/users/sign_in | grep 200 OK git ls-remote http://localhost/group/project.git HEAD这次故障处理给我最深的体会是GitLab的日志管理需要像对待数据库一样重视。现在我会在每次版本升级后专门检查日志配置并在监控大盘上添加磁盘空间的趋势图表。对于关键业务系统建议额外配置一个独立磁盘分区专门存放日志这样即使日志暴增也不会影响主系统运行。
