monitoring on Zwindler's Reflection

Un nouveau champ `log` pour les network policies Cilium : une idée de use case

Mon, 03 Nov 2025 12:00:00 +0200

TL;DR

Cilium 1.18 a ajouté un champ log aux CiliumNetworkPolicies pour taguer les verdicts de flux (FORWARDED, DROPPED, AUDIT, …) avec des labels personnalisés. Dans l’idée, c’est la fonctionnalité parfaite pour éviter de logger le trafic bloqué que l’on connait dans nos dashboards de monitoring !

Mais il y a un hic, sans rapport avec cette fonctionnalité, qui rend cette idée inutilisable : on ne peut pas l’utiliser avec egressDeny + toFQDNs.

ET, il y a un bug, qui fait que le “log” n’est visible que sur le trafic “autorisé”.

Je vous raconte…

Le problème : monitor all the things (mais pas trop)

Comme toute bonne équipe “ops” qui se respecte, nous monitorons/loggons les flux réseau de notre cluster Kubernetes avec Hubble pour une analyse ultérieure et de l’alerting. Nous (en particulier mon collègue Nicolas Nativel) poussons tous les flux AUDIT et DROPPED vers un dashboard Grafana pour pouvoir rapidement repérer quand quelque chose est bloqué et décider :

C’est légitime ? → On ouvre le flux
C’est suspect ? → On déclenche l’alarme 🚨

Ça fonctionne plutôt bien… jusqu’à ce qu’on commence à bloquer explicitement des choses qu’on sait devoir être bloquées.

Dans notre cas, nous voulions empêcher une application tierce d’envoyer les données de “télémétrie” (ouais, appelons ça comme ça 😏). On parle d’appels HTTPS vers des domaines de tracking externes.

Le problème ? Si on bloque simplement ces flux, ils apparaîtront comme DROPPED dans Hubble, déclencheront notre monitoring, et on se retrouvera avec des alertes pour quelque chose qu’on a intentionnellement bloqué.

C’est du bruit dont on ne veut pas.

Et donc, ce champ log des network policies de Cilium 1.18 ?

Bonne nouvelle ! Cilium 1.18 a introduit exactement ce dont nous avions besoin : la possibilité d’ajouter des champs de log personnalisés aux verdicts sur les network policies.

Cf. l’annonce dans le blogpost officiel.

L’idée est simple : vous ajoutez un champ log.value à votre CiliumNetworkPolicy :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: my-policy
spec:
 endpointSelector:
 matchLabels:
 app: my-app
 egress:
 - toFQDNs:
 - matchName: "example.com"
 log:
 value: "my-custom-log-tag"

Ensuite, quand vous observez les flux dans Hubble, vous pouvez les filtrer en utilisant CEL (Common Expression Language) :

hubble observe \
 --verdict AUDIT \
 --not \
 --cel-expression "(_flow.policy_log.endsWith('my-custom-log-tag'))" \
 --print-raw-filters

Output :

allowlist:
- '{"verdict":["AUDIT"]}'
denylist:
- '{"experimental":{"cel_expression":["(_flow.policy_log.endsWith(''my-custom-log-tag''))"]}}'

Parfait ! Vous savez maintenant taguer les calls que vous avez explicitement bloqués et les exclure de votre monitoring. 🎉

Le plan : bloquer la télémétrie élégamment

À l’aide de cette nouvelle fonctionnalité, nous avons élaboré notre stratégie :

Utiliser egressDeny pour bloquer explicitement les domaines de télémétrie
Ajouter un champ de log personnalisé : app-explicit-traffic-blocked
Configurer Hubble pour filtrer les verdicts de flux avec ce tag
Profit ! 🎉

Voici ce que nous avons essayé :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: app-external-block-policy
 namespace: my-namespace
spec:
 endpointSelector:
 matchLabels:
 app.kubernetes.io/name: my-app
 # note: egressDeny prend la précédence sur les règles egress
 # https://docs.cilium.io/en/stable/security/policy/language/#deny-policies
 egressDeny:
 # Bloquer tout le trafic externe et le logger avec un champ de log arbitraire
 # Ceci est utilisé pour empêcher l'app d'envoyer des données de télémétrie à l'extérieur
 # sans déclencher d'alerte AUDIT/DROPPED
 # fonctionnalité ajoutée dans cilium 1.18.0 https://github.com/cilium/cilium/pull/39902
 - toFQDNs:
 - matchPattern: "*.telemetry.example.com"
 toPorts:
 - ports:
 - port: "443"
 protocol: TCP
 - port: "80"
 protocol: TCP
 log:
 value: "app-explicit-traffic-blocked"

Ça devrait fonctionner, non ? On utilise egressDeny (qui prend la précédence sur les autres règles, ce qui est une bonne chose !), et on le tague avec notre log personnalisé.

Retour à la réalité

Et puis… patatra.

En lisant la documentation Cilium sur les deny policies, nous sommes tombés sur cette petite note de rien du tout :

