Grafana on Zwindler's Reflection

Recompiler les dashboards Grafana "MetaMonitoring" de Mimir pour Kubernetes

Thu, 12 Dec 2024 18:00:00 +0200

Contexte

Quand on travaille sur l’observabilité, il y a un outil qui vient toujours en tête en premier : Grafana.

Grafana est un outil de visualisation open source développé par Grafana Labs, et je suis sûr que vous le connaissez tous (et j’ai aussi écrit à son sujet de nombreuses fois). Mais au-delà de cela, ils développent également beaucoup d’autres outils utiles dans le paysage de l’observabilité, au point qu’on peut en théorie construire toute sa stack d’observabilité uniquement avec des outils Grafana Labs.

Pour répondre au manque de stockage long terme de Prometheus et au manque de fonctionnalités de haute disponibilité (je n’ai JAMAIS compris pourquoi l’équipe Prometheus refuse de travailler là-dessus), Grafana Labs a forké Cortex il y a quelques années et l’a renommé Mimir.

Je ne vais pas couvrir l’installation de Mimir ici, il y a plein de tutoriels sur Internet et une documentation officielle pour ça.

À la place, je vais parler d’un problème que j’ai avec le chart helm officiel de Mimir, et plus précisément avec les dashboards Grafana intégrés qui viennent avec.

Des dashboards, vous dites ?

Mimir est livré avec de nombreux dashboards Grafana utiles pour s’assurer que les composants fonctionnent correctement.

Ces dashboards sont compatibles avec les différents modes de déploiement de Mimir. Dans Kubernetes, si vous utilisez le chart helm officiel mimir-distributed, cela peut être activé par une simple valeur :

metaMonitoring:
 dashboards:
 enabled: true

Mais, par défaut, tous les dashboards installés via la valeur metaMonitoring dans les charts helm de Mimir sont des manifestes JSON précompilés utilisant jsonnet/mixin.

Par exemple, voici la version précompilée du “Mimir / Overview dashboard” :

github.com/grafana/mimir/blob/2640b8f72127548e9e3da281a763476b03fb4aae/operations/mimir-mixin-compiled/dashboards/mimir-overview.json

Par conception, vous ne pouvez pas changer des choses comme le préfixe du nom des pods mimir, ce qui rend ces dashboards précompilés inutiles dans un environnement type helm où le nom de release (mimir-) est un préfixe du pod.

kubectl -n monitoring get pods
NAME READY STATUS RESTARTS AGE
mimir-alertmanager-0 1/1 Running 0 24h
mimir-alertmanager-1 1/1 Running 0 24h
mimir-compactor-0 1/1 Running 0 24h
mimir-distributor-5d668b479f-ksltr 1/1 Running 1 (24h ago) 6d1h
...

Dans ce cas, tous les dashboards seront cassés, affichant tous “no data” dans Grafana car les données seront incorrectement filtrées. Par exemple, le panneau “Write requests / sec” dans “Mimir / Overview dashboard” a un label job=~"($namespace)/((distributor..., mais notre pod est mimir-distributor, pas distributor :

sum by (status) (
label_replace(label_replace(rate(cortex_request_duration_seconds_count{cluster=~"$cluster", job=~"($namespace)/((distributor.*|cortex|mimir|mimir-write.*))", route=~"/distributor.Distributor/Push|/httpgrpc.*|api_(v1|prom)_push|otlp_v1_metrics"}[$__rate_interval]),
"status", "${1}xx", "status_code", "([0-9]).."),
"status", "${1}", "status_code", "([a-zA-Z]+)"))

La solution est de désactiver le flag metaMonitoring du chart, et de construire / déployer les dashboards séparément.

Procédure

Récupérez les sources de Mimir :

git clone https://github.com/grafana/mimir.git

Heureusement, les fichiers jsonnet/mixin incluent une variable job_prefix qui va nous aider à corriger cela :

sed -i.bak "s/job_prefix: '(\$namespace)\/',/job_prefix: '(\$namespace)\/mimir-',/" operations/mimir-mixin/config.libsonnet

Recompilez les dashboards :

make build-mixin

podman image inspect grafana/mimir-build-image:pr9491-80f5778956 >/dev/null 2>&1 || podman pull grafana/mimir-build-image:pr9491-80f5778956
podman tag grafana/mimir-build-image:pr9491-80f5778956 grafana/mimir-build-image:latest
[...]
make: Leaving directory '/go/src/github.com/grafana/mimir'
 10,10 real 0,02 user 0,01 sys

Note : Si vous n’avez pas docker sur votre machine (j’utilise podman), la commande make va échouer car elle ne peut pas trouver docker et le binaire docker est hardcodé dans les commandes make. Modifiez le Makefile pour remplacer docker par podman.

Les fichiers json dans operations/mimir-mixin-compiled/dashboards sont maintenant construits avec les noms de pods corrects.

Créez un chart helm grafana-dashboards (appelé yourDashboardsChart ici).

helm create yourDashboardsChart

Dans ce chart, créez un répertoire src/dashboards/mimir (pour les sources des dashboards json) à côté du répertoire classique templates contenant les manifestes YAML go-templatés. Nous allons créer les fichiers helm gotemplate juste après :

