Prometheus on Zwindler's Reflection

Optimisation des ressources Kubernetes avec l’autoscaling horizontal des pods via des custom metrics et le Prometheus Adapter

Fri, 11 Oct 2024 10:00:00 +0200

Introduction

Note : cet article a été co-écrit avec mon ex-collègue Gaby Fulchic, alias Weeking.

Si vous avez vécu dans une grotte ces 10 dernières années et que vous n’avez jamais entendu parler de Kubernetes, eh bien… je vous invite à consulter mes autres articles sur le sujet xD.

Dans cet article, j’ai eu envie de creuser une fonctionnalité qui existe depuis un moment, mais dont j’ai rarement eu besoin : les HorizontalPodAutoscalers, en particulier via l’usage de custom metrics.

Prêt à scaler ? C’est parti !

C’est quoi diantre que l’autoscaling horizontal des pods (HPA) ???

L’HorizontalPodAutoscaler est une fonctionnalité de Kubernetes. Elle permet de spécifier, pour des métriques données sur un groupe de Pods, d’essayer d’atteindre des valeurs cibles. L’utilisation la plus basique de cette fonctionnalité est, vous l’aurez deviné, de “scaler” des Pods en fonction de métriques basiques, par exemple la consommation CPU.

Comme tout dans Kubernetes, il s’agit d’une API (actuellement autoscaling/v2). La manière la plus simple d’interagir avec elle est de créer un fichier manifest YAML où vous décrivez l’état souhaité de votre application en fonction de la charge.

Par défaut, seules des métriques simples, la consommation CPU et mémoire (celles collectées par metrics-server) sont disponibles afin de spécifier les règles de scaling.

Un exemple simple pourrait ressembler à ceci :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: myapp-hpa
 namespace: mynamespace
spec:
 maxReplicas: 6
 metrics:
 - resource:
 name: cpu
 target:
 averageUtilization: 50
 type: Utilization
 type: Resource
 minReplicas: 2
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: myapp

Note : Les spécifications HPA peuvent être incroyablement plus complexes et puissantes, car l’API s’est considérablement enrichie au fil des années. N’hésitez pas à aller lire la documentation officielle ;-).

Sur la base de l’exemple précédent, une fois le manifest appliqué, Kubernetes tentera de maintenir une utilisation moyenne du CPU autour de 50 % sur tous les pods “myapp” et ajoutera des replicas si la consommation moyenne de CPU dépasse ce seuil. Dès que la consommation CPU descend en dessous de la cible, Kubernetes réduit le nombre de replicas, jusqu’à atteindre le nombre minimal si nécessaire.

Bon, ça, c’est la théorie. Mais d’expérience, l’utilisation de HPA de cette manière présente des limites :

Les applications modernes ont souvent des caractéristiques de performance complexes qui sont imparfaitement décrites par l’utilisation du CPU et de la RAM seules. Par exemple, une application peut être limitée par les entrées/sorties (I/O). D’autres facteurs comme la latence des requêtes, des métriques métier ou des indicateurs sur des dépendances externes (le nombre de messages dans une queue, par exemple) peuvent fournir une meilleure base pour les décisions de scaling.
L’utilisation du CPU peut également être très élevée lors du « boot » d’un nouveau pod, ce qui peut entraîner plus de scaling que nécessaire (on, parle de boot storm sur les infrastructures plus classiques, je trouve le terme approprié).

L’HorizontalPodAutoscaler réagit aux métriques récupérées à un moment donné, ce qui signifie qu’il peut y avoir un décalage entre le pic de la métrique et la réponse de scaling. Cela peut entraîner une dégradation temporaire des performances. Trouver des métriques permettant d’anticiper le besoin de scaling plutôt que de réagir après une dégradation est donc l’objectif à garder en tête pour améliorer la fiabilité de nos apps.

Pour pallier ces limitations, Kubernetes permet l’utilisation de custom metrics offrant une plus grande flexibilité et un meilleur contrôle sur le comportement du scaling des applications. C’est là qu’interviennent des outils comme Prometheus et le Prometheus Adapter, qui vont nous permettre des stratégies d’autoscaling plus adaptées / efficaces.

Prometheus et les métriques via `/-/metrics`

Comme Kubernetes, Prometheus est un autre des grands projets sous l’égide de la CNCF. C’est un outil de collecte de métriques, qui dispose d’une base de données de séries temporelles (TSDB) optimisée pour stocker des métriques d’infrastructure et d’un langage de requête permettant des analyses profondes faciles, mais puissantes de ces métriques. Là aussi, j’ai déjà écrits plusieurs articles sur le sujet.