Deny policies do not support:

policy enforcement at L7, i.e., specifically denying an URL

toFQDNs, i.e., specifically denying traffic to a specific domain name.

Attendez, quoi ?

On ne peut pas utiliser toFQDNs avec egressDeny. Tout notre plan vient de s’effondrer 😱.

Pourquoi c’est un problème, déjà ?

Le problème, c’est le modèle de précédence dans Cilium :

Les règles egressDeny prennent la précédence sur les règles egress (by design, et c’est bien !)
Mais si on utilise egressDeny, on ne peut pas utiliser toFQDNs pour cibler intelligemment le domaine incriminé, on doit bloquer par IP ou CIDR
Ces services de télémétrie utilisent probablement des IPs dynamiques pour leurs endpoints (bonne chance pour maintenir une liste…)
Et si on bloque tout le trafic 80/443 dans egressDeny, on ne peut pas faire d’exceptions pour le trafic légitime dans les règles egress car… deny prend la précédence sur allow !

On est coincé entre le marteau et l’enclume :

Utiliser egress avec toFQDNs → ça marche, mais on ne peut pas bloquer, seulement autoriser
Utiliser egressDeny avec des IPs → on va jouer au chat et à la souris avec des plages IP qui changent
Utiliser egressDeny pour bloquer tout le 80/443 → on bloque tout, y compris le trafic légitime

Solutions de contournement potentielles

En attendant que Cilium supporte toFQDNs dans les policies egressDeny, voici quelques approches alternatives que vous pourriez envisager :

Trouver un moyen de désactiver la télémétrie directement dans l’app

C’est la meilleure option, mais malheureusement pas toujours sur la table.

Blocage basé sur le DNS

Configurer le serveur DNS pour retourner NXDOMAIN pour les domaines de télémétrie, comme un serveur pi-hole personnel le ferait avec les pubs. L’application échouera à résoudre le domaine et n’enverra pas de données.

Utiliser egressDeny basé sur les IPs (avec un overhead de maintenance)

Résoudre les FQDNs de télémétrie vers leurs plages IP actuelles et les bloquer avec egressDeny :

egressDeny:
 - toCIDRSet:
 - cidr: 203.0.113.0/24  # Exemple de plage IP de télémétrie
 toPorts:
 - ports:
 - port: "443"

Si la liste n’évolue pas trop souvent, c’est une bonne option.

OK, mais imaginons qu’il n’y ait pas de trafic légitime. Peut-on utiliser la fonctionnalité pour ajouter un log sur le trafic droppé ?

Malheureusement non, pas pour le moment.

Il y a un bug dans cette nouvelle fonctionnalité de Cilium qui ne log le champ policy_log que sur les flux “autorisés”, pas sur les flux audit/dropped.

Policy log does not work for DROPPED/AUDIT flow ouverte par mon collègue Nicolas :

When defining a CiliumNetworkPolicy with the spec.log field configured, I expect the relevant hubble flows to have the policy_log field. It works for allowed flow.

But for denied/audited flow resulting from the rule (implicit or explicit), policy_log is never available.

Note: I observe the same issue with --print-policy-names option of hubble, the k8s:io.cilium.k8s.policy.derived-from label is not set for denied flows (but correctly set for allowed flows).

et une autre issue [Hubble CLI] –print-policy-names flag does not do anything ouverte par quelqu’un d’autre.

Puisque 2 tickets sont ouverts et que les mainteneurs ont commencé à répondre dessus, on peut espérer que ce soit corrigé un jour.

Conclusion

Dans notre cas d’usage, nous n’avons finalement pas utilisé cette nouvelle fonctionnalité de Cilium. Mais donner la possibilité d’ajouter des détails (et permettre de filtrer dessus également) est toujours une feature sympa.

Un grand merci à mon collègue Nicolas Nativel, qui a fait la majorité du travail autour des CiliumNetworkPolicies, incluant les dashboards, le travail exploratoire sur cette fonctionnalité, et a pris le temps de créer l’issue sur le repo Cilium.

Références

SLO, SLI, Error Budget et Critical User Journey expliqués simplement (et pourquoi ce ne sont pas des SLA !) (en plusieurs prompts)

Tue, 17 Jun 2025 18:00:00 +0200

NOTE IMPORTANTE : cet article a été généré par un LLM. Ceci va à l’encontre de règles que je me suis fixé pour ce blog (cf l’AI Manifesto).

Je pars du principe que si je ne prends pas la peine d’écrire moi-même le contenu de ce blog, vous ne devriez pas prendre la peine de le lire.

Je l’ai fait dans le cadre d’une expérience qui est décrite dans l’article suivant :

Réflexions sur le blogging technique à l’ère des LLMs

Cependant, je ne vous interdit pas de lire cet article ci (les informations qu’il contient sur les SLOs sont correctes), je veux juste que vous le fassiez en connaissance de cause ;-P.

Introduction : quand les devs découvrent le SRE