cp operations/mimir-mixin-compiled/dashboards/* ../yourDashboardsChart/src/dashboards/mimir

Maintenant, pour chaque fichier json généré par jsonnet, nous allons créer un fichier yaml helm gotemplaté, qui à son tour créera une ConfigMap pour chaque dashboard dans notre cluster Kubernetes. Ils ressembleront à ceci :

---
# Source: mimir-distributed/templates/metamonitoring/grafana-dashboards.yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: mimir-alertmanager-dashboard
 namespace: '{{ $.Release.Namespace }}'
 labels:
 grafana_dashboard: "1"
 annotations:
 k8s-sidecar-target-directory: /tmp/dashboards/Mimir Dashboards
data:
 mimir-alertmanager.json: |-
 {{ $.Files.Get "src/dashboards/mimir/mimir-alertmanager.json" | fromJson | toJson }}

Pour accélérer le processus, vous pouvez réutiliser helm template et quelques commandes bash pour générer tous les fichiers helm gotemplate pour vous :

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

mkdir -p mimir

helm -n monitoring template mimir grafana/mimir-distributed --set metaMonitoring.dashboards.enabled=true > helm-output.yaml

# Compter le nombre de séparateurs de documents
doc_count=$(grep -c '^---$' helm-output.yaml)

# Diviser le fichier YAML en fichiers séparés pour chaque document
csplit -f mimir/helm-output- helm-output.yaml '/---/' "{$((doc_count - 2))}" >/dev/null

# Un peu de nettoyage
for file in mimir/helm-output-*; do
 if grep -q 'kind: ConfigMap' "$file" && grep -q 'dashboard' "$file"; then
 name=$(yq eval '.metadata.name' "$file")
 yq eval -i 'del(.metadata.labels."helm.sh/chart", .metadata.labels."app.kubernetes.io/name", .metadata.labels."app.kubernetes.io/instance", .metadata.labels."app.kubernetes.io/version", .metadata.labels."app.kubernetes.io/managed-by")' "$file"
 yq eval -i '.metadata.namespace = "{{ $.Release.Namespace }}"' "$file"
 yq eval -i '.data |= with_entries(.value = "{{ $.Files.Get \"src/dashboards/mimir/" + .key + "\" | fromJson | toJson }}")' "$file"
 mv "$file" "mimir/${name}.yaml"
 else
 rm "$file"
 fi
done

mv mimir/* ../yourDashboardsChart/templates/mimir

Maintenant, vous devriez avoir tous les fichiers nécessaires pour régénérer les dashboards Grafana dans votre cluster Kubernetes, avec le préfixe correct.

Have fun!

Source

Sauvegarder des dashboards Grafana dans Kubernetes, en s’amusant (j’explique les RBAC, Job et les CronJob)

Tue, 01 Oct 2024 18:00:00 +0200

Note : Pour les allergiques à Kubernetes, cet article peut être vu comme une entrée en la matière, car je vais progressivement explorer certains concepts, de manière très progressive.

Note 2 : par convention dans cet article, j’ai essayé de nommer tous les objets Kubernetes avec une majuscule à tous les mots (exemple : ServiceAccount) pour que ce soit plus clair.

Grafana

Je ne vous ferai pas l’affront de vous présenter Grafana, l’outil de visualisation open source de la société éponyme. C’est un outil que j’utilise depuis un moment et qui est quasiment incontournable dans toutes les solutions de monitoring modernes (ou non ? xD).

D’ailleurs, j’ai écrit déjà quelques articles sur Grafana au fil des années, c’est un outil aussi simple qu’irremplaçable (jusqu’à ce qu’on trouve mieux, bien entendu).

Si vous avez déjà utilisé au moins une fois Grafana, vous savez donc que les visualisations sont organisées comme suit :

des dossiers
dans lesquels on range des dashboards
qui contiennent des panels (nos visualisations)

On peut donc créer des dashboards à gogo en fonction du besoin, les cloner, les modifier, les importer depuis un magasin sur grafana.com (assez inutilisable maintenant, mais bon) et en afficher le code JSON.

Et ça, c’est super cool, parce que si mon Grafana brûle (mes machines persos ne sont pas hébergées dans les conditions les plus pros possibles… 😱), je n’ai pas envie de tout perdre. Mais aller régulièrement copier / coller le code JSON de chaque dashboard, c’est pénible.

Because I’m API

Un truc qui est cool avec Grafana, c’est que comme tout logiciel un peu pro qui se respecte, il dispose d’une API. Je ne vais pas juger de sa qualité globale d’API (vous connaissez peut-être bien mieux que moi), mais elle a le mérite d’exister.

Récemment, je me suis donc demandé quelle quantité d’effort, il faudrait déployer pour sauvegarder de manière automatisée des dashboards Grafana avec l’API et Kubernetes (oui hein, vous n’allez pas y couper).

Partons donc du principe que j’ai un cluster Kubernetes sur lequel j’ai déployé la chart Helm officielle de Grafana (rappel, Helm, c’est à la fois un package manager et un moyen de déployer des applications dans Kubernetes).

À partir de là, de quoi j’ai besoin ?

Je suis le roi des fainéants, je ne veux pas avoir à aller créer les accès dans Grafana moi même (via 3 clics clics). Il faut donc que j’automatise la création d’un token pour communiquer avec l’API
Une fois que j’ai mon token, je veux créer une tâche périodique qui va se connecter à l’API, lister les dashboards disponibles et les sauvegarder sur un bucket s3 chez Scaleway (il y a 75 Go gratuit dans le free-tier, ça suffira largement)

Se préparer à créer un token

Bon, là en apparence, on se retrouve face à un problème d’œuf / poule. Comment je fais pour me connecter à l’API si je n’ai pas un accès à l’API ?

Heureusement, on va tricher… grâce à Kubernetes 😏

Quand on déploie Grafana dans Kubernetes, la chart officielle va créer un Secret (au sens Kubernetes du terme) qui contient le login / password du compte local administrateur de Grafana.

apiVersion: v1
kind: Secret
metadata:
 creationTimestamp: "2024-10-01T13:11:48Z"
 name: grafana
 namespace: grafana
 resourceVersion: "1234567"
 uid: deadbeef-dead-cafe-baba-123456789012
data:
 admin: YWRtaW4=
 password: TmV2ZXJHb25uYUdpdmVZb3VVcAo=
type: Opaque

S’il est déconseillé de l’utiliser au jour le jour (mieux vaut utiliser des comptes nominatifs, idéalement via un Identity Provider), c’est super pratique ici !

Il suffit de créer un Job Kubernetes avec suffisamment de droits pour lire ce Secret, qui va se connecter (une seule fois) sur l’API avec le compte admin, créer un token, le récupérer, et le stocker dans un autre Secret !

Sans rentrer à fond dans les détails de comment fonctionne le RBAC (Role Based Access Control) dans Kubernetes, voilà à quoi ça ressemble :

---
apiVersion: v1
# le compte de service (ServiceAccount) qui va être utilisé par le Job et qui a besoin de droits particuliers
kind: ServiceAccount
metadata:
 name: grafana-backup-sa
 namespace: grafana
---
apiVersion: rbac.authorization.k8s.io/v1
# le rôle, c'est la politique de sécurité qui va nous permettre de faire des trucs
kind: Role
metadata:
 namespace: grafana
 name: grafana-backup-role
rules:
# ici je n'autorise qu'à lire le secret contenant l'admin/password de grafana, pas plus
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana"]
 verbs: ["get"]
# ici, je vais autoriser le fait de modifier un secret qui s'appelle grafana-backup
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana-backup"]
 verbs: ["get", "update", "patch"]
# ici, je vais autoriser le fait de créer des secrets
- apiGroups: [""]
 resources: ["secrets"]
 verbs: ["create"]
---
# ici, je lie simplement ServiceAccount à un Role pour lui donner les droits dont j'ai besoin
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: grafana-backup-rolebinding
 namespace: grafana
subjects:
- kind: ServiceAccount
 name: grafana-backup-sa
 namespace: grafana
roleRef:
 kind: Role
 name: grafana-backup-role
 apiGroup: rbac.authorization.k8s.io

Note : vous aurez remarqué que je n’ai pas autorisé la création ET la modification du Secret grafana-backup en une seule étape, mais en deux. Ceci est dû à une limitation de l’API de Kubernetes, qui ne permet pas de limiter la création d’un objet via son “ressource name”. Je vous laisse aller lire la doc officielle si ça vous intéresse.

Sachez que je me suis un peu “embêté” à gérer la politique de droits et qu’on aurait pu faire bien plus simple. Mais c’est pour respecter le principe en sécurité informatique du moindre privilège (c’est important).

Bon… on va le créer, ce token ??

Maintenant qu’on a géré les aspects de sécurité (ça limitera les possibilités d’un attaquant qui réussirait à prendre la main sur notre Pod / container), on peut créer la tâche qui va créer le token.

Ici, il n’y a pas de raison de laisser tourner un container ad vitam une fois que le token est créé, on peut l’éteindre. Pour ça, il existe un objet dans Kubernetes qui s’appelle le Job (avec une gestion d’erreur et de retry intégré). Voilà à quoi il va ressembler :

---
apiVersion: batch/v1
kind: Job
metadata:
 name: grafana-backup-api-token-job
 namespace: grafana
spec:
 template:
 spec:
 # on lui donne bien le bon ServiceAccount sinon on a fait tout ce RBAC pour rien T_T
 serviceAccountName: grafana-backup-sa 
 containers:
 - name: grafana-create-api-token
 # une petite astuce pour de la bidouille, merci Jérôme :-*
 image: nixery.dev/shell/curl/jq/kubectl:latest
 # on "monte" le Secret Kubernetes comme des fichiers dans notre container
 volumeMounts:
 - name: grafana-secret-volume
 mountPath: /etc/grafana-secret
 readOnly: true
 command:
 - /bin/sh
 - -c
 - |
 # Comme on a monté le secret dans notre container, c'est super facile de récupérer
 # l'utilisateur et le mot de passe admin sans avoir à le stocker nulle part (surtout pas sur github)
 GRAFANA_ADMIN_USER=$(cat /etc/grafana-secret/admin)
 GRAFANA_ADMIN_PASS=$(cat /etc/grafana-secret/password)

 # On peut maintenant faire une requête HTTP via curl sur l'API de Grafana
 GRAFANA_API_TOKEN=$(curl -s -X POST http://@IPgrafana:80/api/auth/keys \
 -u "$GRAFANA_ADMIN_USER:$GRAFANA_ADMIN_PASS" \
 -H "Content-Type: application/json" \
 -d '{
 "name": "Kubernetes Backup Token",
 "role": "Admin",
 "secondsToLive": 31536000
 }' | jq -r '.key')

 # On termine par stocker le token dans le nouveau Secret grafana-backup
 kubectl create secret generic grafana-backup \
 --from-literal=GRAFANA_API_TOKEN=$GRAFANA_API_TOKEN \
 --dry-run=client -o yaml | kubectl apply -f -
 restartPolicy: OnFailure
 volumes:
 - name: grafana-secret-volume
 secret:
 secretName: grafana

Normalement, avec ce bon script code BASH, j’ai réconcilié les amateurs de bash avec Kubernetes.

Comment ça, “non” ?

Il ne me reste plus qu’à appliquer le manifest YAML sur mon cluster Kubernetes et le Secret grafana-backup contenant la clé d’API devrait apparaitre sur notre cluster :

kubectl apply -f job.yaml

kubectl get secrets
NAME TYPE DATA AGE
grafana-backup Opaque 1 1m

kubectl describe secret grafana-backup
Name: grafana-backup
Namespace: grafana
Labels: <none>
Annotations: <none>

Type: Opaque

Data
====
GRAFANA_API_TOKEN: 104 bytes

Première victoire :)

RBAC, again

On peut s’attaquer à la deuxième partie du problème : comment récupérer puis sauvegarder les JSON ?

Ben, avec une nouvelle couche de moindres privilèges, pardi !!

Vous connaissez la musique maintenant. On crée un ServiceAccount, on ne lui donne le droit qu’à lire les Secrets qui nous intéressent via un Role / RoleBinding pour ne pas faciliter le travail d’un attaquant qui aurait compromis mon Pod.

---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: grafana-backup-cron-sa
 namespace: grafana
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: grafana
 name: grafana-backup-cron-role
rules:
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana-backup", "grafana-backup-s3-credentials"]
 verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: grafana-backup-cron-rolebinding
 namespace: grafana
subjects:
- kind: ServiceAccount
 name: grafana-backup-cron-sa
 namespace: grafana
roleRef:
 kind: Role
 name: grafana-backup-cron-role
 apiGroup: rbac.authorization.k8s.io

Petite subtilité, ici, je vais aussi devoir créer un Secret supplémentaire pour que mon container puisse s’authentifier sur le bucket S3 sur lequel je vais déposer mes JSONs. Je ne rentre pas dans les détails, on sort du cadre de l’article, vous pouvez aller lire la doc officielle de scaleway qui est plutôt bien faite (Using Object Storage with the AWS-CLI).

Voilà à quoi ressemble le Secret grafana-backup-s3-credentials :

apiVersion: v1
kind: Secret
metadata:
 name: grafana-backup-s3-credentials
 namespace: grafana
type: Opaque
stringData:
 # le Secret se compose de 2 entrées, qui seront montés comme des fichiers textes 
 # dans le container ; pratique pour des fichiers de config avec des secrets !!
 credentials: |
 [default]
 aws_access_key_id=SCxxxxxxxxxxxxxxxxxx
 aws_secret_access_key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 config: |
 [default]
 region = fr-par
 output = json
 services = scw-fr-par
 [services scw-fr-par]
 s3 =
 endpoint_url = https://s3.fr-par.scw.cloud

Et pour finir, on veut donc créer une tâche planifiée, qui va s’occuper de réaliser notre sauvegarde régulièrement. Dans Kubernetes, il s’agit de l’objet CronJob, qui va lancer périodiquement des Job (le même qu’on a vu précédemment).

---
apiVersion: batch/v1
kind: CronJob
metadata:
 name: grafana-backup-cronjob
 namespace: grafana
spec:
 schedule: "0 */2 * * *"
 jobTemplate:
 spec:
 template:
 spec:
 serviceAccountName: grafana-backup-cron-sa
 containers:
 - name: grafana-backup
 image: nixery.dev/shell/curl/jq/awscli:latest
 volumeMounts:
 - name: grafana-backup-s3
 mountPath: /.aws/credentials
 subPath: credentials
 - name: grafana-backup-s3
 mountPath: /.aws/config
 subPath: config
 restartPolicy: OnFailure
 env:
 - name: GRAFANA_API_TOKEN
 valueFrom:
 secretKeyRef:
 name: grafana-backup
 key: GRAFANA_API_TOKEN
 command:
 - /bin/sh
 - -c
 - |
 # Ici, on récupère un gros JSON listant les dashboards et on utilise jq pour extraire l'identifiant unique "uid"
 dashboards=$(curl -s -H "Authorization: Bearer $GRAFANA_API_TOKEN" 'http://@IPgrafana:80/api/search?query=&type=dash-db' | jq -r '.[] | .uid')

 # On boucle ensuite sur la liste des uid
 for uid in $dashboards; do
 # On récupère le JSON qu'on copie en local
 dashboard_json=$(curl -s -H "Authorization: Bearer $GRAFANA_API_TOKEN" http://@IPgrafana:80/api/dashboards/uid/$uid)
 echo "$dashboard_json" > /tmp/dashboard-$uid.json

 # Puis on utilise aws-cli pour uploader le fichier sur notre bucket s3
 aws s3 cp /tmp/dashboard-$uid.json s3://grafana-backup/grafana-backups/dashboard-$uid.json --profile default
 done
 volumes:
 - name: grafana-backup-s3
 secret:
 secretName: secret-grafana-backup-credentials

Toutes les deux heures, nos dashboards seront tous sauvegardés sur notre bucket chez Scaleway. Si la fonction de versioning a été activé sur le bucket, on pourra même garder un historique des versions.

Deuxième victoire :)

