Comment mettre en place l'observabilité CI/CD à grande échelle

L'optimisation du CI/CD commence par la visibilité. Pour bâtir une plateforme DevOps performante à l'échelle de l'entreprise, il est essentiel de comprendre les performances des pipelines et les schémas d'exécution des jobs, ainsi que de disposer d'indicateurs opérationnels quantifiables, en particulier pour les organisations qui exploitent des instances GitLab Self-Managed.

Afin d'aider les clients GitLab à maximiser leur investissement dans la plateforme, nous avons développé la solution GitLab CI/CD Observability dans le cadre de notre programme Platform Excellence. Celle-ci transforme les indicateurs bruts des pipelines en informations opérationnelles exploitables.

Un acteur majeur du secteur des services financiers s'est associé au Customer Success Architect GitLab pour gagner en visibilité sur son déploiement GitLab Self-Managed. Ensemble, nous avons mis en œuvre une solution d'observabilité conteneurisée combinant l'outil open source gitlab-ci-pipelines-exporter avec une infrastructure Prometheus et Grafana de niveau entreprise.

Dans cet article, vous découvrirez les défis rencontrés par cette organisation dans la gestion de ses pipelines à grande échelle, ainsi que la manière dont la solution GitLab CI/CD Observability y a répondu grâce à une mise en œuvre pratique de bout en bout.

Le défi : mesurer les performances CI/CD

Avant de mettre en place une solution d'observabilité, il est essentiel de définir vos paramètres de mesure :

• Quels indicateurs sont importants ? La durée des pipelines, les taux de réussite des jobs, les temps d'attente, l'utilisation des runners ?
• Qui a besoin de cette visibilité ? Les développeurs, les ingénieurs DevOps, les équipes plateforme, la direction ?
• Quelles décisions ces paramètres permettront-ils d'éclairer ? Les investissements dans l'infrastructure, la correction des goulots d'étranglement, la planification des ressources ?

Architecture de la solution : un ensemble complet de tableaux de bord pour l'observabilité

Une fois déployée, la pile d'observabilité fournit un ensemble de tableaux de bord Grafana avec une visibilité en temps réel et historique sur votre plateforme CI/CD. Un déploiement type comprend les éléments suivants :

• Tableau de bord d'aperçu des pipelines : une vue globale avec le nombre total d'exécutions de pipelines, les taux de réussite et d'échec dans le temps (sous forme de graphiques à barres empilées ou de séries temporelles) et les tendances de durée moyenne des pipelines. Les panneaux utilisent des indicateurs de statut par code couleur (vert pour la réussite, rouge pour l'échec, orange pour les annulations) afin que les équipes plateforme puissent repérer les problèmes en un coup d'œil.
• Tableau de bord des performances des jobs : des panneaux détaillés montrent la distribution des durées de chaque job (histogramme), le top 10 des jobs les plus lents par durée moyenne et des cartes thermiques des échecs de jobs par projet et par étape. C'est ici que les équipes identifient les jobs qui constituent des goulots d'étranglement à optimiser.
• Tableau de bord des runners et de l'infrastructure : combine les indicateurs système de Node Exporter (processeur, mémoire, disque) avec les données de temps d'attente des pipelines pour corréler la saturation de l'infrastructure avec les temps d'attente des pipelines. Cet outil est précieux pour les décisions de planification des ressources, comme le dimensionnement des pools de runners ou la montée en gamme des instances.
• Tableau de bord de la fréquence de déploiement : suit le nombre de déploiements et leur durée au fil du temps par environnement, en alignement avec les métriques DORA. Il aide les responsables d'ingénierie à évaluer le débit de livraison et la dérive des environnements (commits en retard par rapport à la branche principale).

Chaque tableau de bord est provisionné automatiquement via le provisionnement par fichier de Grafana, ce qui garantit un déploiement cohérent d'un environnement à l'autre. Les tableaux de bord peuvent être personnalisés davantage grâce aux variables Grafana pour filtrer par projet, branche de référence ou plage temporelle.

La solution nécessite deux exporters :

• Pipeline Exporter : collecte les indicateurs CI/CD via l'API GitLab (durée des pipelines, statut des jobs, déploiements)
• Node Exporter : collecte les indicateurs système (processeur, mémoire, disque) pour la corrélation avec l'infrastructure

