Aller au contenu

Supervision de GitLab ()

Cette page décrit les processus de Monitoring des instances GitLab et des GitLab Runner.

La solution utilisée pour la surveillance (monitoring), remontée d'alerte (alerting) et la création de tableau de bord (dashboard) est la pile Prometheus, aussi connue sous le nom de kube-prometheus-stack.

Plus d'informations sur l'architecture déployée dans le cluster dans cette page .

Ci-dessous seront décrits les objets Kubernetes déployés pour superviser l'instance GitLab et les GitLab Runner.

Pour surveiller des point d'accès (endpoints), des ressources telles que des ServicesMonitor et des PodMonitor doivent être déployées. Ces dernières indiquent à l'instance Prometheus de moissonner certain endpoints. Les ServiceMonitor parcourent les endpoints de services, tandis que les PodMonitor récoltent les endpoints de pods. Les services ou les pods sélectionnés par ces deux objets Kubernetes sont définis par des labels.

Instance GitLab

Point d'accès à la supervision de GitLab

GitLab expose un endpoint metrics, pouvant être moissonné par Prometheus.

Les instances GitLab sont hébergées sur le cloud Oshimae (plus d'info ici.

Sachant que les instances GitLab sont hébergées sur un tenant Oshimae et que la pile de supervision est hébergée sur le Cluster Kubernetes ECO 3, les instances du monitoring n'ont pas directement accès à l'instance GitLab : L'IP n'est donc pas directement accessible par le cluster.

Un proxy a donc été mis en place afin d'accéder à l'endpoint /-/metrics depuis le cluster.

Ce proxy est un NGinx et la configuration est passée via une Configmap.

Ce proxy est exposé via un Service et ce dernier est interrogé par Prometheus via un Service Monitor.

Dans la Configmap, il faut ajouter un jeton ayant les droits suffisant pour communiquer avec l'API

Toutes les ressources définies ci-dessous sont déployées dans l'espace de nommage monitoring, cette valeur serait à adapter si besoin.

Les manifestes YAML de ce proxy sont définis ci-dessous.

La ConfigMap du service :

apiVersion: v1
kind: ConfigMap
metadata:
  name: gitlab-monitoring-proxy-configmap
data: #Dans la Configmap, l'endpoint donné est le /metrics, car Prometheus va nativement communiquer avec cet endpoint
  default.conf: |
    server {
    listen 80;
    location /metrics {
        proxy_pass https://gitlab-forge.din.developpement-durable.gouv.fr/-/metrics?token=<token>;
    }
    }
--- 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab-monitoring-proxy-deployment
spec:
  selector:
    matchLabels:
      app: gitlab-monitoring-proxy-deployment
  template:
    metadata:
      labels:
        app: gitlab-monitoring-proxy-deployment
    spec:
      containers:
      - name: gitlab-monitoring-proxy-deployment-container
        image: nginx
        resources:
          limits: #Limitation des ressources que peut consommer le proxy
            memory: "128Mi"
            cpu: "250m"
        ports:
        - containerPort: 80
          name: http
        securityContext:
          allowPrivilegeEscalation: false
        volumeMounts: #La Configmap est montée dans le Nginx en lecture seule dans le dossier de configuration
          - mountPath: /etc/nginx/conf.d/
            name: nginx-conf
            readOnly: true
      volumes:
        - name: nginx-conf
          configMap:
            name: gitlab-monitoring-proxy-configmap
            items:
            - key: default.conf
              path: default.conf
--- 
apiVersion: v1
kind: Service
metadata:
  name: gitlab-monitoring-proxy-service
  labels:
    k8s-app: gitlab-monitoring-proxy 
spec:
  selector:
    app: gitlab-monitoring-proxy-deployment
  ports: #Exposition du proxy sur le Port 80
  - name: metrics 
    port: 80
    targetPort: 80
--- 
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: gitlab-monitoring-proxy-servicemonitor
  # Namespace of prometheus operator
  namespace: monitoring
  labels:
    release: prometheus
    k8s-app: gitlab-monitoring-proxy 
spec:
  selector:
    matchLabels:
      k8s-app: gitlab-monitoring-proxy 
  endpoints: #On définit l'endpoint et l'intervalle de ping
  - port: metrics
    interval: 10s

L'exporter GitLab

GitLab peut aussi être configuré pour exposer des exporter ; ces derniers sont des serveurs managés par GitLab qui vont exposer des métriques sur des éléments du GitLab.

Trois exporter sont activés sur les instance GitLab :

  • L'exporter Postgresql : métriques de la DB Postgresql ;
  • L'exporter GitLab : métriques métier et technique sur la solution GitLab ;
  • Le Node Exporter : métriques serveurs.

Les exporter, suivant leur configuration, vont exposer un endpoint http (ou https), sur lequel Prometheus va pouvoir moissonner des métriques.

Tout comme le GitLab Monitoring Endpoint (sous-partie ci-dessus), un proxy nginx est configuré, ce dernier est exposé par un service et ce service est moissonné par Prometheus via un Service Monitor.

Les Manifestes YAML pour déployer ce proxy sont décrits ci-dessous.

Les Manifestes exposent les trois exporters, mais aussi le Monitoring Endpoint de GitLab.

apiVersion: v1
kind: ConfigMap
metadata:
  name: gitlab-monitoring-proxy-configmap
data: #Dans la Configmap, l'endpoint donné est le /metrics, car Prometheus va nativement communiquer avec cet endpoint
  default.conf: |
    server {
    listen 80;
    location /metrics {
        proxy_pass https://gitlab-forge.din.developpement-durable.gouv.fr/-/metrics?token=gyfMspZQT1p-8ydLuCnx;
    }
    }
    server {
    listen 81;
    location /metrics {
        proxy_pass http://app.gitlab-preprod.oshimae.rie.gouv.fr:9168/metrics;
    }
    }
    server {
    listen 82;
    location /metrics {
        proxy_pass http://app.gitlab-preprod.oshimae.rie.gouv.fr:9187/metrics;
    }
    }
    server {
    listen 83;
    location /metrics {
        proxy_pass http://app.gitlab-preprod.oshimae.rie.gouv.fr:9100/metrics;
    }
    }

--- 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab-monitoring-proxy-deployment
spec:
  selector:
    matchLabels:
      app: gitlab-monitoring-proxy-deployment
  template:
    metadata:
      labels:
        app: gitlab-monitoring-proxy-deployment
    spec:
      containers:
      - name: gitlab-monitoring-proxy-deployment-container
        image: nginx
        resources:
          limits: #Limitation des ressources que peut consommer le proxy
            memory: "128Mi"
            cpu: "250m"
        ports:
        - containerPort: 80
          name: metrics
        - containerPort: 81
          name: gitlab-exporter 
        - containerPort: 82
          name: sql-exporter 
        - containerPort: 83
          name: node-exporter 
        securityContext:
          allowPrivilegeEscalation: false
        volumeMounts: #La Configmap est montée dans le Nginx en lecture seule dans le dossier de configuration
          - mountPath: /etc/nginx/conf.d/
            name: nginx-conf
            readOnly: true
      volumes:
        - name: nginx-conf
          configMap:
            name: gitlab-monitoring-proxy-configmap
            items:
            - key: default.conf
              path: default.conf
--- 
apiVersion: v1
kind: Service
metadata:
  name: gitlab-monitoring-proxy-service
  labels:
    k8s-app: gitlab-monitoring-proxy 
spec:
  selector:
    app: gitlab-monitoring-proxy-deployment
  ports: #Exposition du proxy sur le Port 80
  - name: metrics 
    port: 80
    targetPort: 80
  - name: gitlab-exporter 
    port: 81
    targetPort: 81
  - name: sql-exporter 
    port: 82
    targetPort: 82 
  - name: node-exporter 
    port: 83
    targetPort: 83
--- 
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: gitlab-monitoring-proxy-servicemonitor
  # Namespace of prometheus operator
  namespace: monitoring
  labels:
    release: prometheus
    k8s-app: gitlab-monitoring-proxy 
spec:
  selector:
    matchLabels:
      k8s-app: gitlab-monitoring-proxy 
  endpoints: #On definit l'endpoint et l'intervalle de ping
  - port: metrics
    interval: 10s
  - port: gitlab-exporter
    interval: 10s
  - port: sql-exporter 
    interval: 10s
  - port: node-exporter 
    interval: 10s

L'exporter de Pipeline de GitLab

Nativement GitLab n'expose que peu de métrique métier et encore moins de métrique métier liée aux pipelines (temps d'exécution, pipeline, jobs, etc ...)