Conclusion

Ok, écrire ces scripts et les manifests qui vont avec a surement pris un peu plus de temps que d’aller manuellement créer un token dans l’UI de Grafana, puis de le donner en dur dans un gros script bash.

Cependant, il y a quand même quelques différences avec cette approche :

A part pour les crédentials du bucket S3 (et encore on aurait pu utiliser minIO dans Kubernetes), on a manipulé aucun identifiant. Toute cette gestion des Secrets est déléguée à Kubernetes, loin de l’admin (avec les limitations que ça peut avoir). On n’aura pas de leaks sur github de secrets git-és par erreur et si on gère son RBAC correctement, seuls les Pods qui sont habilités à lire ses Secrets pourront le faire.
Tout est géré “as-code” et automatisé. Le faire une fois à la main va plus vite. Le faire 100 fois, car on a 100 clusters identiques, c’est quand même dommage.
On profite des fonctions de Kubernetes de gestion des erreurs et de retries des Jobs et des Cronjobs. C’est du code (bash ou autre) en moins à gérer si on veut fiabiliser l’outil dans une utilisation plus “industrielle”.

Que je vous aie convaincu ou pas, au-delà de l’exemple, le but était surtout d’introduire quelques concepts de Kubernetes (le RBAC et les Jobs, comment on construit des manifests, …) et j’espère que ça vous a plu.

Bonus

Si vous trouvez ces scripts trop limités pour vos besoins, vous pouvez aller voir les outils suivants, plus poussés. Attention cependant, certains ne sont pas/plus maintenu, et je n’ai pas audité le code. A vos risques et périls donc :

Ajoutons du monitoring à notre cluster k3s

Fri, 15 Sep 2023 06:00:00 +0200

Contexte

Je pars de l’article précédent (k3s et cilium rapide et facile) comme base pour installer ma stack k3s + cilium (CNI + ingressController).

L’idée ici, ça va être de préparer le monitoring pour le cluster, en vue d’y ajouter une (des) application(s).

Prometheus & friends

Pour la partie Prometheus, j’ai choisi d’utiliser la chart du projet prometheus-community, qui s’appuie elle-même sur plusieurs charts, dont grafana ainsi que le Prometheus Operator.

prometheus-operator.dev/

Cette chart est “énorme”.

Elle propose une quantité folle d’options, notamment en termes de divers setups de déploiement, avec ou sans Thanos par exemple. On peut même créer des “sharded Prometheus”, au cas où la charge devient ingérable par rapport à la taille de vos nodes.

Note: Ce n’est clairement pas la manière la plus simple de rentrer dans Prometheus, si vous débutez (j’ai écrit plusieurs articles là-dessus dans le passé, ici et là)

L’operator ajoute tout un tas de CRDs qui vont nous permettre de gérer la configuration (au sens très large, aussi bien les aspects techniques que pure configuration) de notre instance de Prometheus “comme du code”.

Le truc cool, c’est qu’on va pouvoir définir ce qu’on veut surveiller sur notre kubernetes sans avoir à aller éditer une ConfigMap. On peut ainsi donner le pouvoir aux devs de surveiller ce qu’ils veulent sans à aller toucher au namespace de monitoring.

Le truc un peu dommage par contre, c’est que par défaut, la chart est livrée avec des Selectors beaucoup trop restrictifs. Elle ne surveille que Prometheus lui même (release kube-prometheus)… On va enlever les restrictions (ex. serviceMonitorSelector.matchLabels: {}).

On va donc modifier les valeurs par défaut, et aussi ajouter un Ingress pour pouvoir accéder à grafana plus facilement depuis Internet :

cat > prometheus-values.yaml << EOF
nameOverride: prom
prometheusOperator:
enabled: true
admissionWebhooks:
enabled: true
prometheus:
enabled: true
prometheusSpec:
enableAdminAPI: true
probeSelector:
matchLabels: {}
podMonitorSelector:
matchLabels: {}
serviceMonitorSelector:
matchLabels: {}
ruleSelector:
matchLabels: {}
grafana:
ingress:
enabled: true
ingressClassName: cilium
hosts:
- grafana.example.org
cleanPrometheusOperatorObjectNames: true
EOF

On installe donc prometheus via helm une fois qu’on a le fichier de values :

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
prometheus-community/prometheus
helm upgrade --install kube-prometheus prometheus-community/kube-prometheus-stack --namespace prometheus --create-namespace -f prometheus-values.yaml

On vérifie le contenu de la CRD “Prometheus” que la chart à installer ne contient pas/plus les matchLabels.release :

$ kubectl -n prometheus get Prometheus -o yaml
[...]
 serviceMonitorNamespaceSelector: {}
 serviceMonitorSelector:
 matchLabels: {}