En général, on classe les outils de supervision dans deux grandes catégories. Ceux qui reçoivent les métriques des clients qui les « push » et ceux qui « pull » périodiquement les métriques des applications elles-mêmes. Prometheus utilise la stratégie de “pull” (la plupart du temps) et, par défaut, il va collecter nos métriques toutes les 30 secondes.

Cela signifie que vous n’avez pas besoin d’installer un « agent » sur vos applications MAIS que vous devez spécifier à Prometheus une liste de « cibles » qui exposent des points de terminaison HTTP (vos applications) servant des métriques dans un format spécifique, généralement sur le chemin /-/metrics :

$ kubectl -n mynamespace port-forward myapp-5584c5c8f8-gbsw8 3000
Forwarding from 127.0.0.1:3000 -> 3000
Forwarding from [::1]:3000 -> 3000

# dans un autre terminal
$ curl localhost:3000/-/metrics/ 2> /dev/null | head
# HELP http_request_duration_seconds duration histogram of http responses labeled with: status_code method path
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.0002"status_code="200"method="GET"path="/-/health"} 0
http_request_duration_seconds_bucket{le="0.0005"status_code="200"method="GET"path="/-/health"} 364
[...]

Nous pouvons ensuite interroger Prometheus pour obtenir ces métriques en spécifiant le nom de la métrique et en ajoutant des labels pour préciser quel sous-ensemble nous intéresse :

http_request_duration_seconds_bucket{kubernetes_namespace='mynamespace' kubernetes_pod_name="myapp-5584c5c8f8-gbsw8"}

Je vais partir du principe que vous avez un Prometheus disponible sur votre cluster pour la suite de l’article (sinon, allez jeter un œil au Prometheus Operator).

Grâce à Prometheus, nous avons maintenant une multitude de métriques parmi lesquelles choisir afin de prédire si nos applications doivent être mises à l’échelle de manière proactive. Cependant, le problème est que nous ne pouvons pas dire au HPA de surveiller directement ces métriques, car le HPA n’est pas directement compatible avec le langage de requête Prometheus PromQL.

Prometheus Adapter à la rescousse

Nous avons donc besoin d’un autre outil qui récupérera les métriques depuis Prometheus et les fournira à Kubernetes. Vous avez deviné de quel logiciel il s’agit maintenant : Prometheus Adapter.

On va l’installer à partir d’une chart Helm hébergée sur le dépôt prometheus-community :

$ helm show values prometheus-community/prometheus-adapter > values.yaml

$ helm install -n monitoring prometheus-adapter prometheus-community/prometheus-adapter -f values.yaml

$ kubectl -n monitoring get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
metrics-server 2/2 2 2 1d
prom-operator-kube-state-metrics 1/1 1 1 1d
prom-operator-operator 1/1 1 1 1d
prometheus-adapter 1/1 1 1 1d
prom-operator-query 3/3 3 3 1d

Dans cet exemple, vous pouvez voir que j’ai déjà déployé metrics-server et Prometheus en utilisant Prometheus Operator, et que Prometheus Adapter est en cours d’exécution.

Par défaut, Prometheus Adapter sera déployé avec certaines custom metrics que nous pouvons utiliser “out of the box” pour scaler nos applications plus précisément. Mais dans cet article, nous allons vous montrer comment créer ✨ vos propres ✨ métriques.

Configurer Prometheus Adapter pour exposer des custom metrics via l’API Server

Au départ, la configuration de Prometheus Adapter ne contient aucune règle. Cela signifie qu’aucune métrique personnalisée n’est exposée via l’API Server au début, et que HPA ne peut pas utiliser de custom metrics.

Prometheus Adapter fonctionne dans cet ordre :

Découvrir des métriques en contactant Prometheus
Les associer aux ressources Kubernetes (namespace, pod, etc.)
Vérifier comment les exposer (si nécessaire, il peut renommer les métriques)
Vérifier comment interroger Prometheus pour obtenir les valeurs réelles (ex. obtenir un “rate”).

D’abord, nous devons valider l’API des custom metrics sur notre cluster. La liste resources sera vide, mais cela prouve que l’API custom.metrics.k8s.io/v1beta1 est accessible.

└─[$] kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq
{
 "kind": "APIResourceList",
 "apiVersion": "v1",
 "groupVersion": "custom.metrics.k8s.io/v1beta1",
 "resources": []
}

Il faut ensuite plusieurs étapes pour que Prometheus Adapter collecte et fournisse des métriques au serveur API de Kubernetes. Toute la configuration de Prometheus Adapter peut être ajustée via le fichier values.yaml de la chart Helm.