Suite à plusieurs discussions récentes avec des collègues développeurs, je me suis rendu compte que les concepts SRE comme les SLO, SLI et Error Budget restaient flous pour beaucoup d’entre eux. Pourtant, ces notions sont de plus en plus utilisées dans nos équipes, souvent sans qu’on prenne le temps de bien les expliquer.

C’est donc l’occasion parfaite pour revenir aux fondamentaux et expliquer ces concepts tels qu’ils ont été conçus à l’origine par Google. Car oui, il faut le rappeler : le SRE (Site Reliability Engineering) et tous les concepts associés ont été inventés par Google, plus précisément par Ben Treynor Sloss en 2003, bien avant que DevOps ne devienne populaire !

L’idée de Google était simple : et si on demandait à des ingénieurs logiciel de concevoir une équipe d’exploitation ? De cette approche sont nés des concepts révolutionnaires pour mesurer et gérer la fiabilité des services.

Fun fact : j’avais déjà abordé ces sujets dans mon talk sur le SRE en 2022, mais je me dis qu’un article dédié ne fait pas de mal pour clarifier les choses :-).

SLA vs SLO : ne mélangeons pas tout !

Avant de rentrer dans le vif du sujet, petit aparté important : ne confondez pas SLA et SLO !

Le SLA (Service Level Agreement), c’est un contrat, souvent avec des pénalités financières si pas respecté. Genre “si le service est en panne plus de X heures dans le mois, on vous rembourse Y€”. Le SLO (Service Level Objective), c’est un objectif interne que vous vous fixez pour la fiabilité de votre service.

La différence est importante : les SLA sont souvent moins stricts que les SLO pour avoir une marge de manœuvre. Si votre SLA c’est 99,9% de disponibilité, votre SLO interne sera peut-être à 99,95%.

Bon, maintenant qu’on a éclairci ça, rentrons dans le détail !

Critical User Journey : commencer par ce qui compte vraiment

Est-ce que le client est content d’utiliser le service ?

C’est LA question fondamentale. Et pour y répondre, il faut d’abord identifier les Critical User Journey (CUJ), autrement dit les parcours utilisateurs critiques.

Mais attention, quand on parle d’utilisateur dans le contexte SRE, ce n’est pas forcément l’utilisateur final ! Pour un service backend, l’utilisateur peut être le frontend qui fait les appels API. Pour une plateforme de CI/CD, ce sont les développeurs qui veulent livrer une nouvelle version. Pour une base de données, ce sont les applications qui l’interrogent.

Concrètement, ça veut dire quoi ? Prenons l’exemple d’une plateforme e-commerce. Les CUJ pourraient être : un utilisateur peut rechercher et consulter un produit, il peut ajouter un produit au panier et passer commande, il peut se connecter à son compte.

On ne va pas définir des SLO pour toutes les fonctionnalités (la page “À propos” de votre site, on s’en fiche un peu), mais se concentrer sur celles qui, si elles tombent en panne, vont vraiment énerver vos utilisateurs.

Et c’est là que ça devient intéressant : définir les CUJ, c’est souvent un exercice qui doit impliquer le business, pas seulement les équipes techniques. C’est eux qui savent ce qui rapporte de l’argent !

SLI : mesurer ce qui compte

Une fois qu’on a identifié nos CUJ, il faut les mesurer. C’est là qu’interviennent les SLI (Service Level Indicators).

Un SLI, c’est simplement une métrique qui indique si votre service fonctionne bien du point de vue de l’utilisateur. Les plus classiques sont la disponibilité (pourcentage de requêtes qui réussissent), la latence (temps de réponse du service), le débit (nombre de requêtes traitées par seconde) et la qualité (pourcentage de réponses correctes, sans erreurs de données).

L’idée clé ici, c’est de mesurer depuis le point de vue de l’utilisateur, pas depuis vos serveurs. Peu importe que votre CPU soit à 10% si l’utilisateur voit des erreurs 500 !

Quelques conseils pour choisir vos SLI

Pour vous aider à concevoir des SLI fiables, vous pouvez vous inspirer des méthodes USE et RED. USE (Utilization, Saturation, Errors) se concentre sur les ressources systèmes, tandis que RED (Rate, Errors, Duration) se concentre sur les requêtes. Ces frameworks vous donnent un bon point de départ pour identifier les métriques qui comptent vraiment.

Mais attention, un microservice ne doit pas avoir trop de SLI ! Trois ou quatre SLI bien choisies et qui ont un sens métier valent mieux qu’une dizaine de métriques que personne ne regarde. D’ailleurs, seuls les membres de l’équipe qui fournissent le service peuvent vraiment savoir quelles sont les métriques pertinentes. On ne peut pas imposer des SLI génériques à toute une entreprise !

Exemple concret pour notre CUJ “recherche de produit” : SLI disponibilité pourrait être (requêtes HTTP 200 sur /search) / (total requêtes sur /search) * 100, et SLI latence 95% des requêtes sur /search répondent en moins de X ms.

SLO : se fixer des objectifs réalistes