On se connecte ensuite à Grafana (accessible à l’URL http://grafana.example.org) pour vérifier que tout est fonctionnel. Ce qui est cool, c’est que les datasources vers prometheus et l’alertmanager sont déjà préconfigurées pour nous. Un truc de moins à faire !

Note: le login/mdp est admin/prom-operator (vous auriez pu le trouver vous-même dans le Secret prometheus/kube-prometheus-grafana)

ServiceMonitor

Une fois que c’est fait, on a notre plateforme de monitoring des métriques opérationnelle. Pour pouvoir surveiller notre IngressController, il va donc falloir activer le “ServiceMonitor”.

Problème, on l’a pas déployé l’option lorsqu’on a installé cilium dans le tuto précédent (en vrai, c’était volontaire, car il faut déployer la CRD ServiceMonitor AVANT de les activer dans cilium sinon l’install échoue).

Je fais donc un upgrade de la release helm, avec beaucoup plus d’options (d’où le besoin de faire un fichier de values) :

cat > cilium-values.yaml << EOF
operator:
 prometheus:
 enabled: true
 serviceMonitor:
 enabled: true
hubble:
 relay:
 enabled: true
 prometheus:
 enabled: true
 serviceMonitor:
 enabled: true

 metrics:
 serviceMonitor:
 enabled: true
 enableOpenMetrics: true
 enabled:
 - dns
 - drop
 - tcp
 - icmp
 - "flow:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"
 - "kafka:labelsContext=source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"
 - "httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"

prometheus:
 enabled: true
 serviceMonitor:
 enabled: true
EOF

CILIUM_VERSION="1.14.2"
helm upgrade --install cilium cilium/cilium --version=${CILIUM_VERSION} \
 --set global.tag="v${CILIUM_VERSION}" --set global.containerRuntime.integration="containerd" \
 --set global.containerRuntime.socketPath="/var/run/k3s/containerd/containerd.sock" \
 --set global.kubeProxyReplacement="strict" \
 --set global.bpf.masquerade="true" \
 --set ingressController.enabled=true \
 --set ingressController.default=true \
 -f cilium-values.yaml \
 --namespace cilium \
 --create-namespace

On peut se connecter sur Prometheus directement via un “port-forward” pour vérifier que cilium est bien dans nos “targets”

$ kubectl -n prometheus port-forward service/kube-prometheus-prometheus 9090
Forwarding from 127.0.0.1:9090 -> 9090
Forwarding from [::1]:9090 -> 9090

Dans Grafana, on peut également commencer à ajouter des dashboards pour voir si notre cilium va bien. Typiquement, Isovalent propose ces deux dashboards :

Loki + promtail

Les métriques, c’est bien. Mais tant qu’à y être, j’aimerais aussi pouvoir lire les logs de mon cluster. Les fans d’observabilité et/ou de Grafana me voient venir avec mes gros sabots, je vais ajouter Loki au cluster, via la chart officielle :

helm repo add grafana https://grafana.github.io/helm-charts

cat > loki-values.yaml << EOF
loki:
 auth_enabled: false
 commonConfig:
 replication_factor: 1
 storage:
 type: 'filesystem'
singleBinary:
 replicas: 1
EOF

helm install loki --namespace loki grafana/loki --create-namespace -f loki-values.yaml

Par rapport aux valeurs par défaut, je vais brider loki en ne lui affectant qu’un seul replica. J’ai aussi retiré l’authentification. Ne faites évidemment pas ça en prod 😬.

On a de la chance, Loki a déjà sa définition ServiceMonitor par défaut :

$ kubectl -n loki get serviceMonitor loki -o yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 annotations:
 meta.helm.sh/release-name: loki
 meta.helm.sh/release-namespace: loki
[...]

Loki en lui-même ne va pas faire grand-chose d’intéressant. Pour récupérer les logs de nos pods, il va nous falloir ajouter l’agent “promtail”, qui va faire l’auto-découverte et la collecte des logs de nos pods.

$ helm upgrade --install promtail grafana/promtail -n loki

On se connecte à Grafana, on ajoute la source de données pour Loki, puis on vérifie que tout fonctionne correctement avec la fonctionnalité “Explore” dans Grafana.

Et si on ajoutait des traces ???

Comme je l’ai dit plus haut, normalement, vous m’avez vu arriver. Il existe 3 piliers dans l’observabilité : les métriques, les logs, et les traces.

Les métriques et les logs, ça parle à tout le monde. Les traces, moins.

Pour faire très (trop?) simple : les traces, c’est une méthode d’observabilité permettant d’obtenir des informations de performances sur le parcours d’une requête de son entrée dans notre SI jusqu’au retour. Les informations remontées par les traces permettent ainsi de remonter la pelote entre (micro)services mais aussi obtenir des informations DANS les services eux-même.

Note: c’est pour ça qu’on parle de “distributed tracing”, cette technique est particulièrement efficace pour debugger des problématiques complexes de performance au sein d’architectures microservices.

Je vous incite à aller lire l’article de Mathieu Corbin : Tracing avec Opentelemetry: pourquoi c’est le futur (et pourquoi ça remplacera les logs) pour mieux comprendre de quoi il s’agit.

Tempo

Je n’ai pas choisi les outils de Grafana Labs par hasard. Il se trouve que Grafana Labs fourni la stack complète pour disposer d’une plateforme d’observabilité complète (j’aurai même pu remplacer Prometheus/Thanos par Grafana agent + Mimir).

Pour la partie tracing, je vais donc commencer par installer Grafana Tempo, comme datasource de tracing pour Grafana. Il existe plusieurs manières d’installer Tempo sur Kubernetes. Pour faire simple je vais déployer le composant dit “monolithique”.

$ helm upgrade --install tempo grafana/tempo -n tempo --create-namespace

On ajoute ensuite la datasource dans Grafana comme pour Loki :

Note: attention ici encore, les valeurs renseignées ne sont pas du tout des valeurs pour une production. Ici, j’ai juste ajouté Tempo, sans aucune haute disponibilité ni persistance (S3).

Maintenant que Tempo est installé, il faut qu’on indique à cilium d’envoyer des traces à Tempo. Pour ça, j’ai besoin d’ajouter opentelemetry, qui est le backend vers lequel les traces vont être envoyées (un peu comme pour loki et promtail).

helm repo add jetstack https://charts.jetstack.io
helm install \
 cert-manager jetstack/cert-manager \
 --namespace cert-manager \
 --create-namespace \
 --version v1.13.0 \
 --set installCRDs=true \
 --set admissionWebhooks.certManager.create=true

cat > opentelemetry-operator-values.yaml << EOF
manager:
 serviceMonitor:
 enabled: true
EOF

helm upgrade --install opentelemetry-operator open-telemetry/opentelemetry-operator \
 --namespace opentelemetry-operator --create-namespace \
 -f opentelemetry-operator-values.yaml

kubectl apply -n opentelemetry-operator -f manifests/otel-collector.yaml

Une fois l’OpenTelemetry operator déployé, on peut (comme pour Prometheus) gérer nos collecteurs comme du code. Je vais donc demander à Otel (le petit nom mignon d’OpenTelemetry) Operator de me créer un DaemonSet pointant sur Tempo :

kubectl create ns opentelemetry

cat > opentelemetry-manifest.yaml << EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
 name: otel
 namespace: opentelemetry
spec:
 mode: daemonset
 hostNetwork: true
 image: otel/opentelemetry-collector-contrib:0.60.0
 config: |
 receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317
 http:
 endpoint: 0.0.0.0:4318
 processors:
 memory_limiter:
 check_interval: 1s
 limit_percentage: 75
 spike_limit_percentage: 15
 batch:
 send_batch_size: 10000
 timeout: 10s

 exporters:
 logging:
 loglevel: info
 otlp:
 endpoint: tempo.tempo.svc.cluster.local:4317
 tls:
 insecure: true

 service:
 pipelines:
 traces:
 receivers: [otlp]
 processors: []
 exporters:
 - logging
 - otlp
EOF

kubectl apply -f opentelemetry-manifest.yaml

Une fois créé, des pods OpenTelemetry devraient se créer :

kubectl -n opentelemetry get pods
NAME READY STATUS RESTARTS AGE
otel-collector-5wk9s 1/1 Running 0 16s
otel-collector-mv24p 1/1 Running 0 16s

Les données de performances qui seront remontées par les pods sur otel seront visibles dans la datasource de Grafana.

Conclusion

La plateforme d’observabilité est opérationnelle. J’avais prévenu, c’est assez dense :\D.

Et pour l’instant elle ne sert pas à grand-chose, puisque rien n’est déployé sur mon cluster xD !

Cependant, vous l’avez deviné, ceci est pour un prochain article… En attendant, have fun ;-P.

Sources complémentaires

Mise en place d’une astreinte OPS – partie 2

Mon, 24 Aug 2020 06:05:00 +0000

“J’peux pas, j’suis d’astreinte”

Voici la seconde partie de mon (gros) article dédié à la mise en place d’une astreinte, dans le cadre du maintien en conditions opérationnelles d’un service informatique. Dans la première partie (disponible ici si vous l’avez loupé), j’ai introduis ce qu’était réellement une astreinte, pourquoi on en met en place et enfin les textes en vigueur.

Dans cette deuxième partie, je vais donc rentrer un peu plus dans le concret.

Pour rappel, il y a 2 ans, j’ai intégré une équipe d’ingénieurs systèmes cloud qui venait de se créer. Quand les premiers produits et les premiers clients sont arrivés en production, le besoin d’assurer la continuité d’activité s’est fait sentir. Et donc, par extension, le besoin d’une astreinte.

J’ai donc eu la chance de pouvoir participer, étant directement concerné (et surtout un peu renseigné sur le sujet) à l’élaboration de cette astreinte. Ça a été l’occasion de traiter directement les aspects suivants :

problématiques droit du travail
organisationnel
implémentation technique

Concevoir son astreinte

Comment organiser les astreintes ?

Après la compensation (récupération ou rémunération), c’est souvent LE gros sujet quand on met en place une astreinte.

Dans tous les cas, il n’est pas souhaitable de mettre 365j/an une seule et même personne d’astreinte ; il faut définir un roulement.

Pour le roulement, est-ce qu’une même personne est d’astreinte toute la semaine ? Seulement quelques jours ? Est-ce que tous les jours, on change ?

Dans le premier cas, les périodes d’astreinte sont plus espacées, mais plus longues (et potentiellement génératrices de plus de fatigue). Dans le dernier, même en cas de semaine chaotique, le changement régulier permet de mieux répartir la fatigue entre astreinteurs, mais on est très souvent d’astreinte (pendant de courtes périodes).

Est-ce que l’astreinte va concerner une journée complète de 24h, ou au contraire, considère-t-on que la journée l’équipe d’exploitation peut gérer les incidents, et l’astreinte à juste vocation à prolonger les horaires de bureaux ?

Ces questions ne sont pas anodines.

Au-delà de l’impact que le fait d’être d’astreinte a sur la vie privée (on ne peut pas faire autant de choses que l’on veut quand on est d’astreinte, c’est pour ça qu’on est compensé…), cela peut avoir des effets très importants sur l’organisation de l’équipe.

Pourquoi ça peut coincer ?

Pour expliciter un peu où je veux en venir, prenons un exemple. Imaginons qu’une équipe de 4 OPS décide de créer une astreinte informatique 7j/7. Les incidents de la journée sont traités par l’équipe et en dehors des horaires de bureau (18h => 9h le lendemain), l’astreinteur prend le relais.

L’astreinteur prend son astreinte le vendredi 18h. Pas de chance, le week end est chaotique ! Des appels ont lieu le samedi et le dimanche, nécessitant des interventions à chaque fois.

A aucun moment du week end, l’astreinteur n’a eu ses 35h de repos hebdomadaire consécutives.

Dans ce cas un peu extrême (mais vécu IRL), le code du travail l’empêche de reprendre le travail que mardi matin. Son absence lundi provoque un déséquilibre dans l’organisation de l’équipe…

Le problème ne se limite évidemment pas au week end. On peut avoir le genre de problèmes si les appels d’astreinte ont lieu la nuit (un à 23h, l’autre à 5h par exemple).

Et le problème est exacerbé si en plus, les appels continuent de pleuvoir pendant la journée. Dans ce cas, si on continue à avoir des alertes en journée, le compteur de repos n’arrive jamais à 11h.

Quelle que soit l’organisation que vous choisissez, il est dans tous les cas impératif de se débrouiller pour que les appels arrivent le moins souvent possible (travailler pour réduire les alertes intempestives).

Il n’y a qu’en travaillant sur la réduction du nombre d’incidents qu’on peut réussir à impacter le moins possible l’organisation de l’équipe “de jour”.

Quel outillage pour réussir son astreinte ?

Je n’imagine pas une seule seconde une astreinte où l’on aurait pas “le kit de l’astreinteur”. Sauf à imposer à l’astreinteur d’être assigné à résidence, ce qui va à l’encontre de la définition de l’astreinte je pense, il est nécessaire pour l’astreinteur OPS d’avoir :

PC portable
smartphone
connexion 4G de qualité (je résiste à insérer un troll 5G).

Ces 3 items fonctionnent ensemble. Le smartphone permet de recevoir les appels et les alertes automatiques (via la 4G). Le PC portable permet d’y remédier en se connectant rapidement sur l’infra, via le modem 4G du smartphone.

On pourrait également considérer qu’un astreinteur pouvant être seul, il est nécessaire qu’il dispose d’un PTI/DATI (protection travailleur isolé). Ça serait particulièrement vrai dans le cas où l’astreinte nécessite des interventions sur site (en DC par exemple), où un accident, hors des horaires de bureaux, pourrait être dramatique.

Bon, ça, c’est le strict minimum.

Si on se contente de ça, on va avoir une astreinte qui subit. Les astreinteurs seront prévenus des incidents par les clients (ou le management) et il sera parfois trop tard pour réparer la situation.

Mettre en place une astreinte efficace nécessite donc quasi obligatoirement d’avoir une plateforme de supervision la plus complète et la plus pertinente possible

Surveiller et alerter en cas de problème

D’abord, ça permet de ne plus subir.

L’astreinteur est prévenu de manière automatique qu’un incident est en cours. Ça permet de retirer un facteur humain dans la chaîne d’intervention (attendre que quelqu’un se plaigne du souci et pense à prévenir la bonne personne) et donc de gagner du temps.

Parfois, on peut même être prévenu avant la catastrophe (eh, ho, ton disque il est bientôt plein là !).

On devient donc proactif.

Ensuite, ça permet, en cas d’incident grave qu’on a pas pu éviter, de savoir exactement ce qui s’est passé et quand. Sans supervision (ou sans métriques pertinentes), impossible de faire un diagnostic correct de ce qui s’est passé et d’engager des actions correctives pour que ça ne se reproduise plus (post-mortem).

Toute la difficulté de l’exercice repose donc dans l’exhaustivité et la pertinence des métriques MAIS la parcimonie des alertes. Pas assez d’alertes, c’est des clients mécontents, mais trop d’alertes, c’est pire… l’astreinteur sera sollicité trop souvent…

Alert fatigue

Au delà de la simple fatigue provoqué par trop d’alertes (et des conséquences que ça peut avoir dans l’équipe comme je l’ai exposé plus haut), ce surplus a un autre effet pervers.

S’ils sont constamment noyés dans des alertes, les astreinteurs vont s’y habituer et cela va inexorablement les conduire à les ignorer. Ce ne sera pourtant pas par flemme ni par manque de professionnalisme.

En fait, le phénomène est connu sous le terme d’“Alert fatigue”, que vous connaissez peut-être mieux depuis votre tendre enfant au travers la fable du garçon criant au loup.

Alarm fatigue or alert fatigue occurs when one is exposed to a large number of frequent alarms (alerts) and consequently becomes desensitized to them. Desensitization can lead to longer response times or missing important alarms. [https://en.wikipedia.org/wiki/Alarm_fatigue](Page wikipedia de l’Alarm fatigue)

Concrètement, dans le cas des alertes automatiques, trop d’alertes risque de conduire le cerveau des administrateurs à ignorer un problème important en pensant que c’ est “une erreur normale, habituelle”.

Il va donc être crucial de n’alerter l’administrateur en astreinte que quand c’est réellement nécessaire.

Implémenter l’astreinte

Maintenant qu’on a bien les idées claires sur ce qu’on doit mettre en place, je vous présente maintenant des solutions que nous avons envisagé (voire retenu).

Cela n’a pas vocation a être une réponse universelle, mais ça convient aux besoins et aux contraintes que nous avions.

L’organisation de l’astreinte

L’idée était de trouver un compromis entre :

fatigue
risque d’absence (à cause du repos quotidien ou hebdomadaire)
répétitions pas trop régulières

Pour toutes les raisons que j’ai cité dans le chapitre sur la conception, le roulement qui nous a paru le plus pertinent, et que nous avons mis en place est le suivant :

Cette organisation permet de garantir que :

si jamais le repos hebdo n’a pas pu être pris en entier, le changement d’astreinteur le lundi lui permet de se reposer
les appels en journée ne gênent pas la prise du repos quotidien au cas où il n’a pas pu être pris pendant la nuit précédente
A 5, on a en moyenne 2 semaines sans aucune astreinte, puis une période de 3 ou 4 jours

Ceci permet de garantir donc à la fois les repos et nous parait être un bon compromis entre fréquence et durée des astreintes.

Les outils de la chaîne de supervision

Le choix de l’outil dépendra obligatoirement du contexte. Si vous travaillez dans une équipe réseau, vous n’aurez pas les mêmes besoins et donc pas les mêmes outils qu’une équipe d’exploitation cloud.

Sans citer directement le nom des produits que nous utilisons, je vais vous donner une liste des types d’outils que nous avons mis en place :

Un groupe de serveurs Prometheus + Thanos pour collecter et stocker les métriques de nos applications dans Kubernetes, mais aussi des services de notre cloud provider (IaaS, SaaS, DBaaS) et des middlewares que nous gérons nous-même (message brokers, bases NoSQL)
Un outil d’alerting, AlertManager, le composant d’Alerting de Prometheus
Une plateforme de visualisation Grafana qui nous permet de visualiser les métriques provenant de différentes sources (majoritairement Prometheus, mais aussi les métriques du cloud providers)
Une plateforme pour centraliser les logs des applications (ex. Splunk/ElasticStack)
Un outil de supervision externe (ex. Pingdom/StatusCake) pour visualiser l’accès aux services web que nous exposons sur Internet depuis plusieurs points dans le monde
Un outil d’APM (Application Performance Monitoring, ex. AppDynamics/Dynatrace) pour valider que le ressenti des utilisateurs ne se dégrade pas (plus pernicieux que la coupure franche)
Un outil pour communiquer en temps réel avec les équipes (chat+audio+visio, de type Teams/Slack/Discord).

Pour le dernier point, Slack nous était tellement utile pour gérer les incidents que j’ai même créé un bot pour créer des channels dédiés pour chaque incident et y inviter les personnes concernées (managers, ops, call center). Si ça vous intéresse, ça s’appelle redalert, c’est open source et j’en parle dans cet article :

redalert : gérer les incidents avec un bot Slack

One tool to rule them all

Comme vous pouvez le voir, ça fait quand même beaucoup de types d’outils différents. Et même si les éditeurs tentent de vous convaincre que vous pouvez tout faire avec un seul outil, c’est probablement faux dès que votre contexte est un peu complexe.

Cependant, pour éviter de se retrouver avec un trop grand nombre de sources de données distinctes, le mieux est de remonter toutes les alertes vers une seule et même plateforme :

Un outil de réponse aux incidents (tel que OpsGenie/PagerDuty par exemple). L’outil de réponse aux incidents permet de gérer les rotations de notre équipe d’astreinte, l’éventuelle escalade, d’avoir des métriques de base sur les incidents, leur provenance et leur durée, etc. Mais le plus important : de notifier la personne d’astreinte sur différents types de canaux (notification push sur smartphone, SMS, appel vocal via TTS, slack, …), de manière entièrement configurable.

Cet outil est vraiment la pièce maîtresse, qui apporte la cohérence à tout le reste. Choisissez donc le bien !

Qu’est ce qu’il manque ?

Vous aurez très certainement besoin de sortir des informations (dashboards, statistiques) sur les incidents du mois (pour suivre la charge, la fatigue des équipes, gérer la paie si les heures d’intervention sont payées ou récupérées).

Généralement, on peut utiliser le reporting intégré à l’outil de réponse aux incidents, mais c’est souvent assez pauvre.

Comme nous voulions pouvoir faire des stats et “déclarer” les durées des astreintes ainsi que leur nombre aux RHs (pour calculer les récupérations), nous avons pris le parti de tenir à jour nous-même un fichier des interventions.

Cette feuille de calcul, assez riche (avec beaucoup de macros et de formules magiques), nous permet d’avoir toutes les données pour ensuite calculer tous les indicateurs dont nous avons besoin.

Actuellement, la seule chose qui pourrait manquer est un outil pour calculer si le repos quotidien/hebdomadaire a été respecté ou non.

Ceci pourrait être fait via la feuille de calcul (puisqu’on a toutes les infos) mais n’est pas très user friendly (ni trivial à implémenter).

J’ai demandé sur Twitter s’il existait un outil pour faire ça, mais a priori rien n’existe “out of the box”…

Et vous, vous faites comment ?

Enfin fini ! Je suis bavard, je sais ;). Mais comme vous avez pu le voir, c’est un sujet aussi complet que complexe.

Cependant, ces deux posts n’étaient que ma vision propre de l’astreinte. Je suis sûr que vous avez vous aussi des besoins et des contraintes différentes.

Donc vraiment (encore plus que d’habitude) n’hésitez pas à utiliser les commentaires pour donner votre avis et nous parler de votre propre organisation.

Ça pourra en aider d’autres :).

