Nous avons récemment introduit IBM Instana Crash Detector, qui détecte et signale automatiquement les interruptions anormales de processus sur toutes les machines Linux fonctionnant avec le noyau Linux 4.8 et plus. La plateforme IBM Instana exploite les fonctionnalités de l’Extended Berkeley Packet Filter (eBPF) du noyau Linux pour se connecter au noyau lui-même et observer les fins de processus. Toute interruption anormale est signalée à l’agent hôte, qui la compare aux processus qu’il surveille afin d’éviter toute information parasite sur des processus non pertinents, puis envoie l’information en amont au back-end d’IBM Instana. Cette fonctionnalité a changé la donne pour nos clients lorsqu’ils travaillent sur des incidents de dépannage.
Avec Crash Detector, le logiciel IBM Instana fournit les données critiques concernant nombre des problèmes qui affectent les performances des applications de nos clients. Nous améliorons à présent cette fonctionnalité en ajoutant les événements OOM Killer (tueur de mémoire insuffisante) à Crash Detector, un complément incroyablement précieux en raison de sa pertinence pour les applications conteneurisées.
Le cloud peut donner l’impression que, si vous disposez d’un budget suffisant, vous avez une puissance informatique infinie à votre disposition. Cependant, cette puissance est divisée en plusieurs segments. Les hôtes (physiques et virtuels), les conteneurs et les fonctions sont tous assortis de limites quant à la quantité de mémoire allouée.
Sous Linux, l’OOM Killer est un processus chargé d’empêcher les autres processus d’épuiser collectivement la mémoire de l’hôte. Lorsqu’un processus tente d’allouer plus de mémoire que la capacité disponible, le processus qui a le score de badness global le plus élevé (basé, par exemple, sur la quantité de mémoire allouée au-delà de la quantité autorisée) reçoit un signal OOM. Ce signal signifie essentiellement : « Vous dépassez les limites. Arrêtez-vous ou arrêtez certains de vos processus enfants, sinon c’est la fin. »
Notez que le processus qui déclenche l’OOM n’est pas forcément le processus qui recevra en fin de compte le signal. Une application qui n’a pas augmenté sa consommation de mémoire récemment pourrait soudainement recevoir un signal OOM en raison du démarrage d’un trop grand nombre d’autres applications sur le même hôte.
La mécanique d’un signal OOM peut sembler brutale, mais elle constitue en fait un mécanisme très efficace pour empêcher l’épuisement de la mémoire sur les hôtes, en particulier dans le cas d’applications mal dimensionnées ou d’un trop grand nombre d’applications exécutées en parallèle (c’est-à-dire que les hôtes ne sont pas dimensionnés correctement par rapport à la workload).
Pour les plateformes conteneurisées telles que Kubernetes, Cloud Foundry et Nomad, l’utilisation de la mémoire est encore plus importante : à la fois en ce qui concerne le dimensionnement approprié des applications, et le nombre d’applications qui s’exécutent simultanément sur un hôte. En général, vous ne planifiez pas en détail les applications qui s’exécutent sur un nœud donné. Dans de nombreuses configurations, les conteneurs sont alloués selon une certaine logique par l’orchestrateur. L’application d’une règle de consommation de mémoire maximale est essentielle pour les conteneurs et les groupes de contrôle (cgroups), la base de la quasi-totalité des technologies de conteneurs sous Linux. Ces plateformes utilisent également le système OOM Killer pour s’assurer que les processus exécutés dans le même groupe (c’est-à-dire un conteneur) n’allouent pas plus de mémoire que la quantité autorisée. Lorsque les processus de vos conteneurs essaient d’allouer plus de mémoire qu’il n’est permis, certains sont interrompus, emportant souvent leurs conteneurs dans leur chute.
Tout est plus complexe à grande échelle, y compris le dimensionnement. Plus vous exécutez de conteneurs dans vos environnements, plus il est difficile de comprendre quand, comment et pourquoi certains d’entre eux tombent en panne. L’OOM Killer peut provoquer des situations problématiques pour vos applications, à savoir une défaillance permanente, suivie d’un redémarrage, ce qui engendre un volume continu d’erreurs pour vos utilisateurs finaux, qui faussent vos objectifs de niveau de service (SLO) et sont très difficiles à dépanner.
Trouver la cause de l’élimination d’un processus par un OOM Killer dépend fortement de la technologie employée. Certains progiciels le consignent dans leurs propres journaux. Vous pourriez aussi être amené à exécuter une commande comme la suivante sur chacun de vos hôtes :
#CentOS
grep -i "out of memory" /var/log/messages
#Debian / Ubuntu
grep -i "out of memory" /var/log/kern.logSi elle semble anodine, ce n’est certainement pas le genre de tâche que vous voulez exécuter sur l’ensemble de votre parc de production pour essayer de comprendre pourquoi MySQL s’est à nouveau arrêté à 3 heures du matin. Surtout quand il s’agit d’une intuition, puisque rien d’autre ne semble expliquer pourquoi le processus de la base de données n’est plus là.
En d’autres termes, l’OOM Killer est un système d’une importance et d’une efficacité indéniables en termes de fiabilité, mais qui n’offre pas une observabilité suffisante. Mais la plateforme IBM Instana est là pour remédier à ce problème.
Développant davantage le socle eBPF qui a donné naissance à Crash Detector, le logiciel IBM Instana est maintenant livré avec un détecteur OOM Killer prêt à l’emploi. Lorsque votre processus est surveillé par le logiciel IBM Instana, il reçoit un signal OOM en temps réel. Non seulement pour le prévenir de la situation, mais également pour lui indiquer comment elle a été résolue (en d’autres termes, quel processus a été interrompu).
Comme pour la plupart des fonctionnalités d’IBM Instana, il vous suffit d’installer l’agent hôte IBM Instana et de regarder le processus OOM Killer exécuter sa sinistre besogne. Il vous indique également la quantité de mémoire allouée au processus tué au moment de l’événement, afin que vous puissiez comprendre pourquoi il a été signalé comme « mauvais » par l’OOM Killer.
Déterminer comment et pourquoi un processus a été interrompu ou pourquoi un processus a été tué par un OOM Killer peut prendre des heures, voire des jours, sans les outils appropriés. Avec IBM Instana Crash Detector, les utilisateurs connaissent maintenant immédiatement l’origine de chaque interruption de processus anormale et peuvent voir chaque processus OOM Killer réussi.
Vous voulez comprendre pourquoi un conteneur est fermé ? Aucun problème. Avec l’OOM Killer d’IBM Instana Crash Detector, vous saurez que votre machine virtuelle Java (JVM), qui exécute un travail par lots très important, a peut-être alloué plus de ressources qu’elle n’était autorisée à le faire. Ou peut-être devez-vous découvrir la cause du grand nombre d’échecs des requêtes du préprocesseur hypertexte (PHP) ou de la disparition de votre base de données. Là encore, vous aurez un accès immédiat à la cause racine de ces problèmes grâce à l’OOM Killer d’IBM Instana Crash Detector.
Pour vous faire gagner du temps à vous et à vos équipes DevOps dans le dépannage des événements OOM Killer, il vous suffit d’installer l’agent IBM Instana sur votre système d’exploitation Linux dès aujourd’hui. Si vous n’avez pas encore d’instance IBM Instana, vous pouvez profiter d’un essai gratuit d’IBM Instana Crash Detector avec OOM Killer pour découvrir son fonctionnement.