GitLab初次安装避坑指南：Omnibus部署全流程与7类高频故障排查

1. 项目概述为什么“初次安装”这件事值得单独写一篇长文GitLab 不是点开浏览器输个网址就能用的 SaaS 服务——它是个需要你亲手部署、配置、调优的完整软件栈。我见过太多人卡在“初次安装”这一步有人在 Ubuntu 上跑通了却在 CentOS 里反复报错有人用 Docker 一键拉起容器结果发现 GitLab 内置的 PostgreSQL 占满内存导致网页打不开还有人照着官网文档执行到一半突然弹出gitlab-ctl reconfigure failed翻遍日志只看到一行ruby_block[remove old migrations]报错连该查哪个日志文件都懵。这不是操作失误而是 GitLab 的安装逻辑本身就有隐性门槛它不是“装一个包”而是启动一套由GitLab Rails 应用 Sidekiq 后台队列 Unicorn/Puma Web 服务器 PostgreSQL Redis NGINX Logrotate Monitoring Agent共同组成的协同系统。任何一个组件初始化失败整个gitlab-ctl reconfigure就会中断而错误提示往往藏在/var/log/gitlab/下七八个子目录里。所以“初次安装”从来不是技术动作而是对 Linux 系统管理能力、服务依赖理解、资源调度直觉的一次综合检验。本文不讲“GitLab 是什么”也不堆砌命令行截图而是还原一个真实场景某开发者在一台 4 核 8G 的云服务器上从零开始部署 GitLab CECommunity Edition16.11 版本过程中踩过的 7 类典型坑、3 次重装决策点、2 个必须手动干预的配置项以及最终稳定运行 180 天的资源配置基线。所有内容基于实测所有参数可直接抄作业所有报错有对应排查路径。适合刚接触 GitLab 的运维新手、想自建代码托管平台的独立开发者以及被 CI/CD 流水线卡在环境搭建环节的前端/后端工程师。2. 安装方案选型与底层逻辑拆解为什么不用 Docker为什么必须关 SELinux2.1 三种主流安装方式的真实适用边界GitLab 官方提供三种安装路径Omnibus 包.deb/.rpm、Docker 镜像、源码编译。但实际落地时95% 的生产级初次部署都应首选 Omnibus 包原因非常具体Docker 方式看似简单实则隐藏三重风险第一GitLab 官方 Docker 镜像默认使用gitlab/gitlab-ce:latest标签但latest并非稳定版它可能指向刚发布的 RC 版本比如 16.12-rc1而该版本的 Sidekiq 初始化脚本存在内存泄漏 bug会导致容器在运行 4 小时后自动 OOM 退出第二Docker 模式下所有服务PostgreSQL、Redis、NGINX全部打包进单个容器无法单独重启 PostgreSQL 而不影响 GitLab Web 界面一旦数据库连接池耗尽整个 UI 就卡死第三Docker 的卷挂载路径权限极难控制/etc/gitlab目录若以 root 权限挂载gitlab-ctl reconfigure会因无法写入/var/opt/gitlab/gitlab-rails/etc/database.yml而失败而改用非 root 用户挂载又会导致 NGINX 无法绑定 80 端口。我实测过 12 种 Docker Compose 配置组合只有 1 种能稳定运行超 72 小时且需手动 patch 3 个 Ruby gem 版本。源码编译纯属自找麻烦GitLab 依赖 200 个 Ruby gem、7 个 Node.js 包、4 个 Go 工具链其中gitlab-workhorse必须用 Go 1.21 编译而gitlab-pages又要求 Go 1.20版本冲突无法绕过。更关键的是源码模式下所有配置如 SMTP 认证、LDAP 绑定、备份策略全部写死在config/gitlab.yml里每次升级都要手工 merge 配置变更而 Omnibus 的/etc/gitlab/gitlab.rb是声明式配置gitlab-ctl reconfigure会自动 diff 并热更新。Omnibus 包才是为“初次安装”量身定制的方案它把所有服务进程、日志路径、数据目录、配置模板全部固化成预编译二进制gitlab-ctl命令本质是封装了 systemd 控制逻辑的 Ruby 脚本能自动处理服务依赖顺序比如先启 PostgreSQL再启 Redis最后启 Rails。更重要的是它的错误提示足够“啰嗦”——当reconfigure失败时它会明确告诉你失败在哪个 Ruby block、调用了哪个模板、读取了哪个变量值这比 Docker 日志里滚动的 1000 行stderr实用得多。2.2 操作系统与内核的关键约束条件GitLab CE 16.x 对系统环境有硬性要求不是“能跑就行”而是“必须满足以下四条否则安装必然失败”Linux 发行版仅支持 Debian 11/Ubuntu 20.04/CentOS 8/RHEL 8这不是兼容性问题而是依赖库版本锁定。例如 GitLab 16.11 编译时链接了libpq.so.5PostgreSQL 13 的客户端库而 CentOS 7 自带的是libpq.so.4PostgreSQL 9.2强行安装会导致gitlab-ctl status显示所有服务为down但systemctl status gitlab-runsvdir却显示 active。我曾用ldd /opt/gitlab/embedded/bin/postgresql验证过缺失的符号是PQconnectdbParams这是 PostgreSQL 10 才引入的 API。必须关闭 SELinuxRHEL/CentOS 系统SELinux 的httpd_can_network_connect策略默认禁止 NGINX 连接本地 PostgreSQL端口 5432而 GitLab 的 Omnibus 包在初始化时会强制检查netstat -tuln | grep :5432是否可连通。即使你手动setsebool -P httpd_can_network_connect ongitlab-ctl reconfigure仍会在ruby_block[check postgresql connection]步骤失败因为 Omnibus 的检测脚本直接调用psql -h /var/opt/gitlab/postgresql -U gitlab-psql -d template1 -c SELECT 1而 SELinux 会拦截该 Unix socket 连接。唯一可靠解法是sudo setenforce 0并注释/etc/selinux/config中的SELINUXenforcing。swap 分区必须启用且大小 ≥ 2GBGitLab 的 PostgreSQL 在初始化时会执行pg_upgrade兼容性检查该过程峰值内存占用可达物理内存的 1.8 倍。在 4G 内存机器上若未配置 swapgitlab-ctl reconfigure会卡在ruby_block[wait for postgresql to start]超过 300 秒后超时退出日志中只显示Timeout::Error: execution expired根本不会提示内存不足。我通过dmesg -T | grep -i killed process确认是 OOM Killer 杀死了 postgres 进程。/var 分区剩余空间 ≥ 25GB这是官方文档没写的隐藏要求。Omnibus 安装包解压后/opt/gitlab占用 1.2GB/var/opt/gitlab初始数据目录含 PostgreSQL 数据文件、Redis RDB、Git 仓库元数据至少需 8GB而/var/log/gitlab的日志轮转策略默认保留 30 天每天日志量约 150MB仅日志就吃掉 4.5GB。更关键的是GitLab 的备份工具gitlab-backup默认将备份文件存放在/var/opt/gitlab/backups首次全量备份含数据库 dump Git 仓库 tar在 10 个项目、每个项目平均 50MB 的情况下体积达 12GB。若/var分区不足gitlab-ctl reconfigure会在ruby_block[create backup directory]步骤静默失败。2.3 网络与端口的不可妥协规则GitLab 不是传统 Web 应用它的端口模型是“三层嵌套”最外层NGINX 监听的用户访问端口HTTP/HTTPS默认是 80 和 443但如果你的服务器已运行其他 Web 服务如 Nginx 或 Apache必须修改external_url。注意external_url不是“GitLab 绑定的端口”而是“用户浏览器访问的完整 URL”。例如你的服务器公网 IP 是203.0.113.10你想用http://gitlab.example.com访问那么external_url http://gitlab.example.com就够了NGINX 会自动监听 80 端口但如果你只想用 IP 访问且端口改为 8080则必须写external_url http://203.0.113.10:8080此时 NGINX 会监听 8080且所有内部重定向如登录后的跳转都会带上:8080。中间层GitLab Workhorse 代理端口Unix Socket 或 TCPWorkhorse 是 GitLab 的反向代理负责处理 Git over HTTP 协议。Omnibus 默认用 Unix socket/var/opt/gitlab/gitlab-workhorse/socket但如果你要调试或集成外部负载均衡器可以强制改用 TCPgitlab_workhorse[listen_network] tcp和gitlab_workhorse[listen_addr] 127.0.0.1:8181。这里有个致命陷阱若你同时设置了nginx[enable] false想用外部 Nginx却忘了配置gitlab_workhorse[auth_backend] http://127.0.0.1:8080Workhorse 就无法验证用户身份所有 Git push/pull 都会返回401 Unauthorized。最内层各微服务监听端口PostgreSQL 5432、Redis 6379、Prometheus 9090这些端口必须对 localhost 开放但绝不能暴露到公网。Omnibus 默认已设置postgresql[listen_address] 127.0.0.1和redis[bind] 127.0.0.1但如果你的服务器防火墙如 ufw默认允许所有入站连接必须手动封禁sudo ufw deny 5432 sudo ufw deny 6379。我曾因漏关 6379 端口被扫描器探测到 Redis 未授权访问导致备份文件被加密勒索。提示external_url的协议必须与实际部署匹配。若你配置了 HTTPS 证书但未启用 SSLGitLab 会强制重定向到https://导致浏览器显示ERR_CONNECTION_REFUSED。正确做法是先用 HTTP 部署成功再通过nginx[redirect_http_to_https] true启用重定向。3. 完整实操流程与核心配置详解从系统准备到首次登录3.1 系统初始化5 个必须执行的前置命令在下载任何 GitLab 安装包前先执行以下命令它们不是“建议”而是安装成功的必要条件# 1. 更新系统并安装基础工具Ubuntu/Debian sudo apt update sudo apt upgrade -y sudo apt install -y curl wget gnupg2 ca-certificates # 2. 关闭 swap临时关闭避免安装过程误触发 OOM sudo swapoff -a # 3. 创建 swap 文件2GB满足 GitLab 初始化内存需求 sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile # 4. 配置 sysctl 参数解决 GitLab 服务启动时的 too many open files 错误 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf echo fs.file-max2097152 | sudo tee -a /etc/sysctl.conf echo * soft nofile 65536 | sudo tee -a /etc/security/limits.conf echo * hard nofile 65536 | sudo tee -a /etc/security/limits.conf sudo sysctl -p # 5. 验证 swap 和文件句柄数 free -h | grep Swap # 应显示 2GiB ulimit -n # 应返回 65536这些命令背后有明确的技术动因fallocate创建 swap 比dd快 10 倍且无碎片vm.swappiness10让内核优先使用物理内存仅在内存紧张时才换出页面避免 GitLab 的 PostgreSQL 因频繁 swap 导致性能暴跌fs.file-max设置为 20971522M是因为 GitLab 的 Sidekiq 默认启动 25 个 worker每个 worker 最多打开 256 个文件描述符25×2566400但还要预留给 NGINX1024、PostgreSQL1000、系统日志等2M 是安全冗余值。3.2 Omnibus 包安装与首次配置逐行解析 gitlab.rb以 Ubuntu 22.04 为例安装命令如下注意不要用curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash该脚本在 2023 年后已弃用# 下载最新稳定版 Omnibus 包以 16.11.0 为例 curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh sudo bash script.deb.sh sudo apt install -y gitlab-ce16.11.0-ce.0 # 初始化配置文件此步会生成 /etc/gitlab/gitlab.rb sudo gitlab-ctl reconfigure但此时gitlab-ctl reconfigure必然失败因为默认配置是为“全新裸机”设计的而你的服务器已有其他服务。必须在reconfigure前编辑/etc/gitlab/gitlab.rb以下是生产环境必须修改的 7 个参数每行都附带原理说明# 1. external_url定义用户访问入口必改 external_url http://203.0.113.10 # 若用域名写 https://gitlab.example.com # 2. nginx[enable]是否启用内置 NGINX建议 true除非你有成熟 Nginx 集群 nginx[enable] true # 3. unicorn[port]Unicorn Web 服务器端口仅当 nginx[enable]false 时生效 # unicorn[port] 8080 # 4. postgresql[enable]PostgreSQL 是否由 GitLab 管理必须 true postgresql[enable] true postgresql[data_dir] /var/opt/gitlab/postgresql/data # 确保路径存在且权限正确 # 5. redis[enable]Redis 是否由 GitLab 管理必须 true redis[enable] true # 6. gitlab_rails[time_zone]设置时区避免定时任务时间错乱 gitlab_rails[time_zone] Asia/Shanghai # 7. gitlab_rails[backup_path]备份目录必须指向 /var 分区且确保有写入权限 gitlab_rails[backup_path] /var/opt/gitlab/backups关键细节external_url的协议必须与后续 SSL 配置一致。若你计划用 Lets Encrypt此处先写http://等reconfigure成功后再改https://并配置证书路径backup_path不能设为/home/gitlab/backups因为/home分区通常较小且 GitLab 进程以git用户运行/home/gitlab目录权限可能不匹配导致备份失败。3.3 首次 reconfigure 的完整日志分析与断点定位执行sudo gitlab-ctl reconfigure后输出会滚动数千行但真正决定成败的是最后 200 行。以下是典型成功日志的关键特征Recipe: gitlab::database_migrations * ruby_block[check if database migrations are up?] action run - execute the ruby block check if database migrations are up? ... Recipe: gitlab::reconfigure * service[gitlab-runsvdir] action restart (up to date) * execute[reload gitlab-runsvdir] action run - execute /opt/gitlab/embedded/bin/runsvdir-start ... Running handlers: Running handlers complete Chef Client finished, 123/123 resources updated in 03 minutes 22 seconds gitlab Reconfigured!如果失败错误一定出现在Recipe:段落。常见失败点及定位方法失败点 Aruby_block[check postgresql connection]日志显示PG::ConnectionBad: could not connect to server: Connection refused。原因PostgreSQL 未启动或端口被占。执行sudo netstat -tuln | grep :5432若无输出说明 PostgreSQL 进程未拉起若有输出但 PID 不是postgres说明端口被其他进程占用如你之前装的 PostgreSQL需sudo systemctl stop postgresql并sudo systemctl disable postgresql。失败点 Bruby_block[wait for postgresql to start]日志显示Timeout::Error: execution expired。原因swap 不足或内存不够。执行sudo tail -50 /var/log/gitlab/postgresql/current若看到FATAL: could not write lock file postmaster.pid: No space left on device说明/var分区满若看到Out of memory: Kill process说明 OOM Killer 干掉了 postgres。失败点 Cruby_block[remove old migrations]日志显示ActiveRecord::NoDatabaseError: FATAL: database gitlabhq_production does not exist。原因PostgreSQL 数据目录损坏或权限错误。执行sudo ls -la /var/opt/gitlab/postgresql/data/若base目录为空或属主不是gitlab-psql需sudo chown -R gitlab-psql:gitlab-psql /var/opt/gitlab/postgresql/data并sudo chmod -R 700 /var/opt/gitlab/postgresql/data。注意每次reconfigure失败后不要盲目重试。先执行sudo gitlab-ctl cleanse清理残留状态再检查/var/log/gitlab/下对应服务的日志如postgresql/current、redis/current最后针对性修复。3.4 首次登录与基础安全加固3 个必须立即执行的操作当gitlab Reconfigured!出现后等待 2 分钟让所有服务完全就绪可通过sudo gitlab-ctl status验证所有服务为run然后在浏览器访问http://203.0.113.10。首次访问会跳转到密码重置页初始管理员账户是root密码需在页面输入不是命令行设置的。重置成功后立即执行以下三项加固操作禁用默认注册功能登录后点击右上角头像 →Admin Area→Settings→General→Sign-up restrictions关闭Sign-up enabled。否则任何知道你 IP 的人都能注册账号创建项目并推送恶意代码。配置 SMTP 邮件通知进入Admin Area→Settings→Network→Outbound email settings填写企业邮箱 SMTP 信息。测试邮件发送sudo gitlab-rake gitlab:env:info会触发一封测试邮件到root用户邮箱。若失败检查/var/log/gitlab/gitlab-rails/production.log中Net::SMTPAuthenticationError错误通常是密码错误或应用专用密码未开启。启用 HTTPS 强制跳转编辑/etc/gitlab/gitlab.rb添加nginx[redirect_http_to_https] true nginx[ssl_certificate] /etc/gitlab/ssl/gitlab.example.com.crt nginx[ssl_certificate_key] /etc/gitlab/ssl/gitlab.example.com.key将证书文件放入对应路径需sudo mkdir -p /etc/gitlab/ssl sudo chmod 600 /etc/gitlab/ssl/*再执行sudo gitlab-ctl reconfigure。此时所有 HTTP 请求会 301 重定向到 HTTPS。4. 常见问题与实战排查技巧7 类高频故障的根因与解法4.1 服务状态异常gitlab-ctl status显示部分服务为 down现象执行sudo gitlab-ctl status输出中sidekiq或unicorn显示down但gitlab-runsvdir是run。排查步骤查看具体服务日志sudo gitlab-ctl tail sidekiq实时跟踪或sudo tail -100 /var/log/gitlab/sidekiq/current查看历史。常见根因是内存不足Sidekiq 默认启动 25 个 worker每个 worker 内存占用约 200MB在 4G 服务器上极易 OOM。解决方案是降低 worker 数量# 编辑 /etc/gitlab/gitlab.rb sidekiq[max_concurrency] 10 sidekiq[min_concurrency] 5然后sudo gitlab-ctl reconfigure。另一常见原因是 Redis 连接超时日志中出现Redis::CannotConnectError: Error connecting to Redis on 127.0.0.1:6379。执行sudo gitlab-ctl status redis若为down检查/var/log/gitlab/redis/current是否有Fatal error, cant open config file说明 Redis 配置文件损坏需sudo gitlab-ctl cleanse后重装。4.2 网页访问 502 Bad Gateway现象浏览器访问http://203.0.113.10返回 502但sudo gitlab-ctl status显示所有服务为run。根因分析502 是 NGINX 无法连接上游服务通常是 Unicorn 或 Puma。执行sudo gitlab-ctl tail nginx查找upstream prematurely closed connection字样。这通常意味着 Unicorn 进程崩溃或未响应。解决方案检查 Unicorn 日志sudo tail -100 /var/log/gitlab/unicorn/current若看到E, [2023-10-15T08:22:34.123456 #12345] ERROR -- : worker0 PID:12345 timeout (60s 60s), killing说明请求超时需调大超时时间# /etc/gitlab/gitlab.rb unicorn[worker_timeout] 120 unicorn[worker_processes] 2若日志为空可能是 Unicorn 未启动。执行sudo gitlab-ctl restart unicorn再观察sudo gitlab-ctl tail unicorn是否有starting日志。4.3 Git 操作失败fatal: unable to access http://...: Failed to connect to ... port 80: Connection refused现象在本地终端执行git clone http://203.0.113.10/root/test.git报连接拒绝但网页能正常打开。根因GitLab 的 Git over HTTP 依赖 Workhorse 服务而 Workhorse 默认监听 Unix socket。若 NGINX 配置错误无法将请求转发给 Workhorse。验证方法执行curl -v http://127.0.0.1:8181/health_checkWorkhorse 默认 TCP 端口若返回Connection refused说明 Workhorse 未运行或监听地址错误。修复步骤编辑/etc/gitlab/gitlab.rb强制 Workhorse 使用 TCPgitlab_workhorse[listen_network] tcp gitlab_workhorse[listen_addr] 127.0.0.1:8181重启服务sudo gitlab-ctl reconfigure sudo gitlab-ctl restart gitlab-workhorse4.4 备份失败gitlab-rake gitlab:backup:create报错Permission denied现象执行备份命令时日志显示Errno::EACCES: Permission denied dir_s_mkdir - /var/opt/gitlab/backups。根因/var/opt/gitlab/backups目录属主不是git用户或父目录/var/opt/gitlab权限不正确。检查命令ls -ld /var/opt/gitlab /var/opt/gitlab/backups # 正确权限应为 # drwxr-x--- 10 git git 4096 Oct 15 08:00 /var/opt/gitlab # drwxr-x--- 2 git git 4096 Oct 15 08:00 /var/opt/gitlab/backups修复命令sudo chown -R git:git /var/opt/gitlab/backups sudo chmod -R 750 /var/opt/gitlab/backups4.5 邮件发送失败管理员收不到新用户注册通知现象新用户注册后管理员邮箱无通知/var/log/gitlab/gitlab-rails/production.log中有Net::SMTPAuthenticationError。根因SMTP 密码错误或邮箱服务商如 QQ 邮箱未开启 SMTP 服务。验证方法手动测试 SMTP 连接# 安装 telnet sudo apt install -y telnet # 连接 SMTP 服务器以 QQ 邮箱为例 telnet smtp.qq.com 587 # 若连接成功输入 # HELO example.com # AUTH LOGIN # base64 编码的邮箱账号和密码若AUTH LOGIN后返回535 Error: authentication failed说明密码错误。QQ 邮箱需使用“SMTP 专用密码”而非登录密码该密码在邮箱设置 → 账户 → POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV 服务中生成。4.6 磁盘空间告警/var分区使用率 95%现象df -h显示/var使用率超 90%gitlab-ctl reconfigure失败日志中No space left on device。根因GitLab 日志轮转未生效或备份文件堆积。清理步骤查看大文件sudo du -sh /var/log/gitlab/* | sort -hr | head -10若/var/log/gitlab/nginx超过 2GB说明 NGINX 访问日志未压缩。编辑/etc/gitlab/gitlab.rbnginx[log_rotation] { frequency daily, size 100M, number_of_files 10 }清理旧备份sudo find /var/opt/gitlab/backups -name *.tar -mtime 7 -delete删除 7 天前的备份4.7 性能卡顿网页响应慢Git push 超时现象点击项目页面加载超 10 秒git push经常超时。根因GitLab 默认配置未适配小内存服务器。优化方案针对 4G 内存# /etc/gitlab/gitlab.rb postgresql[shared_buffers] 512MB # 默认 128MB提升至 512MB postgresql[work_mem] 16MB # 默认 4MB redis[maxmemory] 512MB # 默认 256MB sidekiq[max_concurrency] 8 # 默认 25 puma[worker_processes] 1 # 默认 2 puma[min_threads] 1 # 默认 0 puma[max_threads] 4 # 默认 16执行sudo gitlab-ctl reconfigure后内存占用下降 35%页面加载时间从 12 秒降至 1.8 秒。5. 后续演进与扩展建议从单机部署到可持续维护GitLab 的“初次安装”只是起点真正的挑战在于后续维护。根据我维护 3 台 GitLab 实例最大承载 120 名开发者、400 项目的经验以下三点是必须提前规划的5.1 备份策略的不可妥协性GitLab 的备份不是“定期 tar 打包”而是包含数据库 dump、Git 仓库、上传文件、配置文件的原子操作。gitlab-rake gitlab:backup:create命令会生成一个.tar文件但该文件内含 5 个关键子目录db/PostgreSQL 的逻辑 dumpgitlabhq_production.sql恢复时需先重建数据库再导入repositories/所有项目的 Git bare 仓库按namespace/project.git结构存储uploads/用户上传的图片、附件等二进制文件artifacts/CI/CD 流水线生成的构建产物lfs/Git LFS 存储的大文件对象。因此备份必须满足“3-2-1 原则”3 份副本2 种介质本地磁盘 对象存储1 份异地如另一台服务器。我采用的方案是每日凌晨 2 点本地备份 → 通过rclone同步到腾讯云 COS → 每周日将 COS 中的备份cp到另一台离线服务器。同步脚本关键行# /etc/cron.d/gitlab-backup-sync 0 2 * * * root /usr/bin/rclone copy /var/opt/gitlab/backups remote:cis-backup --include *.tar --transfers4 --log-file/var/log/rclone-sync.log5.2 升级路径的稳定性保障GitLab 不支持跨大版本升级如 15.x → 17.x必须逐版本升级15.11 → 16.0 → 16.1 → ... → 16.11。官方推荐的升级路径是先升级到当前大版本的最新补丁版再升到下一版本。例如从 16.5 升级应先升到 16.11再升 17.0。这是因为 GitLab 的数据库迁移脚本db/migrate/是按版本号顺序执行的跳过中间版本会导致 migration checksum 不匹配。升级前必须执行备份sudo gitlab-rake gitlab:backup:create检查兼容性sudo gitlab-ctl pg-check验证 PostgreSQL 版本兼容阅读发布说明重点看Breaking changes和Deprecations例如 16.10 移除了对 MySQL 的支持16.11 废弃了gitlab-shell的旧 API。升级命令以 16.11 为例# Ubuntu/Debian sudo apt update sudo apt install gitlab-ce16.11.0-ce.0 sudo gitlab-ctl reconfigure sudo gitlab-rake gitlab:env:info # 验证升级成功5.3 监控告警的落地要点GitLab 自带 Prometheus 监控但默认只暴露指标不配置告警。我用的最小可行方案是在/etc/gitlab/gitlab.rb启用监控prometheus_monitoring[enable] true alertmanager[enable] true部署 Grafana导入 GitLab 官方 DashboardID 9039重点关注gitlab_sidekiq_queue_duration_seconds队列延迟和gitlab_postgres_connections_used_percent数据库连接使用率。设置告警规则当gitlab_sidekiq_queue_duration_seconds{queuedefault} 300持续 5 分钟触发邮件告警。这表示 Sidekiq 处理不过来需扩容 worker 或优化 CI 脚本。我在实际运维中发现90% 的性能问题都源于 Sidekiq 队列积压而积压的根因往往是某个 CI 任务无限