Superviser votre instance Jitsi avec Prometheus et Grafana

Mon, 08 Jun 2020 06:35:00 +0000

Quel rapport entre Jitsi et Prometheus ?

Si vous avez suivi un peu mes articles depuis le début du confinement, vous aurez vu qu’en ce moment je fais du Jitsi (cf Ta visio Open Source comme un pro avec Jitsi) et du Prometheus (cf Découvrir Prometheus et Grafana par l’exemple).

Et ça tombe super bien, car aujourd’hui je vais vous parler des deux !

L’appel des Chatons

J’ai pas trop communiqué là dessus, mais lorsque le confinement a commencé, les ENT étant down, beaucoup d’enseignants se sont tournés vers Framasoft, qui héberge entre autre des services d’éditions de texte en collaboratif ainsi que des instances de visio conférences Jitsi.

Ça a pas mal râlé côté Framasoft car ça fait des années qu’ils expliquent qu’en tant qu’association 1901, ils n’ont ni les moyens ni l’envie de supporter les conséquences des mauvais choix technologiques / budgétaires de l’éducation nationale. (Si vous voyez pas trop où que je veux en venir, allez voir leur site, ils l’expliquent mieux que moi). Et de fermer ces deux services temporairement dans la foulée.

Suite à quoi, les CHATONS se sont proposés de faire le relais en listant un ensemble de services Jitsi et Etherpad mis à dispositions par des CHATONS et des particuliers (et maintenant plus encore).

J’ai pas trop communiqué là dessus, mais moi aussi j’ai mis mon instance à dispo.

Coucouuuuuu, je suis là !!

Et alors, des gens s’en servent ?

C’est super cool, j’ai mis à dispo une instance jitsi qui a priori a été utile à plusieurs personnes.

Mais jusqu’à présent, au delà du trafic CPU/réseau que je vois monter de temps en temps, je n’avais aucune idée de la quantité de conférences qui se tenaient sur mon instance.

Puis, j’ai vu ce tweet de pyg, qui m’a relancé sur le sujet.

Ouuuaaaah, la classe :D

A vue de nez, c’est du Grafana. J’ai donc voulu trouver comment brancher Jitsi à ma supervision existante.

Deux exporters pour le prix d’un

La première chose à faire était donc de trouver un exporter prometheus compatible avec Jitsi, histoire de pouvoir capitaliser sur l’infrastructure (Grafana/Prom) actuelle.

J’ai trouvé 2 projets en Go :

jitsi-prom-exporter dont j’ai trouvé la trace sur le forum de jitsi
jitsiexporter

