温馨提示×

Linux系统里GitLab怎样进行故障排查

小樊
69
2025-09-23 06:23:45
栏目: 智能运维

1. 检查GitLab服务状态
使用gitlab-ctl status命令查看GitLab各组件(如Rails、Nginx、Sidekiq、PostgreSQL等)的运行状态。若组件显示为“down”或“unhealthy”,需进一步排查对应组件的日志或尝试重启服务(gitlab-ctl restart <component_name>)。

2. 查看与分析日志文件
GitLab的日志集中存储在/var/log/gitlab目录下,不同组件的日志对应不同文件:

  • 应用层日志/var/log/gitlab/gitlab-rails/production.log(记录用户操作、请求响应等业务日志)、production_json.log(JSON格式的详细错误信息,便于程序化分析);
  • Nginx日志/var/log/gitlab/nginx/gitlab_access.log(访问日志)、gitlab_error.log(Nginx错误日志,如403/502等HTTP错误);
  • Sidekiq日志/var/log/gitlab/sidekiq.log(后台作业执行日志,如CI/CD流水线、邮件发送等);
  • Shell与Unicorn日志/var/log/gitlab/gitlab-shell/gitlab-shell.log(SSH操作日志)、/var/log/gitlab/unicorn/unicorn_stdout.log(Unicorn应用服务器日志)。

常用日志分析命令:

  • gitlab-ctl tail:实时查看所有组件的日志输出(类似tail -f);
  • tail -f /var/log/gitlab/gitlab-rails/production.log:实时跟踪应用层日志;
  • grep -i "error\|failed" /var/log/gitlab/gitlab-rails/production.log:过滤出包含“error”或“failed”的错误信息;
  • less /var/log/gitlab/nginx/gitlab_error.log:分页查看Nginx错误日志。

3. 检查GitLab配置文件
GitLab的主配置文件为/etc/gitlab/gitlab.rb,需重点检查以下配置项:

  • external_url:确保GitLab的访问URL正确(如http://your-server-ip或带域名的HTTPS地址);
  • ssl_certificate/ssl_certificate_key:若启用HTTPS,需确认证书路径正确且文件存在;
  • gitlab_rails['gitlab_shell_ssh_port']:若修改了SSH端口,需同步更新此配置;
  • unicorn['port']/sidekiq['port']:确保端口未被其他服务占用。

修改配置文件后,需执行gitlab-ctl reconfigure重新应用配置(此命令会自动重启受影响的组件),再通过gitlab-ctl restart重启GitLab服务。

4. 监控系统资源使用情况
GitLab运行需要足够的CPU、内存和磁盘空间,资源不足会导致服务缓慢或崩溃。使用以下命令检查资源状态:

  • top/htop:查看CPU和内存占用率,识别高消耗进程(如Sidekiq、Unicorn);
  • free -m:查看内存使用情况(重点关注“available”内存,避免内存耗尽触发OOM Killer);
  • df -h:查看磁盘空间(尤其是/var/opt/gitlab目录,存储Git仓库、数据库文件等,建议保留至少20%空闲空间);
  • vmstat 1 5:查看系统整体资源使用情况(如CPU上下文切换、内存交换、IO等待等)。

5. 排查常见特定错误

  • 502 Bad Gateway:通常因Nginx与Unicorn之间的通信问题导致。需检查Unicorn是否运行(gitlab-ctl status unicorn),查看Unicorn日志(/var/log/gitlab/unicorn/unicorn_stderr.log)中的错误信息(如端口冲突、内存不足);
  • 403 Forbidden:权限问题,可能是用户无权访问项目或目录。检查项目成员权限(通过GitLab Web界面“Project → Members”),或文件系统权限(确保/var/opt/gitlab/git-data/repositories目录权限为git:git);
  • CI/CD构建失败:查看Sidekiq日志(/var/log/gitlab/sidekiq.log)和项目流水线日志(通过GitLab Web界面“CI/CD → Pipelines”),常见原因包括依赖未安装(如nodejsdocker)、环境变量未配置(如CI_SECRET)、镜像拉取失败(如Docker Hub限速);
  • Runner离线:检查Runner服务状态(gitlab-runner status),查看Runner日志(/var/log/gitlab-runner/gitlab-runner.log),确保Token有效(gitlab-runner verify)且能访问GitLab实例;
  • 磁盘空间不足:清理过期流水线缓存(gitlab-rake gitlab:cleanup:orphan_job_artifacts)、构建产物(gitlab-rake gitlab:cleanup:builds)和Docker Registry未使用的镜像(docker system prune -a)。

6. 使用监控与报警工具
集成监控工具实时跟踪GitLab的运行状态,及时发现异常:

  • Prometheus + Grafana:通过GitLab自带的prometheus组件(默认启用)收集性能指标(如请求延迟、CPU使用率、数据库连接数),并在Grafana中创建仪表盘展示。可设置告警规则(如CPU使用率超过80%、磁盘空间低于10%),通过邮件、Slack等方式通知管理员;
  • Logrotate:GitLab内置日志轮转工具,可通过/etc/gitlab/gitlab.rb自定义日志切割策略(如保留7天日志、压缩旧日志),避免日志文件过大占用磁盘空间(修改后需执行gitlab-ctl reconfigure生效)。

7. 备份与恢复
定期备份GitLab数据是故障恢复的关键:

  • 备份命令:使用gitlab-backup create命令创建全量备份(默认存储在/var/opt/gitlab/backups目录),可通过--backup-name指定备份名称(如gitlab-backup create STRATEGY=copy);
  • 备份验证:定期测试备份文件的完整性(如检查备份文件大小、尝试解压);
  • 恢复流程:若GitLab出现严重故障(如数据损坏),可停止GitLab服务(gitlab-ctl stop),删除原有数据目录(rm -rf /var/opt/gitlab/*),然后恢复备份(gitlab-backup restore BACKUP=timestamp_of_backup),最后重启服务(gitlab-ctl start)。恢复后建议执行gitlab-rake gitlab:check SANITIZE=true检查系统状态。

0