1. 问题现象与初步诊断上周五下午3点我们团队的GitLab实例突然出现响应超时前端页面加载缓慢API接口返回504错误。通过SSH连接到服务器后首先执行了gitlab-ctl status检查服务状态发现所有组件都显示run但实际响应异常。这种表面正常但实际不可用的状态往往预示着资源层面的问题。使用df -h命令查看磁盘空间时发现根分区使用率高达98%。进一步用du -sh /var/log/*排查发现/var/log/gitlab目录占用了47GB空间。这个异常情况直接印证了我们的猜想——磁盘空间耗尽导致系统无法正常写入临时文件和日志进而引发服务异常。关键提示当GitLab出现响应缓慢时建议按网络→服务→资源的顺序排查。很多情况下看似复杂的服务故障根源往往是基础的资源问题。2. 日志清理实战操作2.1 定位日志热点进入/var/log/gitlab目录后使用组合命令快速定位大文件cd /var/log/gitlab sudo du -ah . | sort -rh | head -n 20输出显示最大的几个文件是gitlab-rails/production.log (18GB)gitlab-rails/api_json.log (15GB)nginx/gitlab_access.log (9GB)这些日志文件都是未经轮转的原始日志持续累积导致空间耗尽。特别是Java项目的持续集成日志单日就能产生2-3GB的日志量。2.2 安全清理方案直接删除日志文件可能影响正在运行的服务。推荐的安全操作流程首先清空而非删除日志文件sudo truncate -s 0 /var/log/gitlab/gitlab-rails/production.log sudo truncate -s 0 /var/log/gitlab/gitlab-rails/api_json.log对Nginx访问日志进行归档后清理sudo mv /var/log/gitlab/nginx/gitlab_access.log /var/log/gitlab/nginx/gitlab_access_$(date %Y%m%d).log sudo systemctl reload nginx清理旧的日志归档文件保留最近7天sudo find /var/log/gitlab -name *.log.* -mtime 7 -exec rm -f {} \;3. 服务重启与验证3.1 分阶段重启策略简单的gitlab-ctl restart可能会造成服务中断。推荐采用分阶段重启首先重启核心组件sudo gitlab-ctl restart unicorn sudo gitlab-ctl restart sidekiq然后重启辅助服务sudo gitlab-ctl restart nginx sudo gitlab-ctl restart postgresql最后验证服务状态sudo gitlab-ctl status sudo gitlab-rake gitlab:check SANITIZEtrue3.2 服务健康检查重启后需要验证关键功能通过API检查响应时间time curl -s -H PRIVATE-TOKEN: your_token http://localhost/api/v4/projects /dev/null正常响应时间应小于500ms检查后台任务队列sudo gitlab-rake gitlab:sidekiq:check应显示0 busy queues4. 预防措施与长期方案4.1 配置日志轮转编辑/etc/gitlab/gitlab.rb添加以下配置logging[logrotate] { enable true, rotate 30, dateext true, compress true, maxsize 1G, su root root }然后执行sudo gitlab-ctl reconfigure使配置生效。4.2 磁盘空间监控方案建议部署以下监控措施添加Prometheus告警规则- alert: HighDiskUsage expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 85 for: 5m labels: severity: warning设置日志清理定时任务每周日凌晨3点0 3 * * 0 /usr/bin/find /var/log/gitlab -name *.log.* -mtime 30 -exec rm -f {} \;5. 故障排查速查表现象可能原因检查命令解决方案504 Gateway Timeout磁盘空间不足df -h清理日志文件502 Bad GatewayUnicorn崩溃sudo gitlab-ctl tail unicorn重启unicorn服务登录失败Redis连接问题sudo gitlab-rake cache:clear重启redis服务项目无法加载PostgreSQL连接池满sudo gitlab-psql -c SHOW max_connections;调整连接池大小6. 实战经验分享在实际运维中我们发现几个关键点日志文件增长速度往往被低估特别是CI/CD流水线密集时日志量可能呈指数增长truncate比rm更安全可以避免文件描述符丢失的问题重启服务时注意观察/var/log/gitlab/gitlab-rails/application.log中的启动错误对于大型实例建议将日志目录挂载到独立分区避免影响系统运行一个实用的调试技巧当服务异常但日志不明显时可以临时提高日志级别sudo gitlab-ctl stop sudo echo production.log_level :debug /etc/gitlab/gitlab.rb sudo gitlab-ctl reconfigure sudo gitlab-ctl start
1. 问题现象与初步诊断上周五下午3点我们团队的GitLab实例突然出现响应超时前端页面加载缓慢API接口返回504错误。通过SSH连接到服务器后首先执行了gitlab-ctl status检查服务状态发现所有组件都显示run但实际响应异常。这种表面正常但实际不可用的状态往往预示着资源层面的问题。使用df -h命令查看磁盘空间时发现根分区使用率高达98%。进一步用du -sh /var/log/*排查发现/var/log/gitlab目录占用了47GB空间。这个异常情况直接印证了我们的猜想——磁盘空间耗尽导致系统无法正常写入临时文件和日志进而引发服务异常。关键提示当GitLab出现响应缓慢时建议按网络→服务→资源的顺序排查。很多情况下看似复杂的服务故障根源往往是基础的资源问题。2. 日志清理实战操作2.1 定位日志热点进入/var/log/gitlab目录后使用组合命令快速定位大文件cd /var/log/gitlab sudo du -ah . | sort -rh | head -n 20输出显示最大的几个文件是gitlab-rails/production.log (18GB)gitlab-rails/api_json.log (15GB)nginx/gitlab_access.log (9GB)这些日志文件都是未经轮转的原始日志持续累积导致空间耗尽。特别是Java项目的持续集成日志单日就能产生2-3GB的日志量。2.2 安全清理方案直接删除日志文件可能影响正在运行的服务。推荐的安全操作流程首先清空而非删除日志文件sudo truncate -s 0 /var/log/gitlab/gitlab-rails/production.log sudo truncate -s 0 /var/log/gitlab/gitlab-rails/api_json.log对Nginx访问日志进行归档后清理sudo mv /var/log/gitlab/nginx/gitlab_access.log /var/log/gitlab/nginx/gitlab_access_$(date %Y%m%d).log sudo systemctl reload nginx清理旧的日志归档文件保留最近7天sudo find /var/log/gitlab -name *.log.* -mtime 7 -exec rm -f {} \;3. 服务重启与验证3.1 分阶段重启策略简单的gitlab-ctl restart可能会造成服务中断。推荐采用分阶段重启首先重启核心组件sudo gitlab-ctl restart unicorn sudo gitlab-ctl restart sidekiq然后重启辅助服务sudo gitlab-ctl restart nginx sudo gitlab-ctl restart postgresql最后验证服务状态sudo gitlab-ctl status sudo gitlab-rake gitlab:check SANITIZEtrue3.2 服务健康检查重启后需要验证关键功能通过API检查响应时间time curl -s -H PRIVATE-TOKEN: your_token http://localhost/api/v4/projects /dev/null正常响应时间应小于500ms检查后台任务队列sudo gitlab-rake gitlab:sidekiq:check应显示0 busy queues4. 预防措施与长期方案4.1 配置日志轮转编辑/etc/gitlab/gitlab.rb添加以下配置logging[logrotate] { enable true, rotate 30, dateext true, compress true, maxsize 1G, su root root }然后执行sudo gitlab-ctl reconfigure使配置生效。4.2 磁盘空间监控方案建议部署以下监控措施添加Prometheus告警规则- alert: HighDiskUsage expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 85 for: 5m labels: severity: warning设置日志清理定时任务每周日凌晨3点0 3 * * 0 /usr/bin/find /var/log/gitlab -name *.log.* -mtime 30 -exec rm -f {} \;5. 故障排查速查表现象可能原因检查命令解决方案504 Gateway Timeout磁盘空间不足df -h清理日志文件502 Bad GatewayUnicorn崩溃sudo gitlab-ctl tail unicorn重启unicorn服务登录失败Redis连接问题sudo gitlab-rake cache:clear重启redis服务项目无法加载PostgreSQL连接池满sudo gitlab-psql -c SHOW max_connections;调整连接池大小6. 实战经验分享在实际运维中我们发现几个关键点日志文件增长速度往往被低估特别是CI/CD流水线密集时日志量可能呈指数增长truncate比rm更安全可以避免文件描述符丢失的问题重启服务时注意观察/var/log/gitlab/gitlab-rails/application.log中的启动错误对于大型实例建议将日志目录挂载到独立分区避免影响系统运行一个实用的调试技巧当服务异常但日志不明显时可以临时提高日志级别sudo gitlab-ctl stop sudo echo production.log_level :debug /etc/gitlab/gitlab.rb sudo gitlab-ctl reconfigure sudo gitlab-ctl start