La première chose à configurer ici est « où » Prometheus Adapter peut contacter Prometheus. Si Prometheus Adapter est exécuté sur le même cluster que la stack Prometheus, vous pouvez utiliser un enregistrement DNS interne (à Kubernetes) comme ci-dessous (voir la documentation Kubernetes DNS pour les services et pods). Sinon, vous pouvez spécifier une adresse IP (ou un nom DNS) et un numéro de port.

values.yaml > prometheus:
 url: http://prom-operator-query.monitoring.svc
 port: 9090
 path: ""

Pour vérifier que Prometheus Adapter peut correctement contacter Prometheus, il vous suffit de vérifier les logs du pod (en utilisant kubectl logs pod/prometheus-adapter-abcdefgh-ijklm ou tout autre moyen à votre disposition pour lire les logs du pod).

Une fois cette partie opérationnelle, nous devons ajouter quelques règles à notre Prometheus Adapter.

Dans cet exemple, j’ai choisi d’utiliser une métrique appelée ELU (pour « Event Loop Utilization ») collectée à partir d’un serveur Node.js. Elle mesure combien de temps la boucle d’événements Node.js est occupée à traiter des événements par rapport à l’inactivité, et elle est plus représentative de la charge du serveur que le simple pourcentage de CPU.

Les règles nous permettent de spécifier quoi interroger dans Prometheus. Nous pouvons définir quels labels importer et, si nécessaire, les remplacer pour correspondre aux noms des ressources Kubernetes. Voici les valeurs les plus utiles à spécifier :

seriesQuery: exécute la requête PromQL, éventuellement filtrée
resources: associe les labels des séries temporelles aux ressources Kubernetes
name: expose les séries temporelles avec des noms différents de ceux d’origine
metricsQuery: méthode pour demander à Prometheus d’obtenir un taux («.GroupBy» signifie “group by Pod” par défaut)

values.yaml > rules:
 default: false
 custom:
 - seriesQuery: 'elu_utilization{kubernetes_namespace!=""kubernetes_pod_name!=""}'
 resources:
 overrides:
 kubernetes_namespace: {resource: "namespace"}
 kubernetes_pod_name: {resource: "pod"}
 name:
 matches: ^elu_utilization$
 as: ""
 metricsQuery: sum(<<.Series>>{<<.LabelMatchers>>}) by (<<.GroupBy>>)

Vous devriez maintenant pouvoir obtenir quelques custom metrics avec des valeurs réelles en accédant au serveur API. Pour tester, nous allons utiliser kubectl et le paramètre --raw, qui nous donne plus de contrôle sur les requêtes envoyées au serveur API.

Voici quelques exemples de commandes que vous pouvez exécuter pour vérifier manuellement que les métriques sont correctement exposées via l’API Server :

# lister la découverte des custom metrics
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq

