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 exporter
s, 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