Les journaux et traces d'application ne sont utiles que lorsque le problème est visible depuis l'application. Une fois que la latence, la perte de paquets, la pression sur les appels système ou le comportement du planificateur deviennent partie intégrante de l'histoire, la télémétrie au niveau de l'application cesse d'être suffisante.
C'est là qu'eBPF devient précieux. Il permet aux ingénieurs d'examiner le comportement adjacent au noyau sans traiter chaque enquête comme un projet de module noyau personnalisé.
Ce que eBPF fait de mieux
eBPF est particulièrement utile pour :
- le traçage des appels système
- la visibilité des sockets et du réseau
- les questions de timing du planificateur
- l'observation des événements de sécurité
Un petit exemple bpftrace rend l'idée concrète :
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'
Ce n'est pas quelque chose que l'enregistrement normal des applications peut vous montrer. Cela inspecte le comportement en dessous de la frontière de l'application.
Pourquoi cela a de l'importance en production
De nombreux incidents difficiles se situent dans l'écart entre "l'application a l'air bien" et "le nœud est malsain." eBPF aide à combler cet écart :
- appels système lents
- réessais réseau inattendus
- mise en file d'attente dans le noyau
- comportement suspect des processus
Il ne remplace pas les métriques, les journaux ou le traçage. Il étend les couches que vous pouvez observer lorsque ces outils cessent d'expliquer le problème.
Le compromis
eBPF nécessite toujours du jugement. La télémétrie de bas niveau est puissante, mais elle peut aussi devenir bruyante ou trompeuse si l'équipe ne comprend pas le système sous-jacent. L'objectif n'est pas de collecter plus d'événements noyau pour leur propre compte. L'objectif est de répondre plus rapidement à des questions opérationnelles concrètes.
Lectures complémentaires