Les deux n’étant pas franchement bien documentés (et je suis une quiche en Go), je me suis d’abord orienté vers jitsi-prom-exporter, plus “connu” (enfin, ça se joue à 10 étoiles sur Github hein…).

Mais je n’ai jamais réussi à le compiler (vive le Go) et comme je n’y comprend rien après avoir ragé quelques heures (ma femme confirme) j’ai laissé tombé. [Edit]En vrai j’ai fini par le faire marché avec de l’aide et beaucoup de trial and error mais bon… Il faut faire ça, ça puis ça [/Edit]

En revanche, jitsiexporter, j’ai réussi à le faire fonctionner assez vite ! Et je vous propose qu’on se l’installe ensemble !

Activer les statistiques

La première chose à faire et de vérifier dans votre install de Jitsi si l’API REST est activée ou non. Si ce n’est pas le cas, vous pouvez tenter de modifier les propriétés du sip-communicator de videobridge.

ps -ef | grep jvb
jvb 164 1 0 20:09 ? 00:00:56 java -Xmx3072m [...] --apis=rest,

Pour être honnête, je ne suis pas encore bien bien sûr à 100% ce qu’il faut faire pour être sûr que c’est actif. La documentation du projet Github de l’exporter n’est pas hyper claire et j’ai lu pas mal d’instruction contradictoire sur les forums…

En fin d’article, je vous ai mis deux liens vers la doc officielle de Jitsi à ce sujet.

vi /etc/jitsi/videobridge/sip-communicator.properties
[...]
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc,colibri
org.jitsi.videobridge.STATISTICS_INTERVAL=1000

Une fois que c’est bon, un petit curl` vous permettra de vous assurer que tout va bien.

curl http://127.0.0.1:8080/colibri/stats
{"inactive_endpoints":0,"inactive_conferences":0,"total_ice_succeeded_relayed":0,"total_loss_degraded_participant_seconds":0,"bit_rate_download":0,"muc_clients_connected":1,"total_participants":0,...

Installer l’exporter

Maintenant que notre Jitsi nous donne bien des statistiques en local, on va pouvoir commencer à utiliser un exporter pour consommer les métriques périodiquement et les servir au format Prometheus.

Prérequis pour la compilation

D’abord il nous faut go… Sur un Ubuntu 18.04 ça donne ça :

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt update
sudo apt install golang-go git

Compiler

Ensuite, il faut compiler l’exporter. En théorie, comme Go fait des binaires “qui marchent partout”, vous pouvez compiler l’exporter sur votre poste et envoyer le binaire sur le serveur jitsi. En théorie…

su - jvb
mkdir -p go/src && mkdir -p go/bin
cd go/src
git clone https://github.com/xsteadfastx/jitsiexporter
cd jitsiexporter
go get ./...

Si tout se passe bien, un binaire est créé dans ~/go/bin

Tester l’exporter

Maintenant qu’on a un exporter, on va le tester en le lançant à la main, pour valider toute la chaîne. Les paramètres sont assez simples. Il faut renseigner d’un côté l’URL du serveur REST et de l’autre adresse/port sur lesquels on veut que l’exporter accepte les requêtes de Prometheus.

Par défaut c’est localhost donc il est fort probable que vous vouliez changer ça.

/usr/share/jitsi-videobridge/go/bin/jitsiexporter --url='http://127.0.0.1:8080/colibri/stats' --host=192.168.1.100 --port=9700

Un service pour automatiser le démarrage au… démarrage

Comme d’habitude, une fois qu’on a l’exporter qui marche oneshot, le mieux c’est quand même d’avoir un service systemd` qui va nous faciliter le démarrage/l’extinction du service :

cat > /etc/systemd/system/jitsiexporter.service << EOF
[Unit]
Description=Jitsi videobridge Prometheus Exporter
After=jitsi-videobridge2.service
Requires=jitsi-videobridge2.service
[Service]
User=jvb
Restart=on-failure
ExecStart=/usr/share/jitsi-videobridge/go/bin/jitsiexporter --url='http://127.0.0.1:8080/colibri/stats' --host=192.168.1.100 --port=9700
[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable jitsiexporter
systemctl start jitsiexporter

Configurer Prometheus

Vous l’avez compris, il reste donc maintenant à relier Prometheus à notre exporter pour commencer à scrapper des métriques. Ici, il s’agira donc simplement d’ajouter une nouvelle section “job” dans notre configuration de Prometheus et à redémarrer pour prise en compte.

vi /usr/share/prometheus/prometheus.yml
[...]
- job_name: 'jitsi'
static_configs:
- targets:
- 192.168.1.100:9700 # jitsiexporter for jitsi videobridge

systemctl restart prometheus

Et le résultat ?

Bon, faut avouer que c’est pas foufou, j’ai eu quelques conférences en 2 semaines (pas beaucoup plus d’une par jour), mais un joli score tout de même cette conf d’1h30 avec au max 10 personnes !

Vous savez tout ! Have fun :D

Sources additionnelles

Découvrir Prometheus et Grafana par l’exemple

Mon, 13 Apr 2020 06:40:00 +0000

Grafana et Prometheus

Ça fait plusieurs articles que je vous parle de Prometheus et de Grafana, notamment pour l’installer. Mais je n’avais pas encore pris le temps de faire un article pour vous montrer comment les utiliser (et pourquoi ces deux outils sont géniaux) !

Typiquement, ça va nous permettre de réaliser ce genre de dashboard, qui permettra aux équipes (production, dev, voire même équipes fonctionnelles) de voir en un coup d’œil si tout va bien ou au contraire, ce qui va mal.

Un cas utile

Et tant qu’à présenter les outils, je me suis dis que j’allais utiliser un des exemples que j’avais eu à mettre en place dans la vraie vie : tester que mes déploiements Kubernetes respectent bien l’anti-affinité.

Cet exemple est volontairement “un peu complexe”, car il a vocation à vous permettre d’appréhender d’un seul coup plusieurs concepts qui seront utiles pour bien débuter dans Grafana et Prometheus. Notamment, la sélection de la bonne métrique, le langage PromQL, l’ajout de variables dans les dashboards, etc.

Note : Pour ceux qui ne l’ont pas, dans l’orchestrateur de containers Kubernetes, il est possible d’indiquer à l’outil que 2 replicas d’une même application (pour la redondance) ne doivent pas être exécutée sur la même ressource. Ça permet entre autre de garantir qu’il n’y a pas un SPOF au niveau de l’hôte qui exécute les containers alors qu’on croit avoir une application redondante.

Trouver les métriques dans Prometheus

Je vais partir du principe que vous avez déjà une plateforme opérationnelle, équipée d’un Prometheus et d’un Grafana. Si ce n’est pas le cas, je vous invite à faire une rapide recherche sur votre moteur de recherche préféré ou de consulter mes précédents articles sur le sujet.

La première étape avant de commencer à essayer de monter de beaux dashboards consiste à chercher la métrique qui nous intéresse. Car, il faut bien l’admettre, généralement Prometheus en collecte BEAUCOUP !

Rien que Prometheus lui même expose et stocke plus de 700 métriques

On va donc se connecter sur notre serveur Prometheus, puis requêter l’ensemble des métriques disponibles pour en trouver une qui permette de répondre simplement à notre problème. Pour reprendre l’exemple que j’ai choisi, je veux :

pour tous les Pods
m’assurer que plusieurs Pods d’un même déploiement ne sont pas exécuté sur le même serveur

Pour ça, j’ai donc besoin d’avoir une métrique qui me permettre d’avoir tous les Pods, un information sur le Deploiement concerné, ainsi que le Node sur lequel le Pod est exécuté.

container_last_seen

Il y a probablement plusieurs façon de répondre à cette interrogation, mais une des solutions qui marchent plutôt bien pour moi est d’utiliser la métrique container_last_seen.

En recherchant des métriques dans la console de Prometheus, j’ai pu remarquer que cette métrique donne, pour tous les containers, la date à laquelle il a été vu pour la dernière fois, ainsi qu’un certain nombre d’information sur chaque container.

On valide sur un cas particulier

Pour vérifier que la métrique que je vous indique répond bien à notre problème, je vous propose de tester avec un exemple.

La requête PromQL suivante permet d’afficher les containers responsable de la résolution DNS interne de mon Kubernetes (déployé dans le namespace kube-system) :

container_last_seen{container_name=~".*dns.*",namespace=~"kube-system"}
container_last_seen{[...],container_name="dns",instance="node1",namespace="kube-system",pod_name="coredns-xxxxxxxx-yyyyy",[...]} 1577569793
container_last_seen{[...],container_name="dns",instance="node2",namespace="kube-system",pod_name="coredns-xxxxxxxx-zzzzz",[...]} 1577566730
container_last_seen{[...],container_name="dns",instance="node3",namespace="kube-system",pod_name="coredns-xxxxxxxx-aaaaa",[...]} 1577569313

Pour ceux qui débutent en PromQL, il s’agit du langage de requêtage de Prometheus, et qui permet entre autre de filtrer les timeseries affichées en fonction de critères (listés dans la partie entre les accolades).

Dans les résultats de la requête, on a bien :

le nom de notre Deployment (container_name)
le nom de l’hôte qui héberge le container (instance)
le nom du Pod (pod_name)
le namespace

Créer notre visualisation dans Grafana

Maintenant qu’on a trouvé la métriques qui nous intéresse, on peut aller dans Grafana et créer un nouveau Dashboard

Puis un nouveau Panel dans notre Dashboard fraîchement créé :

A partir de là, on pourrait directement afficher les données de notre métrique, mais ça ne serait pas très informatif. On serait noyé sous une masse de conteneurs, chacun avec leurs variables.

Bref, on va devoir restreindre tout ça, notamment via des variables, pour que ça devienne exploitable !

Il y en a beaucoup trop

Dans la capture que j’ai faite juste avant, j’ai quand même été obligé de restreindre à un seul namespace, pour ne pas noyer Prometheus et Grafana. Et encore, c’est (toujours) parfaitement inexploitable.

Clairement, on ne va pas vouloir se contenter d’une sélection “statique” des namespaces, au risque de devoir faire un graphique par namespace Kubernetes (et vous en avez peut être beaucoup).

On va donc récupérer la liste des namespaces disponibles dans Prometheus et l’afficher dans une liste déroulante dans notre Dashboard. Cette liste permettra de filtrer les données par namespace pour ne pas faire planter Prometheus.

Les variables dans le Dashboard

Pour se faire, on va devoir de nouveau trouver la valeur la plus adaptée dans notre source de données Prometheus.

Je ne vais pas vous faire retourner dans Prometheus pour ça, celle que moi j’utilise, c’est celle ci :

kube_namespace_labels{namespace!~"kube-.*|default"}

Cette requête PromQL permet de lister l’ensemble des namespaces présents dans votre cluster Kubernetes, puis, entre les accolades, de filtrer pour retirer les namespaces respectant les regexp “kube-.*” et “default”.

Pour autant, on est pas encore complètement sorti d’affaire puisqu’on doit maintenant récupérer uniquement la partie rouge dans ma capture d’écran, qui est la liste des noms des namespaces.

Arrive alors Grafana, qui fournit une fonction supplémentaire label_values, et qui permet, à partir d’une liste des timeseries Prometheus, de récupérer la valeur d’un seul champ de la timeserie :

label_values(kube_namespace_labels{namespace!~"kube-.*|default"},namespace)

Et tant qu’a y être, on va également se garder sous le coude une autre requête, quasiment identique, mais qui va nous permettre d’avoir la liste des déploiements présents dans votre cluster pour un (ou plusieurs) namespaces donnés :

label_values(kube_deployment_labels{namespace=~"$k8snamespace"}, deployment)

A partir de là, je peux ajouter des Variables dans mon Dashboard. Pour le faire, on doit cliquer sur la roue crantée en haut à droite de notre Dashboard :

Puis ouvrir le menu “Variables” et ajouter les variables

A partir du moment où votre source de données et votre requête est entrée dans les champs Data source et query, Grafana va vous donner un aperçu des valeurs qui seront disponibles (tout en bas du formulaire). Un bon moyen de vérifier que tout est bon avant de passer à l’étape suivante.

Dans le dashboard, nos variables apparaissent !

On sauvegarde et on retourne dans notre Dashboard.

Si tout s’est bien passé, on a maintenant, en haut de notre Dashboard, plusieurs variables avec des menus déroulant pour les sélectionner.

Mais ce n’est pas magique pour autant…

Point un peu pénible, on va devoir maintenant modifier toutes nos visualisations (graphiques) pour prendre en compte le fait qu’on ajoute une variable.

Je ne saurai donc que trop vous conseiller de bien réfléchir à comment vous allez variabiliser vos Dashboard avant d’avoir trop de visualisation statiques…

Ajout de la variable dans notre visualisation

On va donc ajouter la variable de manière à rendre nos graphiques dynamiques en fonction des valeurs sélectionnées dans le Dashboard, en modifiant la requête précédente par celle ci :

container_last_seen{namespace=~"$k8snamespace",container_name=~"$k8sdeployment.*",container_name!="POD"}

Qu’est ce qui a changé ?

Déjà, votre requête devrait répondre beaucoup plus vite ! Et pour cause, on vient non seulement de restreindre à un seul namespace (celui correspondant à la variable Grafana $k8snamespace et non plus la valeur fixe “kube-system”) mais aussi à un seul Deployment donné (via $k8sdeployment).

Note: on a également dégagé les containers s’appelant “POD”, qui vont fausser les statistiques.

Pour autant, notre graphique n’est toujours pas exploitable… On voit bien qu’il existe 2 Pods pour mon Deployment, et si on cherche bien on pourra voir dans la timeserie sur quel Node chaque replica tourne, mais c’est fastidieux…

La valeur de chaque timeserie monte de manière constante. C’est normal, c’est un « uptime »

Compter le nombre de Pod par Node

On va s’en sortir en tirant parti d’une autre variable présente dans nos timeseries (qu’on a justement remarqué plus haut) : instance, ainsi que d’une fonction d’aggrégation du PromQL : count.

Cette variable permet, dans notre requête de savoir sur quel Node Kubernetes se situe notre Pod.

Voilà ce qu’on obtiendra en modifiant la requête de notre visualisation :

count(container_last_seen{namespace=~"$k8snamespace",container_name=~"$k8sdeployment.*",container_name!="POD"}) by (instance)

Avec restriction sur le déploiement

Là, c’est encore fastidieux, mais on commence à entrevoir la réponse à notre question initiale. Dans les derniers graphiques, les couleurs représentent les Nodes Kubernetes, et la valeur numérique le nombre de Pods qui tournent dessus pour un Namespace donné. On voit donc que globalement, pour cet exemple précis, les Pods semblent bien répartis (puisque qu’on sélectionne un seul Deployment, on a bien un Pod par Node).

Et la solution ?

Comment on fait pour voir tous les déploiements d’un coup ? Là, ça commence à devenir un peu plus touchy.

En vrai, la solution n’a plus vraiment d’intérêt en terme de découverte dans l’utilisation de Prometheus et de Grafana, dont j’ai montré les fonctionnalités lors des précédents paragraphes. Cependant, je ne vais pas vous laisser sur un cliffhanger ;-)

