温馨提示×

GitLab在Linux上的监控方法

小樊
31
2025-11-28 20:39:41
栏目: 智能运维

Linux 上监控 GitLab 的实用方案

一 监控体系总览

  • 建议采用“系统层 + GitLab 应用层 + 可视化告警”三层方案:系统层用 Node Exporter 采集主机指标,GitLab 应用层开启 Rails/Workhorse/Runner 指标端点,使用 Prometheus 抓取并存储,配合 Grafana 可视化,最后由 Alertmanager 或 Grafana 告警通知到 邮件/Slack/企业微信 等渠道。

二 快速落地步骤

  • 启用 GitLab 指标
    • 编辑 /etc/gitlab/gitlab.rb,开启监控相关配置并应用:
      • gitlab_rails[‘gitlab_metrics_enabled’] = true
      • gitlab_runner[‘metrics_enabled’] = true
      • global[‘monitoring_enabled’] = true
    • 执行:sudo gitlab-ctl reconfigure
    • 在管理区域启用自监控:进入 Settings → Metrics and profiling → Self monitoring,生成监控项目用于可视化与告警配置。
  • 部署 Node Exporter
    • 在 GitLab 服务器安装 Node Exporter,暴露 9100 端口,供 Prometheus 抓取主机 CPU、内存、磁盘、网络等指标。
  • 配置 Prometheus 抓取
    • prometheus.yml 增加作业,示例:
      • job_name: ‘gitlab’ static_configs:
        • targets: [‘your_gitlab_server_address:9100’, ‘your_gitlab_server_address:8080’] # Node Exporter 与 GitLab 指标端口
  • 配置 Grafana
    • 添加 Prometheus 数据源(URL 如 http://:9090),导入 GitLab/主机相关仪表盘并创建面板。
  • 配置告警
    • Prometheus 规则示例(告警 CPU 持续高于 80%1 分钟):
      • groups:
        • name: gitlab_alerts rules:
          • alert: GitLabHighCPU expr: 1 - avg by(instance)(rate(node_cpu_seconds_total{mode=“idle”}[1m])) > 0.8 for: 1m labels: severity: warning annotations: summary: “High CPU Usage on {{ $labels.instance }}” description: “CPU usage is above 80%”
    • 使用 Alertmanager 或 Grafana 告警通道(邮件、Slack 等)完成通知闭环。

三 关键监控指标与阈值建议

维度 关键指标 建议阈值或关注点 说明
系统资源 CPU 使用率、内存使用率、磁盘 IOPS/延迟、网络吞吐 CPU > 80% 持续 5–15 分钟;可用内存过低;磁盘 await/svctm 升高;带宽打满 先定位瓶颈资源,再回溯到 GitLab 组件
GitLab 组件 Unicorn/Rails 请求耗时、排队、5xx 错误率、Sidekiq 队列与重试、Workhorse 请求耗时 5xx 突增、队列持续增长、P95/P99 明显上升 反映应用健康与容量
Runner 作业排队时长、失败率、并发/利用率 排队时间拉长、失败率升高 关注 CI/CD 负载与 Runner 规模
数据库/缓存 PostgreSQL 连接数、慢查询、锁等待;Redis 命中率、内存与阻塞 连接数接近上限、慢查询增多、命中率下降 常见性能根因来源
存储与仓库 仓库对象存储延迟、NFS/对象存储错误、磁盘空间 空间不足、延迟抖动 影响克隆/拉取与 Web 响应
网络与安全 连接数、TCP 重传、异常来源 IP 重传率高、异常访问增多 排查网络质量与潜在攻击

四 命令行与日志的即时排查

  • 服务与连通性
    • 检查服务状态:sudo gitlab-ctl status
    • 快速健康检查:curl -I https:///users/sign_in(关注 200/302 与响应时延)
  • 资源与 I/O
    • 实时资源:top/htop、vmstat 1、iostat -x 1、sar -n DEV 1、netstat -s
    • 磁盘空间:df -h、du -sh /var/opt/gitlab
  • 日志定位
    • 综合日志:sudo gitlab-ctl tail
    • 组件日志:sudo gitlab-ctl tail nginx/gitlab-rails/gitlab-workhorse/sidekiq/postgresql/redis
  • 性能剖析
    • 管理区域启用 Performance BarAdmin → Metrics and profiling → Performance Bar),在页面底部查看当前请求各阶段耗时,快速定位慢点。

五 容器与 Kubernetes 场景补充

  • Kubernetes 中通过 ServiceMonitor/PodMonitor 或注解自动发现 GitLab 组件与 Node Exporter,示例注解:
    • gitlab.com/prometheus/scrape: “true”
    • gitlab.com/prometheus/scheme: “https”
    • gitlab.com/prometheus/path: “/-/metrics”
    • gitlab.com/prometheus/port: “8080”
  • 使用 Helm 部署时,在 values.yaml 中开启 monitoringrunner.metrics.enabled,并配置 Prometheus/Alertmanager 接入。

0