Monitoring de l'instance GitLab
GitLab expose nativement des metriques Prometheus et integre optionnellement Grafana. Les metriques couvrent les composants applicatifs (Puma, Sidekiq, Workhorse), les operations Git (Gitaly), la base de donnees et les queues CI.
Prometheus embarque
Omnibus inclut Prometheus et peut l'activer pour scraper tous les composants GitLab :
# /etc/gitlab/gitlab.rb
prometheus['enable'] = true
prometheus['listen_address'] = '0.0.0.0:9090' # ou loopback si Prometheus externeLes endpoints de metriques par composant :
:9090Prometheus/-/metricsRails (Puma):9229Workhorse:9236Gitaly:8082Sidekiq:9187PostgreSQL exporter:9121Redis exporter
Grafana
Omnibus peut deployer Grafana avec des dashboards preconfigures pour GitLab :
grafana['enable'] = true
grafana['gitlab_application_id'] = 'APPLICATION_ID' # OAuth GitLabLes dashboards GitLab officiels couvrent : throughput web, latence Rails, queues Sidekiq, performance Gitaly, connexions PostgreSQL, utilisation Redis.
Pour les deployments avances, integrer GitLab dans un stack Prometheus/Grafana existant est souvent preferable : moins de composants a gerer dans Omnibus, meilleure integration avec les alertes existantes.
Health checks
GitLab expose plusieurs endpoints de sante :
/-/health: liveness check (GitLab Rails repond)/-/readiness: readiness check (tous les services sont prets)/-/liveness: liveness avec details des sous-services
Ces endpoints sont utilises par les load balancers et les probes Kubernetes. Ils ne necessitent pas d'authentification mais peuvent etre filtres par IP dans la configuration NGINX.
Alertes cles a mettre en place
- Sidekiq queue depth : si les queues s'accumulent, les jobs CI et les webhooks prennent du retard
- Gitaly latency : degradation de performance visible sur toutes les operations Git
- PostgreSQL connections : epuisement du pool = erreurs 500
- Disk space : Gitaly et les artefacts CI peuvent saturer les disques rapidement
- Runner queue wait time : les jobs CI attendent trop longtemps = capacite runner insuffisante