# lister les valeurs des custom metrics pour chaque pod
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/<namespace_name>/pods/*/elu_utilization" | jq

Attention : le scaling sera fortement dépendant de l’intervalle de scraping de vos métriques et de l’intervalle de découverte de votre Prometheus Adapter. La documentation officielle insiste sur le fait que vous pourriez rencontrer des problèmes si vous mettez une valeur trop basse.

“You’ll need to also make sure your metrics relist interval is at least your Prometheus scrape interval. If it’s less than that, you’ll see metrics periodically appear and disappear from the adapter.”

Comment cela va-t-il fonctionner ?

Jusqu’à présent, nous avons introduit plusieurs composants qui interagissent entre eux.

Mais comment tout cela va-t-il fonctionner sous le capot ? Eh bien, rien de mieux qu’un diagramme pour expliquer des choses comme celle-ci :

Prometheus scrape les métriques exposées par notre application
Prometheus Adapter interroge le serveur Prometheus pour collecter les métriques spécifiques que nous avons définies dans sa configuration
L’HorizontalAutoscaler (le contrôleur qui gère les HPA) interrogera le serveur API pour vérifier périodiquement, si la métrique ELU est dans les limites acceptables…
… qui à son tour demandera à Prometheus Adapter.

Créons maintenant notre premier HorizontalPodAutoscaler !

Utilisation d’une ressource HorizontalPodAutoscaler avec des custom metrics

Au début de ce post, nous avons introduit l’API HorizontalPodAutoscaler. La ressource elle-même n’est pas difficile à utiliser. En gros, HPA prend un déploiement cible à scaler, un nombre minimum de replicas, un nombre maximum de replicas et les métriques à utiliser. Pour la partie métrique, nous allons maintenant utiliser la métrique personnalisée de notre article configurée avec Prometheus Adapter :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
spec:
 maxReplicas: 6
 metrics:
 - pods:
 metric:
 name: elu_utilization
 target:
 averageValue: 500m
 type: Utilization
 type: Pods
 minReplicas: 2
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: <deployment.apps_name>

Lorsque vous configurez une ressource HPA, vous ne définissez que le nom de la métrique. Mais comment HPA peut-il déterminer la bonne métrique des bons pods puisque plusieurs applications peuvent exposer cette même métrique ? Pour comprendre cela, nous pouvons examiner les logs de Prometheus Adapter.

I0618 12:05:29.149095 1 httplog.go:132] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1/n

Comme vous pouvez le voir, un labelSelector est ajouté à la requête. Et comme vous mentionnez le Deployment dans la référence scaleTargetRef de HPA, ce dernier utilise la valeur labelSelector du sélecteur de labels du Deployment. Cela vous permet de cibler les métriques d’un Deployment spécifique. Et ces labels existent parce que, lors du scraping des pods avec Prometheus, la découverte des pods Kubernetes et les annotations ajoutent des labels aux métriques.

Si vous souhaitez utiliser un labelSelector personnalisé dans la requête, ajoutez le champ metrics.pods.metric.selector à la ressource HPA.

Nous avons donc l’API des custom metrics, nous avons configuré Prometheus Adapter pour découvrir et exposer certaines métriques, et nous avons créé notre première ressource HPA. Il est maintenant temps de tester le déploiement sous charge et d’observer le comportement.

Pour cela, nous allons vous présenter un outil nommé Vegeta (it’s over 9000!)

Vegeta is a versatile HTTP load testing tool built out of a need to drill HTTP services with a constant request rate.

Nous allons utiliser Vegeta pour générer une charge sur notre application tout en surveillant les pods de l’application et l’état de l’HPA (avec 3 terminaux ouverts en parallèle) :

kubectl get hpa/<myhpa> -w -n <mynamespace>
kubectl get po -l app=<myapp> -w -n <mynamespace>
vegeta attack <app_endpoint_http>

Note : Dans le cas où votre application peut supporter une charge importante et que les paramètres par défaut ne déclenchent pas de scaling, vous pouvez modifier certains paramètres dans la commande Vegeta. Nous recommandons d’utiliser les options workers et rate :

–workers : nombre initial de workers (par défaut 10)
–rate : nombre de requêtes par unité de temps [0 = infini] (par défaut 50/1s)

Lorsque la charge augmente, la valeur de votre métrique personnalisée augmentera également, ce qui devrait à son tour déclencher une montée en charge du déploiement une fois que les seuils sont atteints.

Utilisation de Prometheus Adapter en production

Lorsque Prometheus Adapter devient un composant central de votre architecture, son tuning et sa surveillance deviennent essentiels.

Si ce composant est HS, votre HPA ne pourra plus réagir. Il y aura deux impacts potentiels : vous utiliserez trop de ressources pour le trafic actuel, ou au contraire, ne pas en avoir assez pour gérer le trafic. Dans tous les cas, vos workloads ne sont pas immédiatement affectés ; ils maintiennent le dernier nombre de replicas calculé par HPA avant la panne.

Pour éviter que cela ne devienne un SPOF, assurez-vous de mettre plus d’une replicas pour Prometheus Adapter. Et je conseille aussi de rajouter un petit PodDisruptionBudget pour éviter les soucis pendant les maintenances de votre cluster.

Conclusion

L’autoscaling horizontal des pods intégré à Kubernetes est un mécanisme standard pouvant potentiellement aider vos apps à gérer efficacement les charges variables. A titre personnel, je trouve le HPA classique, qui utilise les métriques CPU et mémoire, trop limité. Mais avec l’intégration des custom metrics avec Prometheus Adapter, on peut rendre ses décisions de scaling plus précises et pertinentes.

Si l’installation de Prometheus Adapter est simple, sa configuration est, je trouve, un peu contre-intuitive, voire complexe, sans pour autant gérer efficacement les scénarios les plus avancés.

C’est pourquoi je pense que, si vous n’avez pas comme impératif de rester sur le standard Kubernetes, vous devriez jeter un oeil (ou attendre mon prochain article ?) à KEDA (Kubernetes Event-Driven Autoscaling), un autre projet open-source qui étend les capacités de HPA en prenant en charge diverses sources d’événements et déclencheurs de scaling.

Bon scaling !

Sources supplémentaires

Documentation de Prometheus Adapter :

Documentation Kubernetes HPA :

Autre :

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 !

CNCF Bdx #6 : les slides de mon talk Thanos

Thu, 24 Oct 2019 17:00:10 +0000

Ce soir, je donne un talk sur Thanos au CNCF Meetup de Bordeaux. Comme d’habitude, je met à disposition les slides quelques minutes avant. [Le lien du Meetup pour les curieux]

Besoin de métriques Prometheus à long terme ? Thanos fera des Marvels !

Prometheus, aussi puissant soit il, repose sur plusieurs postulats qui ne collent pas avec tous les cas d’usage. Les métriques doivent être stockées sur un medium local et rapide, il faut un serveur par zone (failure domain) et donc potentiellement un grand nombre de serveurs Prometheus indépendants, difficiles à corréler, …

Arrive alors Thanos (rien à voir avec le bonhomme violet avec un gant doré) !

Celui ci va nous permettre de stocker nos métriques infiniment, tout en les rassemblant au sein d’une même source de données et en améliorant la performance de nos requêtes les plus coûteuses.

Les slides, les slides !

Et voilà les slides :-D

CNCF_meetup6_Thanos.pdf

Le podcast, le podcast !

Si je n’oublie pas de lancer l’enregistrement, je mettrais aussi un fichier audio de la conf, en mode podcast :-p.

CNCF Meetup Bordeaux #6 : Tour d’horizon du monitoring dans Kubernetes

Mon, 14 Oct 2019 15:30:18 +0000

CNCF Meetup Bordeaux

Et rebelotte !

Je récidive et vais de nouveau venir vous raconter comment je travaille au CNCF Meetup de Bordeaux (pour rappel, vous pouvez retrouver les slides de mon passage précédent, dans lequel j’avais fais un REX des incidents qu’on a eu sur Kubernetes).

Pour cette 6ème édition, ça se passera le 24 octobre à partir de 19h00 dans les locaux de « Le Wagon » à Bordeaux.

Le lien vers le meetup et l’inscription

Si vous êtes du coin et que vous êtes de passage et que vous voulez échanger avec vos pairs sur les solutions open sources de containérisation et autres sujets ayant trait au cloud, c’est « the place to be ».

Comme d’habitude, attention car les places partent très vite. Généralement, en 2 jours c’est plié…

CNCF ?

Pour rappel, la Cloud Native Computing Foundation, c’est la fondation « spin-off » de la Linux Foundation qui a été créée pour fédérer, piloter, organiser l’ensemble des projets open source ayant trait aux containers, aux microservices et aux services clouds.

The Cloud Native Computing Foundation builds sustainable ecosystems and fostersa community around a constellation of high-quality projects that orchestrate containers as part of a microservices architecture.

Elle a été créée lorsque Google a légué le code de Kubernetes en 2015.

Le programme

A 19H15, Etienne Coutaud, le co organisateur, nous fera son traditionnel « tour des news de l’écosystème CNCF ».

#1 Monitorer mon cluster Kubernetes (quasiment) sans les mains.

A 19h30, Etienne embraye sur la supervision avec Prometheus dans Kubernetes

Il est impensable de mettre une plateforme en production sans monitoring, ceci est aussi vrai pour du Kubernetes managé ou non. Kubernetes est conçu pour s’intégrer parfaitement avec un autre produit phare de la CNCF Prometheus. Nous verrons durant ce talk comment mettre en œuvre les deux, comment cela s’architecture et comment l’opérer. Nous verrons également comment cette architecture est faite pour nativement accueillir les métriques issus de votre propre code.

#2 Besoin de métriques Prometheus à long terme ? Thanos fera des Marvels !

Et ensuite, c’est mon tour. J’irai un peu plus loin avec Prometheus en vous parlant de Thanos.

Prometheus, aussi puissant soit il, repose sur plusieurs postulats qui ne collent pas avec tous les cas d’usage. Les métriques doivent être stockées sur un medium local et rapide, il faut un serveur par zone (failure domain) et donc potentiellement un grand nombre de serveurs Prometheus indépendants, difficiles à corréler, … Arrive alors Thanos (rien à voir avec le bonhomme violet avec un gant doré) ! Celui ci va nous permettre de stocker nos métriques infiniment, tout en les rassemblant au sein d’une même source de données et en améliorant la performance de nos requêtes les plus coûteuses.

Lier l’utile à l’agréable

A 21h, nous nous retrouverons pour échanger autour d’une bière et d’une part de pizza offert par Gekko (Merci à eux :-D).