Maintenant qu’on sait quoi mesurer, il faut se fixer des objectifs. C’est le rôle des SLO (Service Level Objectives).

Un SLO, c’est tout simplement une valeur cible pour vos SLI sur une période donnée. Par exemple : “99,9% des requêtes de recherche doivent réussir sur une période de 30 jours” ou “95% des pages de recherche doivent s’afficher en moins de 500ms sur une période de 7 jours”.

Quelques conseils pour bien définir vos SLO

Commencez par mesurer l’existant. Inutile de viser 99,99% si votre service actuel est à 98%. Regardez vos métriques historiques et fixez-vous des objectifs atteignables mais ambitieux.

Pensez S.M.A.R.T. : vos SLO doivent être Spécifiques, Mesurables, Atteignables, Réalistes et Temporellement définis. Comme tout bon objectif !

Et n’oubliez pas que 100% c’est mal ! Comme le dit si bien Ben Treynor Sloss (le papa du SRE chez Google) :

100% is the wrong reliability target for basically everything

Plus on veut de “9”, plus ça coûte cher exponentiellement. Et au-delà d’un certain seuil, les utilisateurs ne voient même plus la différence ! Prenez l’exemple d’un site web qui ne charge pas sur un smartphone : au-delà d’un certain niveau de disponibilité, l’utilisateur ne saura pas dire si c’est son smartphone qui a un problème, son navigateur, le réseau 5G ou bien le site web qui rencontre un incident. Si recharger la page une fois de temps en temps suffit et que les utilisateurs ne sont pas plus impactés que ça, inutile d’investir dans plus de fiabilité.

Pour vous aider à calculer ces pourcentages et temps d’indisponibilité, vous pouvez utiliser uptime.is qui fait les conversions pour vous.

Error Budget : retourner le problème

Et là, c’est le moment où ça devient vraiment malin. Au lieu de raisonner en “disponibilité”, les équipes SRE raisonnent en Error Budget (budget d’erreur).

C’est un simple changement de perspective : service accessible 99,9% = service inaccessible 0,1% du temps. Sur 30 jours, ça fait environ 43 minutes d’indisponibilité “autorisée”.

Cette approche change complètement la donne ! Au lieu de voir les pannes comme des échecs, on les voit comme un budget à dépenser intelligemment.

Comment utiliser son Error Budget ?

Contre-intuitivement… IL FAUT L’UTILISER !

Si votre SLO est respecté (utilisateurs contents), vous pouvez “dépenser” votre error budget pour faire des déploiements plus risqués, tester des nouvelles fonctionnalités en prod, faire du chaos engineering, ou réaliser des maintenances disruptives.

À l’inverse, si vous “cramez” votre error budget (SLO pas atteint), alors là, stop : on arrête tout ce qui n’améliore pas la fiabilité du service !

C’est un formidable outil de priorisation entre les équipes produit (qui veulent des nouvelles features) et les équipes ops (qui veulent de la stabilité). Le fameux mur de la confusion :

Exemple concret : une API de recommendation

Bon, assez de théorie, prenons un exemple concret. Imaginons qu’on ait une API de recommandation de produits.

D’abord, on définit le CUJ : “Un utilisateur doit pouvoir récupérer des recommandations personnalisées en moins de 1 seconde”. Ensuite, on choisit les SLI : disponibilité (réponses HTTP 200) / (total requêtes) * 100 et latence P95 du temps de réponse.

Pour les SLO, on pourrait avoir : “99,5% des requêtes sur l’API de recommandation doivent réussir sur 30 jours” et “95% des requêtes doivent répondre en moins de 800ms sur 7 jours”.

Enfin, on calcule l’Error Budget : 99,5% de disponibilité = 0,5% d’indisponibilité autorisée, soit environ 3,6 heures d’indisponibilité “budgetées” sur 30 jours.

Simple, non ?

Les pièges à éviter

Le premier piège, c’est de vouloir mettre des SLO partout. N’essayez pas ! Commencez par 2-3 SLO sur vos CUJ les plus critiques. Vous pourrez étendre ensuite.

Le deuxième piège, c’est de fixer des SLO trop stricts. Si vous mettez la barre trop haut, vous allez passer votre temps en “SLO violation” et personne ne prendra plus ça au sérieux.

Enfin, le troisième piège, c’est d’oublier l’aspect organisationnel. Les Error Budgets ne marchent que si toute l’organisation (business inclus) adhère au principe. Sinon, vous aurez beau être en SLO violation, on vous demandera quand même de déployer la nouvelle feature…

Comment commencer ?

Si vous n’avez jamais fait de SLO, voici un plan d’action simple.

Identifiez d’abord 1-2 CUJ critiques (avec le business !). Regardez ensuite vos métriques actuelles sur ces parcours. Définissez alors des SLO réalistes mais un peu ambitieux. Mettez en place l’alerting quand vous êtes en train de consommer votre error budget. Et enfin, itérez ! Les SLO ne sont pas gravés dans le marbre.