Je ne vais tout détailler, mais dans l’idée, la solution que j’ai trouvée (il y en a peut être de plus élégantes) est :

de lister tous les couples nom du déploiement + nom de l’hôte qui l’héberge
de regrouper par déploiement les items de la liste précédente et d’en faire une somme pour chaque déploiement
de diviser chacun des items de cette dernière liste par le nombre total de container par déploiement
d’afficher la liste des valeurs inférieures à 1

1. count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance))
2. count(count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance)) by (container_name)
3. count(count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance)) by (container_name) / count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name)
4. count(count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance)) by (container_name) / count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name) < 1

Ainsi, avec cette dernière formule, on peut lister l’ensemble des Deployments Kubernetes dont il existe un nombre de replica supérieur au nombre de Nodes qui les hébergent (et donc, de dénicher des soucis sur l’anti-affinités et par extension, de potentiels SPOF).

CQFD :-D

Proxmox VE + Prometheus = <3

Mon, 06 Jan 2020 07:15:00 +0000

Proxmox et Prometheus sont dans un bateau…

Si vous avez suivi le précédent article sur Prometheus et Grafana, vous m’avez peut être vu teaser cet article.

En effet, j’avais mis une capture d’écran d’un dashboard Grafana avec des métriques provenant de mon cluster Proxmox VE :

On fait du LXC à fond ici !caption>

Petit récap’

Pour rappel, dans le tuto précédent, on avait installé le couple Grafana + Prometheus sur une machine virtuelle (ou physique peu importe), et pas dans un container (comme le préconise la plupart des billets de blogs que j’ai pu lire). Maintenant vous comprenez surement mieux pourquoi ;-).

Pour alimenter notre Prometheus, on va donc vouloir le donner à manger. Et quoi de mieux dans une infrastructure non containerisée que les métriques de l’hyperviseur ?

prometheus-pve-exporter

On est plutôt gâté avec Proxmox VE, car les métriques pertinentes sont assez nombreuses et surtout exposées par API.

S’il n’existe pas d’exporter officiel, il existe néanmoins des implémentations Open Source réalisées par de gentils contributeurs.

La plus utilisée semble être celle de znerol, qui a en plus l’avantage d’être la base utilisée dans un dashboard sur le site de Grafana (on y reviendra). Dans la mesure du possible, j’essaye de rester sur les implémentations les plus couramment utilisées. Sauf exception, ça permet d’éviter d’être le seul à avoir un bug. Je vous ai mis une autre implémentation dans les sources en bas d’article, que je n’ai pas testée.

Les sources et la documentation sont disponibles sur Github à l’adresse suivante : github.com/znerol/prometheus-pve-exporter

Prérequis

Dans tous les cas, on va devoir créer un utilisateur dans Proxmox VE, a qui on va autoriser l’accès aux métriques depuis l’API. C’est cet utilisateur qu’utilisera notre exporter pour se connecter à PVE, récupérer les métriques et enfin les exposer au format OpenMetrics.

Sur un des serveurs PVE du cluster :

créer un groupe
ajouter le rôle PVEAuditor au groupe
créer un utilisateur
lui ajouter le groupe, puis un mot de passe

pveum groupadd monitoring -comment 'Monitoring group'
pveum aclmod / -group monitoring -role PVEAuditor
pveum useradd pve_exporter@pve
pveum usermod pve_exporter@pve -group monitoring
pveum passwd pve_exporter@pve

Installation de l’exporter

A partir de là, on peut installer l’exporter sur nos serveurs PVE. L’avantage du cet exporter c’est qu’il sait gérer le cluster. Je veux dire par là qu’avec un seul exporter vous allez pouvoir collecter l’ensemble des métriques de l’ensemble de vos machines du cluster (containers, VMs, stockage, hyperviseurs, …).

En théorie, il n’est donc nécessaire de l’installer que sur une machine. Pour autant, je vous conseille quand même d’installer un exporter par serveur. Dans les faits, cela vous évitera de perdre toute collecte de données de supervision en cas de panne du seul serveur portant l’exporter.

Sur vos serveurs PVE, lancer les commandes suivantes :

apt-get install python-pip
pip install prometheus-pve-exporter

Cette implémentation utilise le gestionnaire de paquet de Python, pip.

On va ensuite créer un fichier de configuration qui va contenir les informations de connexion à notre PVE :

mkdir -p /usr/share/pve_exporter/
cat > /usr/share/pve_exporter/pve_exporter.yml << EOF
default:
user: pve_exporter@pve
password: myawesomepassword
verify_ssl: false
EOF

Note : remplacer myawesomepassword par un mot de passe vraiment cool.

Temporairement, vous pouvez lancer le binaire manuellement pour voir si ça fonctionne correctement :

/usr/local/bin/pve_exporter /usr/share/pve_exporter/pve_exporter.yml

Si tout s’est bien passé, on va maintenant créer un script de démarrage systemd pour que notre exporter se démarre tout seul avec l’hyperviseur :