Prérequis :

• GitLab Self-Managed version 18.1+
• Plateforme d'orchestration de conteneurs : un cluster Kubernetes (recommandé pour les déploiements d'entreprise) ou un environnement d'exécution de conteneur tel que Docker/Podman pour les environnements de moindre envergure ou les études de faisabilité. Le guide de déploiement principal ci-dessous cible Kubernetes ; une alternative Docker Compose est fournie en annexe pour les tests et évaluations dans un environnement local
• Jeton d'accès personnel GitLab (portée read_api)

Déploiement Kubernetes (recommandé)

Pour les environnements d'entreprise, déployez chaque composant sous forme de déploiement distinct au sein d'un espace de nommage dédié. Cette approche s'intègre à l'infrastructure de cluster existante, à la gestion des secrets et aux politiques réseau.

1. Créer l'espace de nommage et le secret

      kubectl create namespace gitlab-observability

# Create the GitLab token secret (see Secrets Management section below
# for enterprise-grade approaches using external secret operators)
kubectl create secret generic gitlab-token \
  --from-literal=token=glpat-xxxxxxxxxxxx \
  -n gitlab-observability

    

2. Déployer le Pipeline Exporter

      # exporter-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab-ci-pipelines-exporter
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gitlab-ci-pipelines-exporter
  template:
    metadata:
      labels:
        app: gitlab-ci-pipelines-exporter
    spec:
      containers:
        - name: exporter
          image: mvisonneau/gitlab-ci-pipelines-exporter:latest
          ports:
            - containerPort: 8080
          env:
            - name: GCPE_GITLAB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: gitlab-token
                  key: token
            - name: GCPE_CONFIG
              value: /etc/gcpe/config.yml
          volumeMounts:
            - name: config
              mountPath: /etc/gcpe
      volumes:
        - name: config
          configMap:
            name: gcpe-config
---
apiVersion: v1
kind: Service
metadata:
  name: gitlab-ci-pipelines-exporter
  namespace: gitlab-observability
spec:
  selector:
    app: gitlab-ci-pipelines-exporter
  ports:
    - port: 8080
      targetPort: 8080

    

3. Déployer Node Exporter (DaemonSet)

      # node-exporter-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: gitlab-observability
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
        - name: node-exporter
          image: prom/node-exporter:latest
          ports:
            - containerPort: 9100
---
apiVersion: v1
kind: Service
metadata:
  name: node-exporter
  namespace: gitlab-observability
spec:
  selector:
    app: node-exporter
  ports:
    - port: 9100
      targetPort: 9100

    

4. Déployer Prometheus

      # prometheus-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
        - name: prometheus
          image: prom/prometheus:latest
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: config
              mountPath: /etc/prometheus
      volumes:
        - name: config
          configMap:
            name: prometheus-config
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: gitlab-observability
spec:
  selector:
    app: prometheus
  ports:
    - port: 9090
      targetPort: 9090

    

5. Déployer Grafana

Le déploiement Grafana ci-dessous démarre avec l'authentification désactivée (GF_AUTH_ANONYMOUS_ENABLED: true) pour faciliter la configuration initiale.

Ce paramètre permet à toute personne ayant accès au réseau de consulter l'ensemble des tableaux de bord sans s'authentifier. Pour les déploiements en production, supprimez cette variable ou définissez-la sur « false » et configurez un fournisseur d'authentification approprié (LDAP, SAML/SSO ou OAuth) afin de restreindre l'accès aux utilisateurs autorisés.

      # grafana-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
        - name: grafana
          image: grafana/grafana:10.0.0
          ports:
            - containerPort: 3000
          env:
            # REMOVE or set to 'false' for production.
            # When 'true', any user with network access can
            # view dashboards without authentication.
            - name: GF_AUTH_ANONYMOUS_ENABLED
              value: 'true'
          volumeMounts:
            - name: dashboards-provider
              mountPath: /etc/grafana/provisioning/dashboards
            - name: datasources
              mountPath: /etc/grafana/provisioning/datasources
            - name: dashboards
              mountPath: /var/lib/grafana/dashboards
      volumes:
        - name: dashboards-provider
          configMap:
            name: grafana-dashboards-provider
        - name: datasources
          configMap:
            name: grafana-datasources
        - name: dashboards
          configMap:
            name: grafana-dashboards
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: gitlab-observability
spec:
  selector:
    app: grafana
  ports:
    - port: 3000
      targetPort: 3000

    