Conclusion

J’espère que cet article vous aura donné envie de creuser ces concepts ! Les SLO/SLI/Error Budget ne sont pas juste des buzzwords, c’est vraiment un changement de paradigme dans la façon d’appréhender la fiabilité.

Et le plus beau, c’est que ça marche autant pour une startup avec 3 développeurs que pour une GAFAM avec 10000 ingénieurs. L’important, c’est de commencer simple et d’itérer.

Pour aller plus loin, je vous recommande chaudement le SRE Book de Google (gratuit !) et leur guide pratique pour définir des SLO.

Et si vous voulez approfondir le sujet SRE en général, n’hésitez pas à jeter un œil aux slides de mon talk de 2022 ;-).

Bon monitoring !

Retrouvez-moi ce soir au meetup Archilocus

Thu, 30 May 2024 08:00:00 +0000

On the road again

Après quelques mois sans être speaker (FOSDEM en février, ouhalala au moins 3 mois 🤣), j’aurais le plaisir de participer avec des anciens collègues / amis à Archilocus ce soir.

Ca se passe dans les locaux de Zenika Bordeaux à partir de 18h ce soir, au 17 Quai Louis XVIII.

La page du meetup (inscription obligatoire, gratuit) Archilocus #13

Le planning du meetup

📺 Diffusé simultanément en live sur twitch.tv/archilocus

🕕 18h05 - OpenTelemetry: vous ne pourrez plus vous passer de monitoring en prod par Vivien Maleze Architecte Technique chez Ippon Technology

🕖 18h45 - Pourquoi privilégions-nous les services managés dans le Cloud ? par Guillaume Lannebere Head Of Cloud Center Of Excellence chez Betclic

🕢 19h25 - Comment je monitore ma prod ? Table ronde avec participation du public Denis Germain Staff SRE chez Deezer Sébastien Descamps Directeur R&D et Innovation chez Zenika Gauthier Astruc-Amato CTO chez CyberVadis

Le pitch de la session

Table ronde : Comment je monitore ma prod ? Denis Germain, Sébastien Descamps et Gauthier Astruc-Amato partageront leurs expériences et discuteront des meilleures pratiques pour le monitoring de la production.

Bonus - Deez is la Tech

J’ai aussi oublié de publier que j’ai participé à un podcast sorti la semaine dernière, pour parler des Communautés de Pratiques (aka les CoP), dont j’avais déjà parlé dans cet article.

Les liens vers les plateformes d’écoutes ainsi que le transcript est disponible ici :

Deez is la tech — S02E06 — Good COP, bad COP : comment organiser et animer une Communauté de Pratique

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

Des visualiations ultra personnalisés sur Kibana avec Vega

Mon, 03 Jan 2022 07:00:00 +0000

Et si on faisait un nuage de points avec Kibana ?

Si vous me suivez sur les réseaux sociaux que je fréquente (Twitter et LinkedIn) vous ne pouvez pas avoir loupé le fait que je participe à l’organisation du sondage annuel sur les salaires dans la tech Girondine de l’association Okiwi. (OUI, je vous ai bassiné avec ça, mais c’est pour la bonne cause :chatpotté:).

Aujourd’hui, j’en parle pas, promis ;-p (ou alors, juste un tout petit mini lien ?).

Cet article est juste un retour d’expérience suite à un problème que j’ai eu, dans le cadre de ce sondage.

Frédéric Camblor m’a fait remarquer que pour visualiser les différents types de salaires en fonction de certaines catégories, un nuage de points pouvait être une visualisation efficace.

Or, pas de bol, on ne peut pas nativement faire ce type de visualisation dans Kibana… Et vous allez voir que la solution est tout sauf triviale…

Déjà, comment le savoir ?

Pour en avoir le coeur net, j’ai épluché toutes les possibilités offertes par la page “Visualisation” de mon Kibana.

D’abord, il y a Lens, a priori c’est relativement récent car ça ne me disait rien, mais c’est une façon assez pratique, user friendly et intuitive de créer des visualisations.

On drag’n’drop la métrique qu’on veut représenter et Kibana nous propose une ou plusieurs visualisation avec un type d’aggregation (count, avg, median) déterminé automatiquement.

Pour l’avoir utilisé pour la première fois pour le sondage des salaires de cette année, c’est hyper bien pensé et j’ai gagné beaucoup de temps par rapport à l’ancien éditeur de visualisation.

Bravo Elastic pour ça.

Ensuite, il y a l’ancienne façon de faire des visualisations, et là encore, pas de nuage de points…

Enfin, il y a les TSVB mais c’est pour les timeseries (donc là ça va pas le faire), et… Vega…

C’est quoi, Vega ?

Nouveauté dans Kibana 6.2 : vous pouvez désormais construire des visualisations riches Vega et Vega-Lite avec vos données Elasticsearch.

Vega-Lite is a high-level grammar of interactive graphics. It provides a concise, declarative JSON syntax to create an expressive range of visualizations for data analysis and presentation. – https://vega.github.io/vega-lite/