Néanmoins, un exporter, maintenu par la communauté existe

Ce dernier peut être configuré directement sur l'instance GitLab, sur un serveur standalone ou dans un cluster Kubernetes.

Compte tenu de la valeur ajoutée par cet exporter, il a été déployé et relié à l'instance GitLab.

L'avantage est qu'il ne nécessite pas de configuration spécifique sur l'instance : il suffit de fournir un jeton avec des droits suffisants (droit sur l'api et read_repository) et ce dernier va moissonner les métriques en requêtant l'API de l'instance GitLab.

Voici les instructions pour installer le chart Helm de l'exporter Pipeline. Ces commandes doivent être exécutées sur un serveur GNU/Linux, ayant accès à internet, ayant une kubeconfig avec les droits pour créer des ressources ainsi que Helm installé :

# Ajout du Helm repository contenant le chart
helm repo add mvisonneau https://charts.visonneau.fr

# Création d'un fichier values.yaml contenant les données de connexion
# Merci de bien customiser les valeurs avant d'appliquer la commande :

cat <<-EOF > values.yml
config:
 gitlab:
 url: <URL du gitlab> #Doit être accessible par le cluster
 # You can also configure the token using --gitlab-token
 # or the $GCPE_GITLAB_TOKEN environment variable
 token: 
 projects:
 - name: foo/project