6. Configurer la politique réseau

Restreignez le trafic entre pods aux seuls chemins de communication nécessaires :

      # network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: observability-policy
  namespace: gitlab-observability
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    # Prometheus scrapes exporter and node-exporter
    - from:
        - podSelector:
            matchLabels:
              app: prometheus
      ports:
        - port: 8080
        - port: 9100
    # Grafana queries Prometheus
    - from:
        - podSelector:
            matchLabels:
              app: grafana
      ports:
        - port: 9090

    

7. Valider

      kubectl get pods -n gitlab-observability
kubectl port-forward svc/grafana 3000:3000 -n gitlab-observability
curl http://localhost:3000/api/health

    

Référence de configuration

Configuration de l'exporter

      # gitlab-ci-pipelines-exporter.yml (ConfigMap: gcpe-config)
log:
  level: info
gitlab:
  url: https://gitlab.your-domain.com
  maximum_requests_per_second: 10
project_defaults:
  pull:
    pipeline:
      jobs:
        enabled: true
wildcards:
  - owner:
      name: your-group-name
      kind: group
    archived: false

    

Configuration de Prometheus

      # prometheus.yml (ConfigMap: prometheus-config)
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'gitlab-ci-pipelines-exporter'
    static_configs:
      - targets: ['gitlab-ci-pipelines-exporter:8080']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

    

Sources de données Grafana

      # datasources.yml (ConfigMap: grafana-datasources)
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
# dashboards.yml (ConfigMap: grafana-dashboards-provider)
apiVersion: 1
providers:
  - name: 'default'
    folder: 'GitLab CI/CD'
    type: file
    options:
      path: /var/lib/grafana/dashboards

    

Indicateurs clés

Indicateurs du Pipeline Exporter

Indicateurs de Node Exporter

Dépannage

Installation de plugins Grafana dans un environnement air-gapped

Pour les environnements hors ligne, installez les plugins manuellement. Exemple pour Kubernetes :

      # Copy plugin zip into the Grafana pod
kubectl cp grafana-polystat-panel-2.1.16.zip \
  gitlab-observability/grafana-<pod-id>:/tmp/
# Extract plugin
kubectl exec -it -n gitlab-observability deploy/grafana -- \
  sh -c "unzip /tmp/grafana-polystat-panel-2.1.16.zip -d /var/lib/grafana/plugins/"
# Restart Grafana pod
kubectl rollout restart deployment/grafana -n gitlab-observability
# Verify installation
kubectl exec -it -n gitlab-observability deploy/grafana -- \
  ls -al /var/lib/grafana/plugins/

    

Points importants pour les environnements d'entreprise

Pour les secteurs réglementés, veillez à respecter les points suivants :

• Sécurité des jetons : stockez les jetons d'accès personnel GitLab dans un gestionnaire de secrets dédié plutôt que de les coder en dur dans les ConfigMaps. Appliquez des politiques de rotation des jetons et limitez la portée à read_api uniquement.
• Segmentation réseau : déployez derrière un proxy inverse avec terminaison TLS. Sur Kubernetes, utilisez un contrôleur Ingress avec provisionnement automatisé des certificats.
• Authentification : configurez Grafana avec le fournisseur d'identité de votre organisation (SAML, LDAP ou OAuth/OIDC) afin d'appliquer un contrôle d'accès basé sur les rôles aux tableaux de bord.

Pourquoi GitLab ?

Le design axé sur les API de GitLab permet de créer des solutions d'observabilité personnalisées qui complètent les fonctionnalités natives telles que l'analyse du flux de valeur et les métriques DORA. L'architecture ouverte permet aux organisations d'intégrer des outils open source éprouvés, comme gitlab-ci-pipelines-exporter, directement dans leur infrastructure d'entreprise existante, sans perturber les workflows établis.

À mesure que votre maturité en matière d'observabilité progresse, les fonctionnalités intégrées de GitLab Observability constituent une prochaine étape naturelle, car elles offrent une visibilité plus approfondie et intégrée sans outils supplémentaires. Découvrez les capacités disponibles nativement dans la plateforme pour GitLab Observability.