Grosso modo, pour tout ce que Kibana ne propose pas nativement comme type de visualisation, on vous propose de vous orienter vers le langage Vega, qui permet de déclarer, en JSON, des graphiques assez complexes et spécifiques à votre besoin.

Cool ! Reste plus qu’à trovuer comment ça fonctionne ce biniou, et surtout, comment ça s’interface avec les données dans mon ElasticSearch…

La première chose que j’ai cherché, c’est donc des exemples de nuages de points en Vega. Sauf que… je n’avais aucune idée de comment dire “nuages de points” en anglais (la recherche en Français n’ayant rien donné). Et non, ce n’est pas “cloud dots”…

Une fois que je savais que c’était un “bubble chart”, c’était tout de suite beaucoup plus simple ;-) et j’ai trouvé un tuto qui commençait à ressembler à ce que je voulais faire (même si au final ce que j’ai fais ne ressemble pas du tout).

Bubble Chart in Kibana with Vega

Ca ressemble à quoi, Vega ?

Si vous cliquez sur “Custom Visualization”, vous allez tomber sur cette page dans votre Kibana :

A gauche, un aperçu de ce que vous êtes en train de faire, et à droite, le code JSON associé.

Il y a pas mal de gloubiboulga mais vous allez vite vous rendre compte que c’est surtout des commentaires pour vous aider à comprendre ce que vous êtes censé écrire pour que ça fonctionne.

Si vous enlevez tous les commentaires, vous devriez tomber sur ça :

{
 $schema: https://vega.github.io/schema/vega-lite/v5.json
 title: Event counts from all indexes
 data: {
 url: {
 %context%: true
 %timefield%: @timestamp
 index: _all
 body: {
 aggs: {
 time_buckets: {
 date_histogram: {
 field: @timestamp
 interval: {%autointerval%: true}
 extended_bounds: {
 min: {%timefilter%: "min"}
 max: {%timefilter%: "max"}
 }
 min_doc_count: 0
 }
 }
 }
 size: 0
 }
 }
 format: {property: "aggregations.time_buckets.buckets"}
 }
 mark: line
 encoding: {
 x: {
 field: key
 type: temporal
 axis: {title: false}
 }
 y: {
 field: doc_count
 type: quantitative
 axis: {title: "Document count"}
 }
 }
}

La difficulté de faire du Vega dans Kibana a été pour moi que je découvrais 2 choses en même temps :

requêter elastic depuis Kibana avec des notions d’aggregations, buckets, etc que je ne maitrisais pas du tout
découvrir le langage Vega

Choisir l’index