cat > /etc/systemd/system/pve_exporter.service << EOF
[Unit]
Description=Proxmox VE Prometheus Exporter
After=network.target
Wants=network.target
[Service]
Restart=on-failure
WorkingDirectory=/usr/share/pve_exporter
ExecStart=/usr/local/bin/pve_exporter /usr/share/pve_exporter/pve_exporter.yml 9221 192.168.1.1
[Install]
WantedBy=multi-user.target
EOF

Note : remplacer 192.168.1.1 par l’adresse IP de votre serveur Proxmox VE (aussi accessible par votre serveur Prometheus)

systemctl daemon-reload
systemctl enable pve_exporter
systemctl start pve_exporter

La collecte

On a maintenant un endpoint au format OpenMetrics qui peut être collecté par Prometheus. Cool !!

Le but du jeu va être maintenant d’informer Prometheus qu’il doit scrapper notre exporter. On va faire ça en ajoutant la configuration suivante à notre serveur Prometheus (puis le redémarrer) :

vi /usr/share/prometheus/prometheus.yml
[...]
scrape_configs:
[...]
- job_name: 'pve'
static_configs:
- targets:
- 192.168.1.1:9221 # Proxmox VE node with PVE exporter.
- 192.168.1.2:9221 # Proxmox VE node with PVE exporter.
metrics_path: /pve
params:
module: [default]
systemctl restart prometheus.service

Note : remplacer les IPs par les adresses IP de vos exporters sur vos serveurs PVE.

Visualiser tout ça

Dernière étape avant d’aller prendre un café, afficher tout ça dans un dashboard. Là ça aurait pu être trivial mais j’ai du bidouiller (un tout petit peu).

Je l’ai dis au début de l’article, un des avantages de cet exporter, c’est que quelqu’un a pris la peine de faire un dashboard dans Grafana qui affiche déjà tout sans qu’on ait besoin de faire quoique ce soit.

On peut donc l’installer juste en copiant l’URL ou l’ID dans notre Grafana 10347

Trivial !

La seule petite difficulté, c’est que ce Dashboard gère mal le clustering. Plus particulièrement, il n’aime pas qu’un meme exporter remonte les données de plusieurs nodes, ce qui est dommage pour un cluster.

J’ai donc tweaké le Dashboard en y ajoutant une variable “node”, permettant de sélectionner les métriques du node qu’on veut (uniquement).

Enfin, j’ai modifié les graphiques concernés en ajoutant un filtre de type id="node/$node" utilisant cette variable dans la requête PromQL.

Vous avez maintenant un Dashboard qui remonte les métriques de vos serveurs, stockages, vms et containers dans Proxmox VE ! A vous l’observabilité !

Sources

Une autre implémentation : wakeful/pve_exporter

[Tutoriel] Installer Prometheus/Grafana sans Docker

Tue, 12 Nov 2019 07:30:45 +0000

Prometheus et Grafana dans Docker, quelle horreur ?

Je sais que certains d’entre vous ne sont pas super fan (euphémisme) de la technologique containers Docker (et je ne parle même pas de Kubernetes, cf Concerning Kubernetes). Pour autant, pas besoin de Docker pour avoir besoin du couple Prometheus / Grafana.

Prometheus a plein de features sympas (notamment l’auto discovery, le langage de requêtage PromQL, …). De son côté, Grafana est vraiment top pour ce qui est visualisation rapide provenant de plusieurs sources de données.

Peut être même que vous avez du Docker (ou même Kubernetes) mais que vous n’avez pas envie d’intégrer la supervision dans votre infra de compute.

Il y a plein de bonnes raisons pour ça, comme ne pas vouloir héberger la supervision sur l’infra qu’elle est censé surveillée ou encore pour des problématiques de performances, …

Avec Docker, lancer Prometheus ou Grafana se fait en une ligne de commande, c’est pour ça qu’on voit cette manière de faire partout. Sans Docker, c’est nécessairement un poil plus compliqué (mais à peine) à faire. Et c’est pourquoi je fais ce petit tuto rapide.

Prometheus

Dans ce tuto, on va partir des sources. Pour Prometheus, vous pourrez trouver un raccourci vers la dernière version sur le site officiel.

On télécharge cette version et on configure un utilisateur exécuter Prometheus

wget https://github.com/prometheus/prometheus/releases/download/v2.13.1/prometheus-2.13.1.linux-amd64.tar.gz
tar xzf prometheus-2.13.1.linux-amd64.tar.gz
sudo mv prometheus-2.13.1.linux-amd64/ /usr/share/prometheus
sudo useradd -u 3434 -d /usr/share/prometheus -s /bin/false prometheus
sudo mkdir -p /var/lib/prometheus/data
sudo chown prometheus:prometheus /var/lib/prometheus/data
sudo chown -R prometheus:prometheus /usr/share/prometheus

Une fois que c’est fait, le mieux c’est de tester que Prometheus “fonctionne” correctement en le lançant à la main pour voir si le logiciel se lance bien, avec la configuration par défaut.

/usr/share/prometheus/prometheus --config.file=/usr/share/prometheus/prometheus.yml
[...]
level=info ts=2019-09-20T14:56:18.244Z caller=main.go:768 msg="Completed loading of configuration file" filename=/usr/share/prometheus/prometheus.yml
level=info ts=2019-09-20T14:56:18.244Z caller=main.go:623 msg="Server is ready to receive web requests."

Ici tout s’est bien passé, on peut donc le couper (Ctrl-C) et créer un script SystemD pour pouvoir le démarrer automatiquement avec le serveur.

sudo vi /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target
[Service]
User=prometheus
Restart=on-failure
WorkingDirectory=/usr/share/prometheus
ExecStart=/usr/share/prometheus/prometheus --config.file=/usr/share/prometheus/prometheus.yml
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus
sudo systemctl status prometheus

Grafana

Maintenant que c’est fait, on passe à Grafana. Vous allez voir, ça va aussi vite.

Dans le cas de Grafana, la méthode mise en avant sur le site officiel est l’utilisation des packages systèmes (".deb" pour Debian ou Ubuntu, RPM pour CentOS). Par souci de cohérence dans l’article, je ne vais pas utiliser le .deb et installer le binaire précompilé pour l’installer de la même manière que Prometheus. Cependant, le .deb aurait très bien fait l’affaire (et ça ira plus vite si vous êtes pressés).

On télécharge donc la version précompilée, on positionne les bons dossiers/binaires/fichiers de config aux bons endroits.

wget https://dl.grafana.com/oss/release/grafana-6.4.4.linux-amd64.tar.gz
tar -xzf grafana-6.4.4.linux-amd64.tar.gz
sudo useradd -d /usr/share/grafana -s /bin/false grafana
sudo mkdir -p /var/lib/grafana/plugins /etc/grafana /var/log/grafana
sudo chown -R grafana:grafana /var/lib/grafana
sudo mv grafana-6.4.4/ /usr/share/grafana
sudo cp /usr/share/grafana/bin/grafana-server /usr/sbin/
sudo cp /usr/share/grafana/conf/sample.ini /etc/grafana/grafana.ini

On configure systemD puis on démarre le service.

sudo vi /etc/default/grafana-server
GRAFANA_USER=grafana
GRAFANA_GROUP=grafana
GRAFANA_HOME=/usr/share/grafana
LOG_DIR=/var/log/grafana
DATA_DIR=/var/lib/grafana
MAX_OPEN_FILES=10000
CONF_DIR=/etc/grafana
CONF_FILE=/etc/grafana/grafana.ini
RESTART_ON_UPGRADE=true
PLUGINS_DIR=/var/lib/grafana/plugins
PROVISIONING_CFG_DIR=/etc/grafana/provisioning
PID_FILE_DIR=/var/run/grafana

sudo vi /etc/systemd/system/multi-user.target.wants/grafana-server.service
[Unit]
Description=Grafana instance
Documentation=http://docs.grafana.org
Wants=network-online.target
After=network-online.target
After=postgresql.service mariadb.service mysql.service
[Service]
EnvironmentFile=/etc/default/grafana-server
User=grafana
Group=grafana
Type=simple
Restart=on-failure
WorkingDirectory=/usr/share/grafana
RuntimeDirectory=grafana
RuntimeDirectoryMode=0750
ExecStart=/usr/sbin/grafana-server \
--config=${CONF_FILE} \
--pidfile=${PID_FILE_DIR}/grafana-server.pid \
cfg:default.paths.logs=${LOG_DIR} \
cfg:default.paths.data=${DATA_DIR} \
cfg:default.paths.plugins=${PLUGINS_DIR} \
cfg:default.paths.provisioning=${PROVISIONING_CFG_DIR}
LimitNOFILE=10000
TimeoutStopSec=20
UMask=0027
[Install]
WantedBy=multi-user.target

systemctl start grafana-server
systemctl enable grafana-server
systemctl status grafana-server
[...]
Nov 10 15:40:17 nostromo grafana-server[14606]: t=2019-11-10T15:40:17+0000 lvl=info msg="Initializing Stream Manager"
Nov 10 15:40:17 nostromo grafana-server[14606]: t=2019-11-10T15:40:17+0000 lvl=info msg="HTTP Server Listen" logger=http.server address=0.0.0.0:3000 protocol

On cable le tout ensemble

Vous avez vu, je vous avais pas menti, c’est assez simple en fait.

Maintenant que Prometheus et Grafana tournent, on va les coufigurer pour qu’ils parlent ensemble.

Tout se passe sur l’interface d’administration de Grafana, qui devrait maintenant être accessible à l’URL http://@IP_de_votre_serveur:3000

Authentifiez vous en tant qu’administrateur. Par défaut à la première instanciation, seul un compte “admin” est créé, avec le mot de passe hautement sécurisé “admin”. Heureusement on change ça tout de suite…

La dernière étape consiste à simplement se rendre dans la partie administration de Grafana, puis de créer un source de données.

Il existe de nombreuses sources de données différentes. Nous dans notre cas, c’est bien une source de type Prometheus qu’on veut créer.

Renseignez simplement l’URL d’accès à Prometheus (par défaut http://localhost:9090 dans ce tutoriel) et sauvez.

A partir de maintenant, vous avez un couple Prometheus / Grafana fonctionnel. Vous allez pouvoir commencer à créer des Dashboard.

Enjoy !