EOF

# Release the chart on your Kubernetes cluster
helm upgrade -i gitlab-ci-pipelines-exporter mvisonneau/gitlab-ci-pipelines-exporter -f values.yml

Sur le serveur de déploiement, il faut créer un fichier values.yaml et le configurer. Attention à bien instancier les variables avant de continuer :

# config -- configuration of the exporter
config:
  gitlab:
    url: <URL du gitlab> #Doit être accessible par le cluster
    token: <token> #Le token doit avoir les droits sur l'API ainsi que les droit en lecture sur le repository.

  wildcards:
    - {} # Mettre un Wildcard va configurer l'exporter pour scrapper tous les projets

## Manage a ServiceMonitor resource to automatically configure the endpoint
## through the Prometheus operator: https://github.com/coreos/prometheus-operator
serviceMonitor:
  # serviceMonitor.enabled -- deploy a serviceMonitor resource
  enabled: true

  # serviceMonitor.scrapeInterval -- prometheus probes interval
  scrapeInterval: 10s

  # serviceMonitor.labels -- additional labels for the service monitor
  labels:
    release: prometheus #Le label à mettre sur le ServiceMonitor va dépendre de l'installation du Prometheus.

L'exporter peut ensuite être installé :

helm upgrade -i gitlab-ci-pipelines-exporter mvisonneau/gitlab-ci-pipelines-exporter -f values.yml

La commande ci-dessus va installer le chart Helm dans l'espace de nommage dans lequel kubectl est actuellement, il est possible de le customiser avec le flag -n.

GitLab Runner

Un GitLab Runner est déployé par groupe racine, dans un espace de nommage éponyme. Ils sont donc nombreux, ces derniers sont surveillés avec un PodMonitor :

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: gitlab-runner-pod-monitor
  labels:
    app.kubernetes.io/managed-by: ops-team
    release: prometheus
spec:
  namespaceSelector:
    any: true
  selector:
    matchLabels:
      app: gitlab-runner-gitlab-runner
      release: gitlab-runner
  podMetricsEndpoints: #Definition de l'endpoint
  - port: metrics
    path: /metrics 
    interval: 15s