La première chose qu’on remarque, c’est que les données récupérées d’ElasticSearch et donné à manger à Kibana proviennent de TOUS nos index car on a la ligne index: _all.

 data: {
 url: {
 %context%: true
 %timefield%: @timestamp
 index: _all

Clairement, ça va pas le faire ;-) du coup on restreint à l’index qui nous intéresse (okiwi-2022 dans mon cas)

Requêter Elastic avec des aggrégations

Le deuxième gros morceau à comprendre, c’est la partie interrogation de notre ElasticSearch

 body: {
 aggs: {
 time_buckets: {
 date_histogram: {
 field: @timestamp
 interval: {%autointerval%: true}
 extended_bounds: {
 min: {%timefilter%: "min"}
 max: {%timefilter%: "max"}
 }
 min_doc_count: 0
 }
 }
 }
 size: 0
 }

Ici, l’exemple fait un graphique en fonction du temps (x-axis). Les données sont regroupées avec une aggrégation de type date_histogram, avec un intervalle automatique et en se basant sur le timestamp de nos entrée dans ElasticSearch.

Ce que j’ai mis un bon moment à comprendre (car la doc est pas ouf non plus et j’ai perdu beaucoup de temps dessus) c’est qu’on a pas forcément BESOIN de faire des aggrégations.

Les aggregations possibles, si vous, vous en avez besoin, sont disponibles ici

Typiquement, dans mon cas, je ne voulais pas afficher un point (genre la moyenne) pour un groupe de personne de mon sondage, mais bien un point par personne !

Requêter Elastic sans aggrégation

Pas besoin d’aggrégation donc…

Il m’a fallu un bon moment pour trouver car tous les exemples que j’ai trouvé sur Internet passaient TOUS par des aggrégations préalables, mais j’ai fini par trouver comment juste faire une requête à ElasticSearch depuis Kibana de la façon suivante (depuis les “Dev Tools” ou bien un cURL) :

GET okiwi-2022/_search
{
 "size": 10,
 "_source": ["Nombre d'années d'expérience", "Salaire *partie fixe BRUT* (€) annuel (ex_ 30000)_ ", "Type d'entreprise"]
}

Ici, je requête l’index okiwi-2022 et je lui demande 10 résultats contenant les propriétés “Nombre d’années d’expérience”, “Salaire partie fixe BRUT (€) annuel (ex_ 30000)_ “, “Type d’entreprise” de mes documents.

Une fois que je savais ça, j’ai juste testé dans Vega

 body: {
 "size": 1000,
 "_source": ["Nombre d'années d'expérience", "Salaire *partie fixe BRUT* (€) annuel (ex_ 30000)_ ", "Type d'entreprise"]
 }

Bon ok, ça marchait toujours pas 😭😭😭 mais j’avais progressé.

La blague, c’est que le JSON renvoyé par Elasticsearch est un poil différent en fonction du fait que vous utilisiez ou non une aggregation.

Dans le premier cas, les données sont encapsulées dans aggregations.time_buckets.buckets, d’où la ligne suivante, en dessous du bloc “data”

format: {property: "aggregations.time_buckets.buckets"}

Dans le cas où vous avez une requête sans aggrégation, il suffit “juste” de remplacer par

format: {property: "hits.hits"}

Le graphique en lui même

OK, maintenant, on a les données, on peut faire du Vega purement cosmétique.

La première chose que j’ai voulu changer, c’est que dans l’exemple donné quand on créé le graphique, on a des traits. Or, moi je veux des points.

Ca, c’est géré par la ligne :

 mark: line

On remplace ça par :

 mark: {"type": "point"}

Et puis pour que le graphique soit plus “user friendly”, on peut activer les tooltips pour voir les détails du point quand on passe la souris dessus

 mark: {"type": "point", "tooltip": true}

Et puis comme les points sont trop petits (30 de base), on peut grossir un peu

 mark: {"type": "point", "tooltip": true, size: 80}

Les axes

Normalement notre graphique est pété depuis nos premières modifs car l’exemple donné par Kibana se base sur des axes temporels et des données récupérées depuis une aggrégation et qu’on a viré tout ça.

Il est donc grand temps de rebosser sur les axes et surtout où on place nos points (en fonction de quels axes).

Cette partie est gérée par le bloc encoding

 encoding: {
 x: {
 field: key
 type: temporal
 axis: {title: false}
 }
 y: {
 field: doc_count
 type: quantitative
 axis: {title: "Document count"}
 }
 }

Dans mon exemple, je veux afficher le salaire des gens en fonction de leur expérience. Mon axe des X est donc le nombre d’années d’expérience et celui des y est donc le salaire.

 x: {
 field: "_source.Nombre d'années d'expérience"
 type: "quantitative"
 axis: {title: "Années d'expériences"}
 }
 y: {
 field: "_source.Salaire *partie fixe BRUT* (€) annuel (ex_ 30000)_ "
 type: quantitative
 axis: {title: "Salaire brut"}
 }

Pour faire joli, je leur ai donné un titre avec axis: {title: ""}, c’est quand même plus sympa que le nom dégueulasse que j’ai importé du google forms en CSV ;-). Dans les deux cas, mes axes sont “quantitatifs” et non plus “temporels”. La documentation Vega sur les axes est disponible ici

Une fois que tout ça est fait, ça devrait donner un truc qui ressemble grosso modo à ça (la requête à droite est pas la bonne mais le résultat est le même):

Rendre ça joli

On n’est plus très loin de ce que Frédéric m’a proposé en début d’aticle. Reste maintenant à discriminer visuellement les données en fonction du type de société dans laquelle le salarié est embauché.

Pour ça, on va changer la forme ET la couleur du point en fonction d’une 3ème donnée : son type d’entreprise.

Bon, je vais le dire tout de suite, j’ai passé pas mal de temps sur cette partie et je ne suis pas réussi à faire ce que je voulais malgré plusieurs essais…

La méthode pour faire ça est d’utiliser les valeurs shape et color dans encoding. Là où Vega est plutôt malin, c’est que si vous mettez la même valeur comme field dans shape et color, les deux sont “merge” dans la légende, comme le montre cet exemple de la doc de Vega

https://vega.github.io/vega-lite/docs/scale.html#ordinal

 shape: {"field": "_source.Type d'entreprise", "type": "nominal"}
 color: {"field": "_source.Type d'entreprise", "type": "nominal"}

Sauf que les couleurs choisies par Kibana (qui utilise sa propre scale) sont plus que bof…

En relisant la doc, on voit qu’on devrait pouvoir choisir notre propre scale

The range of an ordinal scale can be an array of desired output values, which are directly mapped to elements in the domain. Both domain and range array can be re-ordered to specify the order and mapping between the domain and the output range. For ordinal color scales, a custom scheme can be set as well.

