Intégrer OpenTelemetry dans l'ingress NGINX: optimiser la tracabilité

Un matin comme un autre, le téléphone sonne. « On a un problème avec l'application : les utilisateurs se plaignent de lenteurs, mais impossible de comprendre pourquoi. Tout semble normal de notre côté. »

3 Cafés plus tard.... Le système est complexe, les logs sont dispersés, et les métriques ne suffisent pas à donner une vue claire. C'est dans ce type de situation qu'OpenTelemetry entre en jeu. Et lorsque l'ingress NGINX est une des clés de voûte de ton cluster Kubernetes, l'intégrer avec OpenTelemetry peut faire toute la différence.

Bon il faut qu'il soit déjà installé avant! Si tu découvres ton soucis, Otel ne te sera d'aucun ressort.

Pourquoi OpenTelemetry et l'ingress NGINX ?

L'ingress NGINX est souvent le premier point de contact entre un utilisateur et ton cluster Kubernetes. C'est lui qui gère les requêtes HTTP et les redirige vers les services backend. Mais lorsqu'une requête se perd en chemin ou que les temps de réponse explosent, il devient difficile de savoir ce qui s'est passé.

OpenTelemetry, en offrant un système standardisé de collecte de traces, permet de suivre le parcours d'une requête à travers tout le système. Avec l'intégration dans l'ingress NGINX, tu obtiens une visibilité précise dès le point d'entrée.

Qu'est-ce qu'une trace distribuée ?

Une trace distribuée est une représentation visuelle et structurée du parcours d'une requête ou d'un événement à travers un système complexe. Elle est constituée de plusieurs "spans", qui représentent des segments individuels d'un flux de travail, comme une requête HTTP, une opération en base de données, ou un traitement dans une file d'attente.

Chaque span contient des métadonnées précieuses, comme :

• L'opération exécutée : par exemple, une requête GET sur un endpoint API.
• Les timestamps : pour mesurer les latences.
• Les relations parent-enfant : pour savoir quel span a déclenché un autre.

Dans un système distribué, comme un cluster Kubernetes avec plusieurs microservices, une trace complète te permet de voir comment une requête passe de l'ingress NGINX, à un service backend, puis à une base de données, tout en mesurant les performances et en identifiant les erreurs.

L'objectif principal d'une trace distribuée est d'aider les équipes à détecter rapidement les goulots d'étranglement et à résoudre les problèmes en comprenant le comportement global du système.

Pré-requis

Avant de commencer, voici ce dont tu as besoin :

• Un cluster Kubernetes fonctionnel.
• L'ingress NGINX déjà déployé.
• Le collector OpenTelemetry installé (par exemple, via Helm).
• Un backend pour les traces, comme Jaeger ou Grafana Tempo.

Et le schéma de ce que ça représente:

Configuration pas à pas

1. Activer le support OpenTelemetry dans l'ingress NGINX

Modifie la configuration de ton ingress NGINX pour activer l'exportation des traces OpenTelemetry.

2 façons de faire, soit en configMap directement, soit au niveau d'un ingress simple via l'annotation.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: nginx-configuration
5  namespace: ingress-nginx
6data:
7  enable-opentelemetry: "true"
8  otel-tracing-endpoint: "http://opentelemetry-collector.default.svc.cluster.local:4317"
9

Redémarre les pods de l'ingress NGINX pour appliquer les changements :

1kubectl rollout restart deployment ingress-nginx-controller -n ingress-nginx
2

C'est tout ??! Et je ne l'ai pas fait avant ?!

Oui et non, désolé. Ca fonctionne en tant que tel, mais ça va activer Otel pour TOUS les ingress, ce qui peut faire une charge assez conséquente et non désirée.

Donc on pourrait n'activer que par l'annotation https://kubernetes.github.io/ingress-nginx/user-guide/third-party-addons/opentelemetry/

Sauf que la librairie a une petit bug que j'ai commenté sur Github, et même si on ne l'active que pour un ingress, alors tous les ingress seront activé, lié à un défaut d'implem. https://github.com/kubernetes/ingress-nginx/issues/10966#issuecomment-2277938830

Il faut créer dans le configmap ingress cette configuration:

1apiVersion: v1
2data:
3  http-snippet: 
4    opentelemetry off;
5

Car ça va venir surcharger la configuration générée par Lua et l'ingress.

Ensuite, vous n'avez qu'à ajouter l'annotation sur vos ingress désirés.

1kind: Ingress
2metadata:
3  annotations:
4    nginx.ingress.kubernetes.io/enable-opentelemetry: "true"
5

2. Configurer le collector OpenTelemetry

Il faut installer le collector OpenTelemetry pour avoir le récepteur GRPC. https://opentelemetry.io/docs/kubernetes/helm/collector/

1helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
2helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector \
3   --set image.repository="otel/opentelemetry-collector-k8s" \
4   --set mode=deployment
5

Avec en values l'activation de la configuration grpc.

1  config:
2    receivers:
3      otlp:
4        protocols:
5          http:
6          grpc:
7    
8    exporters:
9      otlphttp:
10            encoding: json
11            endpoint: <TEMPO_URL>
12    
13    service:
14      pipelines:
15        traces:
16          receivers: 
17            - otlp
18            - zipkin
19          exporters: [otlphttp]
20

3. Visualiser les traces

Une fois tout configuré, effectue quelques requêtes vers ton ingress :

1curl http://ton-domaine/api/endpoint
2

Vérifie dans ton outil de visualisation (Jaeger, Grafana) les traces collectées. Tu devrais y voir le chemin complet des requêtes, les latences et les erreurs potentielles.

Conclusion

L'intégration d'OpenTelemetry dans l'ingress NGINX est une étape essentielle pour améliorer la visibilité dans ton cluster Kubernetes. En suivant ces étapes, tu disposeras d'un outil puissant pour mieux comprendre et optimiser ton système et tu pourras:

• Identifier rapidement les goulots d'étranglement.
• Suivre le parcours complet des requêtes.
• Résoudre plus vite les problèmes, comme ceux que rencontrait mon client ce fameux matin.