如何通过GitLab监控Linux系统的性能

整体思路与架构

• 采用“主机层指标 + GitLab应用层指标 + 可视化告警”三层方案：在 Linux 主机上采集 Node Exporter 的系统指标，启用 GitLab 自带 Prometheus 指标端点，由 Prometheus 抓取并存储，使用 Grafana 展示，配合 Alertmanager 或 GitLab 内置告警进行通知。这样既能看到 CPU、内存、磁盘 I/O、网络等基础资源，也能观测到 GitLab 的请求延迟、作业队列、Sidekiq 等关键业务指标。

步骤一 主机层指标采集

• 安装并启动 Node Exporter（建议以 systemd 管理），默认监听 9100 端口，暴露节点级指标（如 node_cpu_seconds_total、node_memory_MemAvailable_bytes、node_disk_read/write_seconds_total 等）。
• 在 Prometheus 配置文件中新增抓取任务，例如：
  • job_name: ‘node’ static_configs:
    • targets: [‘< 你的服务器IP或域名> :9100’]
• 验证抓取：访问 Prometheus 的 /targets 页面，确认 node 目标为 UP 状态。

步骤二 启用 GitLab 应用层指标

• 在 GitLab 管理后台启用监控组件（不同版本菜单位置略有差异），确保 GitLab 的 Prometheus 指标端点开启，常见端点包括：
  • /metrics（Puma/Unicorn、Rails 应用指标）
  • /-/sidekiq/metrics（Sidekiq 队列与运行时指标）
  • /-/workhorse/metrics（Workhorse 代理指标）
  • /-/nginx/metrics（内置 Nginx 指标，如启用）
• 在 Prometheus 中新增抓取任务，例如：
  • job_name: ‘gitlab-rails’ metrics_path: ‘/metrics’ static_configs:
    • targets: [‘< gitlab.example.com> ’]
  • job_name: ‘gitlab-sidekiq’ metrics_path: ‘/-/sidekiq/metrics’ static_configs:
    • targets: [‘< gitlab.example.com> ’]
  • job_name: ‘gitlab-workhorse’ metrics_path: ‘/-/workhorse/metrics’ static_configs:
    • targets: [‘< gitlab.example.com> ’]
• 在 GitLab 管理后台 Monitoring 页面可查看部分内置图表与健康状态，用于快速巡检。

步骤三 可视化与告警

• 在 Grafana 中添加 Prometheus 数据源（URL 如 http://:9090），导入或创建仪表盘：
  • 系统层：Node Exporter 官方或社区仪表盘（关注 CPU、内存、磁盘 IOPS/延迟、网络 等）
  • 应用层：GitLab 官方/社区仪表盘（关注 HTTP 请求时延、Rails 队列、Sidekiq 延迟与重试、Puma/Unicorn 工作进程 等）
• 配置 Alertmanager 或在 GitLab 中配置告警规则，示例（Prometheus 规则）：
  • groups:
    • name: gitlab_alerts rules:
      • alert: HighCPU expr: 1 - avg by(instance)(rate(node_cpu_seconds_total{ mode=“idle”} [5m])) > 0.8 for: 5m labels: { severity: warning } annotations: summary: “High CPU on { { $labels.instance } } ” description: “CPU usage > 80% for 5m”
      • alert: GitLabHighResponseTime expr: gitlab_rails_request_duration_seconds{ quantile=“0.95”} > 1 for: 5m labels: { severity: warning } annotations: summary: “High GitLab 95th percentile latency” description: “P95 latency > 1s on { { $labels.instance } } ”
• 通知渠道可选 邮件、Slack、企业微信/钉钉 等，确保值班人员可及时响应。

步骤四 快速排障与日志联动

• Linux 现场排查常用命令（定位瓶颈时配合使用）：
  • top/htop（进程资源占用）、vmstat（虚拟内存与系统整体）、iostat（磁盘 I/O）、free（内存）、ss/netstat（网络连接）、dstat（综合资源）、sar（历史统计）、nmon（交互式资源监控）、glances（Web/API 视图）。
• GitLab 日志路径与实时查看（配合指标异常定位根因）：
  • /var/log/gitlab/gitlab-rails/production.log（Rails 主日志）
  • /var/log/gitlab/gitlab-rails/production_json.log（结构化异常）
  • /var/log/gitlab/gitlab-shell/gitlab-shell.log（gitlab-shell）
  • /var/log/gitlab/unicorn/*.log（Unicorn 输出，如使用）
  • 实时查看示例：tail -f /var/log/gitlab/gitlab-rails/production.log
• 如需更强的日志分析，可将日志接入 ELK Stack（Elasticsearch、Logstash、Kibana） 做检索与可视化。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！