Sauf que tous mes tests se sont révélés être des échecs :-( Au mieux, j’ai réussi à le faire, mais en pétant la légende.

 color: {mark: {"type": "point", "tooltip": true, size: 60}
 "type": "nominal",
 "scale": {
 domain: ["Association", "ESN/SSII", "Editeur", "Entreprise non numérique", "Public"]
 range: ["rgb(230,230,31)", "rgb(255,0,0)", "rgb(0,191,0)", "rgb(31,31,255)", "rgb(191,31,191)"]
 }

Conclusion

Ce “besoin” de faire un graphique non prévu “out of the box” dans Kibana m’aura permi de découvrir plusieurs choses. D’abord, les différentes façon de requêter ElasticSearch car je n’avais jamais eu besoin de le faire (au delà de sortir les documents entier avec un bête index/_search sans filtres).

Ensuite, j’ai réussi à faire un graphique approchant de ce que je voulais faire.

Et enfin, ça m’a surtout permis de voir que je pouvais totalement me passer de Kibana pour faire des visulisations jolies.

Car beaucoup de gens qui font du Vega utilisent tout simplement une URL pointant vers un CSV et c’est totalement suffisant pour afficher des graphiques sur Internet… On perd le côté interactif bien sûr, mais pour les cas où j’ai besoin de quelque chose de simple, ça me suffira largement.

Mise à jour mars 2026 : le serveur Kibana a été décommissionné. Les dashboards interactifs ne sont plus disponibles. Les captures d’écran et les exports de données sont consultables dans l’article dédié à la décommission.

Have fun :-)

Sources

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 :).

[Update] Les salaires de l’IT dans un Kibana

Fri, 10 Jul 2020 18:46:29 +0000

Update

Shirley a eu la gentillesse de rajouter de nouvelles valeurs dans son sondage. J’ai donc intégré les résultats dans le Kibana (après nettoyage).

Comme la dernière fois, n’hésitez pas à me demander les accès !

Étude des salaires dans l’IT de Shirley Almosni Chiche

Shirley Almosni Chiche (agent de carrière IT, pour ceux qui ne la connaissent pas encore) a lancé il y a quelques jours une étude des salaires en « Open Source », comme elle dit. Elle est limitée aux salariés et à la France.

L’avantage de sa démarche, c’est que les résultats (dont les personnes ont accepté la diffusion) sont librement accessible sur un Google Docs !

Ça vous rappelle pas quelque chose ?

Ceux qui me suivent sur LinkedIn se souviennent peut être que j’avais déjà participé à une étude sur les salaires dans l’IT (association Okiwi cette fois là), mais limitée à la région bordelaise.

Là aussi, les résultats étaient librement accessibles et j’avais utilisé les résultats pour alimenter un dashboard Kibana.

Une capture d’écran d’une partie du dashboard Okiwi 2019/2020

Et comme je suis quelqu’un de sympa, je n’avais pas gardé ça juste pour moi et avait mis à disposition le dashboard à tous ceux qui me l’avaient demandé.

Vous me voyez venir…

Et oui, j’ai récidivé !

J’ai une nouvelle fois exploité les données librement accessibles pour faire un nouveau dashboard, cette fois ci plus limité à la seule région bordelaise mais à toute la France (salariés uniquement) !

Voici quelques screenshots de ce que je commence à avoir :

Pourquoi Kibana ?

Après tout, on aurait simplement pu se contenter d’utiliser le fichier sur Google Sheet et y ajouter des graphiques en sélectionnant les colonnes !

En vrai, ça fonctionne très bien.

Cependant (là encore c’est possible), ça devient plus compliqué de le rendre dynamique. Par exemple, si je ne veux sélectionner que les femmes dans mes graphiques, il faut utiliser des filtres, potentiellement des formules, si je veux quelque chose de plus poussé.

Avec Kibana, tout est dynamique,nativement.

Si je ne veux afficher que les réponses de femmes dans l’IT, il me suffit de simplement cliquer sur « femmes » dans mon donut des genres, et paf :

Idem si je veux faire une recherche uniquement sur les SRE, etc…

Vous l’aurez compris, c’est méga super trop chouette :D

Comment y avoir accès ?

Et c’est là où j’ai besoin de vous !

Pourquoi ?

Tout simplement parce que c’est étude ne valent pas grand chose si elles ne sont pas remplies par le plus grand nombre.

En 3 jours, Shirley avait déjà récolté plus de 400 réponses (250 librement accessibles). C’est pas mal, mais pour être encore plus pertinents, il nous en faut plus.

C’est pourquoi, si jamais vous voulez un accès à mon dashboard Kibana, je vous demanderai d’abord de remplir le questionnaire de Shirley en premier. Ce n’est pas très long et ça nous permettra à tous d’avoir les résultats les plus pertinents possibles.

Et comme ça, tout le monde est gagnant :)

Le formulaire :

docs.google.com/forms/d/e/1FAIpQLScMWthuEaxmP9zGBKzM0MOZmWOLT4hYO9ngKNiU6m53IogmZA/viewform

Et une fois rempli, si jamais vous voulez accéder au Kibana, n’hésitez pas à me demander les accès en m’envoyant un message sur ~~Twitter~~ ou sur LinkedIn.

Mise à jour mars 2026 : le serveur Kibana a été décommissionné. Les dashboards interactifs ne sont plus disponibles. Les captures d’écran et les exports de données sont consultables dans l’article dédié à la décommission.

Have fun !

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