Outils Linux de gestion de crise

 (brendangregg.com)
2 points par GN⁺ 2024-03-25 | 1 commentaires | Partager sur WhatsApp
  • Si l’on commence à installer les outils de diagnostic après l’apparition d’un incident de performance, le temps perdu à préparer l’environnement retarde la reprise ; il faut donc intégrer à l’avance des outils de gestion de crise dans l’image des serveurs Linux
  • La liste recommandée comprend procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool, etc. ; c’est l’ensemble minimal de paquets pour vérifier immédiatement le CPU, le disque, le réseau et le traçage du noyau
  • bcc et bpftrace se recoupent sur de nombreux outils, mais bcc offre davantage d’options CLI tandis que bpftrace est plus simple à modifier sur le terrain ; à l’exécution, ils produisent le même bytecode BPF
  • Installer pendant une panne peut faire perdre des dizaines de minutes à cause de variables comme un SSH lent, une configuration apt cassée, un dépôt bloqué, un pare-feu, un système de fichiers immuable ou des erreurs de permissions
  • Le coût porte surtout sur l’espace disque et le temps de déploiement des images, mais la plupart des paquets recommandés sont petits ; les inclure par défaut dans les distributions Linux d’entreprise permettrait de démarrer plus vite la réponse aux incidents de performance

Le minimum à avoir avant un incident

  • Lorsqu’un incident de performance survient, le temps passé à installer les outils nécessaires au diagnostic est déjà une perte ; il est donc plus sûr de préinstaller par défaut des outils de gestion de crise sur les serveurs Linux
  • La liste s’appuie sur le tableau “Linux Crisis Tools” de Systems Performance 2nd Edition
  • Voici les outils recommandés, sur la base des paquets Ubuntu
    • procps : ps, vmstat, uptime, top
      • Vérification des statistiques de base
    • util-linux : dmesg, lsblk, lscpu
      • Vérification des logs système et des informations sur les périphériques
    • sysstat : iostat, mpstat, pidstat, sar
      • Vérification des statistiques des périphériques et du système
    • iproute2 : ip, ss, nstat, tc
      • Outils réseau privilégiés
    • numactl : numastat
      • Vérification des statistiques NUMA
    • tcpdump : tcpdump
      • Sniffing réseau
    • linux-tools-common, linux-tools-$(uname -r) : perf, turbostat
      • Vérification du profiler et des statistiques PMU
    • bpfcc-tools ou bcc : opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile, etc.
      • Outils eBPF préconstruits
    • bpftrace : bpftrace, versions de base de opensnoop, execsnoop, runqlat, biosnoop, etc.
      • Scripting eBPF
    • trace-cmd : trace-cmd
      • CLI Ftrace
    • nicstat : nicstat
      • Statistiques des interfaces réseau
    • ethtool : ethtool
      • Informations sur les interfaces réseau
    • tiptop : tiptop
      • PMU/PMC top
    • cpuid : cpuid
      • Détails sur le CPU
    • msr-tools : rdmsr, wrmsr
      • Analyse approfondie du CPU

Comment considérer bcc et bpftrace ensemble

  • bcc et bpftrace se recoupent sur de nombreux outils, mais ils ont chacun leurs points forts
  • Les outils bcc offrent plus de fonctionnalités, comme des options CLI, et se prêtent mieux à un usage d’outil abouti
  • Les outils bpftrace peuvent être modifiés immédiatement sur place, ce qui facilite les vérifications adaptées à la situation
  • Cela ne veut pas dire que l’un est plus rapide que l’autre
    • Les deux produisent le même bytecode BPF
    • En exécution, ils sont tout aussi rapides
  • bcc évolue vers une migration des outils Python vers du C libbpf
    • Avec utilisation de CO-RE et de BTF
    • Les paquets n’ont pas encore été retravaillés
    • À terme, bpfcc-tools devrait être remplacé par un paquet plus léger, libbpf-tools, ne contenant que les binaires des outils

Des outils supplémentaires selon le type de serveur

  • La liste ci-dessus n’est qu’une liste minimale
  • Si le serveur dispose d’accélérateurs, il faut aussi ajouter les outils permettant d’analyser ce matériel
    • Serveur avec GPU Intel : intel-gpu-tools
    • Serveur NVIDIA : nvidia-smi
  • Des outils de débogage comme gdb peuvent aussi être préinstallés si l’on veut les utiliser immédiatement en situation de crise
  • Les outils d’analyse essentiels changent rarement ; cette liste peut donc ne nécessiter une mise à jour qu’une fois tous les quelques ans

Le coût réel d’une installation par défaut

  • Le premier inconvénient visible lorsqu’on ajoute des paquets est l’utilisation disque
  • Sur des instances cloud, quelques Mo supplémentaires dans l’image serveur de base peuvent augmenter le temps de déploiement de quelques secondes ou d’une fraction de seconde
  • La plupart des paquets recommandés sont petits, et bcc devrait encore rétrécir ; le coût en espace et en temps ne devrait donc pas être important
  • Les debuginfo représentaient environ 1 Go au total, ce qui a réellement soulevé des inquiétudes sur leur inclusion par défaut

Comment l’installation peut se bloquer pendant un incident

  • Si l’on tente d’installer les outils après la panne, on peut finir par consacrer plus de temps à résoudre les problèmes d’installation qu’au diagnostic lui-même
  • Exemple de déroulé
    • 16:00 : le site de l’entreprise tombe ou devient trop lent pour être utilisable
    • 16:01 : le tableau de bord de monitoring montre qu’un groupe de serveurs backend est anormal, avec suspicion d’I/O disque élevées
    • 16:02 : tentative de connexion en SSH au serveur, mais la connexion est très lente
    • 16:03 : tentative d’exécution de iostat -xz 1, mais iostat est absent et un message suggère d’installer sysstat
    • 16:07 : l’installation du paquet échoue car le dépôt ne peut pas être résolu, révélant un problème de configuration dans /etc/apt
    • 16:10 : il faut lancer apt-get update avec la configuration corrigée, mais c’est très lent
    • 16:13 : un délai d’attente est dépassé, ce qui fait soupçonner un problème de connectivité au dépôt ou de performance
    • 16:17 : l’équipe sécurité réseau confirme qu’un trafic inattendu a conduit au blocage des requêtes apt sortantes HTTP/HTTPS/FTP
    • 16:20 : après désactivation du pare-feu, apt-get update fonctionne, mais l’installation échoue avec une erreur de permissions
    • 16:24 : l’équipe sécurité plateforme explique qu’il s’agit d’un système immuable, avec écriture bloquée sur certaines parties du système de fichiers, notamment la zone des binaires exécutables
    • 16:27 : l’équipe SRE annonce un incident majeur ; la direction demande des mises à jour d’état et une ETA de rétablissement, mais le diagnostic a à peine commencé
    • 16:30 : tentative de remplacer grossièrement iostat avec cat /proc/diskstats, mais il faut lire la documentation Linux et cela ne fait que confirmer que le disque est occupé
    • 16:55 : une nouvelle image serveur avec système de fichiers inscriptible est lancée et permet d’installer sysstat, mais le redémarrage du serveur a simplement remis le site en ligne sans corriger la cause racine
    • 00:50 : l’exemple se termine par un site compromis à cause de la désactivation du pare-feu et de la sécurité du système de fichiers
  • L’incident de 00:50 n’est pas une expérience réelle, mais le reste de l’exemple est basé sur des faits vécus
  • Dans un ancien poste, vers le cap des 15 minutes, la “traffic team” lançait parfois des mesures de bascule de région cloud ; au moment où iostat finissait par être installé, le système concerné pouvait déjà être redevenu inactif

Pourquoi les inclure dans l’image de base

  • Ce scénario montre à quel point il est fragile de vouloir installer les outils plus tard, au beau milieu d’un incident de production
  • Certaines entreprises utilisent déjà des images serveur personnalisées créées par l’équipe OS avec les outils nécessaires inclus
  • Beaucoup de sites continuent toutefois d’exploiter une version Linux de base telle quelle, et ne prennent conscience du besoin qu’après avoir subi un incident
  • Si les distributions Linux d’entreprise incluaient par défaut ces outils de gestion de crise, les entreprises de toutes tailles pourraient commencer le diagnostic immédiatement en cas d’incident de performance

À lire aussi

1 commentaires

 
GN⁺ 2024-03-25
Avis sur Hacker News

  • Cette liste est utile. Quand le serveur lui-même est dans un état bancal, par exemple si l’analyse des dépôts apt échoue, le cloud est souvent bien adapté.
    Plutôt que de s’acharner à le réparer, on peut tuer la machine ou la retirer du pool et en lancer une nouvelle ; la nouvelle machine et l’application redémarrent proprement, et l’incident est terminé. On peut ensuite examiner la machine problématique à part, hors du chemin critique.

    • Une fois le problème « résolu », personne n’a le temps, ou l’autorisation, d’examiner cette machine ; avec le temps, l’approche consistant à reconstruire depuis zéro fait perdre la capacité réelle à résoudre les problèmes et les connaissances accumulées.
      On devient l’équivalent logiciel, dans le monde physique, de « ceux qui ne font que remplacer des pièces ».
    • « 16 h 10 : le même problème de performances persiste aussi sur la nouvelle machine »
    • Ce n’est pas forcément un avantage propre au cloud ; c’est plutôt celui d’une exploitation de serveurs virtualisés et remplaçables (cattle).
    • Si l’on tue la machine, les preuves peuvent disparaître avec elle. Tous les journaux peuvent être conservés à l’extérieur, mais en général il manque quelque chose.

  • Tous les serveurs ne sont pas conteneurisés, mais beaucoup le sont, et cela apporte ses propres difficultés.
    Les outils de débogage présents dans les images Docker sont souvent signalés par les scanners de sécurité automatiques comme des « outils inutiles susceptibles d’aider un attaquant à observer ou modifier le comportement du système ». Pour gdb, l’inquiétude est légitime, mais pas toujours.
    Du coup, certains outils sont placés sur un volume séparé, si possible sous forme de binaires statiques, ou bien compilés et installés avec le chemin de montage comme préfixe d’installation. Quand un débogage est nécessaire, on demande à l’équipe d’exploitation de le monter temporairement en lecture seule.
    Par ailleurs, lorsqu’un outil de debug exige l’activation d’une fonctionnalité spécifique du noyau, cela suscite souvent des questions et des inquiétudes sur son impact sur les autres conteneurs du même hôte.

    • Si un attaquant peut exécuter un fichier depuis le système de fichiers, et que la seule chose qui manque à son exécution est la présence de ce fichier, il pourrait simplement l’écrire lui-même, non ?
      J’ai du mal à voir un scénario où cette politique a du sens, hormis « l’organisation utilise mal son scanner de sécurité ».
    • Une meilleure approche consiste à créer une deuxième image contenant les outils de debug et l’utilisateur root, puis à l’exécuter en l’attachant aux namespaces PID et réseau du conteneur de production.
      Pour utiliser un débogueur, il faut souvent le droit SYS_PTRACE, l’utilisateur 0 et beaucoup de flags comme --privileged ; lancer un second conteneur est donc généralement préférable.
      Avec cette méthode, il n’est pas nécessaire de redémarrer le conteneur de production, ce qui réduit aussi le risque de perdre les éléments permettant de reproduire le problème.
      En revanche, il n’est pas facile de se souvenir de cette procédure en situation d’incident ; il faut donc l’avoir testée à l’avance et l’avoir documentée étape par étape dans un runbook.

  • À ce sujet, depuis FreeBSD 5.2, donc depuis 2004, tous les systèmes FreeBSD disposent de /rescue/*.
    Il s’agit d’un unique binaire lié statiquement regroupant environ 150 outils essentiels, hard-linké sous leurs noms habituels, et d’une taille d’environ 17 Mo.
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • En 15 ans, je n’ai jamais eu à m’en servir. Ces 4 ou 5 dernières années, pour préserver ma santé mentale, j’ai porté autant de choses que possible vers *BSD.

  • Quand j’étais chez Netflix, Brendan et son équipe ont fait en sorte que des outils de débogage comme bpftrace, bcc et un perf fonctionnel soient installés un peu partout.
    Ce sont des outils qui m’ont sauvé la mise à plusieurs reprises.

  • J’ai été surpris de ne pas voir strace dans la liste. C’est généralement l’un des premiers outils que l’on attrape.
    En particulier, quand un programme renvoie des messages d’erreur inutiles ou erronés, strace est vraiment précieux.

  • Dans les entretiens pour des postes de type SRE, on aborde toujours ce genre d’outils.
    Le cœur du sujet n’est pas de savoir combien de commandes un candidat a mémorisées ; s’il vous fait découvrir un nouvel outil, c’est impressionnant, mais on regarde surtout s’il sait ce qui est possible, quels outils existent et comment les utiliser.
    Ce qui compte, c’est d’avoir l’intuition qu’on peut capturer et analyser le trafic réseau, les appels système et les profils d’exécution, et examiner l’état du système d’exploitation comme du matériel.

  • Si, dans ce genre de situation de crise, il est impossible d’installer des outils, on peut exécuter plusieurs utilitaires avec Docker.
    Par exemple, on peut construire un conteneur en une ligne, l’attacher au réseau de l’hôte pour lancer des outils de type netstat, ou monter /proc et utiliser --privileged, --net host, --pid host pour exécuter des outils système comme iostat, sar, vmstat, mpstat ou pidstat.
    Bien sûr, yum install est préférable, mais si Docker est disponible et que l’on peut gérer les mappings nécessaires, cela constitue une alternative. Avec une configuration rootless ou Podman, cela ne fonctionnera probablement pas très bien.

    • Y a-t-il vraiment des situations où apt ne peut pas télécharger et installer des paquets, mais où Docker peut récupérer un nouveau conteneur ?
      Peut-être si les bibliothèques d’apt sont cassées, quelque chose comme ça ?
    • Les environnements avec séparation réseau sont une exception. Pour récupérer une image « Ubuntu », bonne chance.
    • Dans ce contexte, j’aimerais que busybox contienne davantage de ces outils.
      Disposer d’un fichier d’environ 1 Mo que l’on peut téléverser sur un serveur et exécuter immédiatement serait très utile.

  • Tout le monde obtient un accès root ? Moi, quoi que je fasse, je dois ouvrir un ticket d’administrateur système.

    • Aujourd’hui je suis consultant, donc je change d’entreprise tous les quelques mois. Il y a toujours des gens avec qui il faut entretenir de bonnes relations.
      Il est utile de retenir les noms des responsables sécurité, des personnes en veste un peu raide qui vous donnent accès au bâtiment, et de prévoir aussi des cartes Starbucks.
      Soyez également poli avec le personnel de ménage et retenez leurs noms : votre poste restera propre. Rester tard de temps en temps pour apprendre à connaître ces personnes en vaut la peine.
      C’est bien aussi de se faire des amis à la comptabilité. Si vous prenez un café, déjeunez avec eux, parlez d’autre chose que du travail et montrez de l’intérêt, les bonnes personnes vous préviendront quand des licenciements approchent ou quand l’entreprise débloque de l’argent.
      Il faut aussi bien traiter l’IT, c’est-à-dire les personnes qui distribuent les ordinateurs portables et gèrent l’e-mail. Vous verrez à quelle vitesse elles retirent les outils de sécurité absurdes de votre machine, et à quel point vous remontez dans la file pour les mises à niveau.
      Le plus important, ce sont les administrateurs système. Pas seulement à cause de root, mais parce qu’un bon administrateur système sait coder, sans jamais le dire trop fort. Un bon admin sait dans quels coins sombres se trouvent les cadavres, et s’il s’agit d’un simple placard ou d’un cimetière entier. Si vous apprenez à construire en fonction de leur plateforme, vous gagnerez beaucoup plus de marge de manœuvre. Quand ils vous demandent quelque chose, faites-le.
    • Avant, je travaillais dans les opérations IT ; ici, cela désigne système, SRE et sécurité.
      Ce texte s’adresse aux personnes qui exploitent des applications sur une infrastructure fournie par l’IT. Si vous devez interagir comme dans l’exemple, ce n’est pas un problème technique, mais un échec organisationnel.
      Nous avions des lignes de communication très claires et fiables ; les gens n’agissaient pas via le chat, mais par téléphone, ou aujourd’hui via Teams, avec le développement, l’exploitation, la sécurité et la conformité.
      En pratique, il y avait au minimum un point de contact dans chaque équipe, et les développeurs faisaient généralement tourner leurs applications sur les ressources fournies par l’équipe d’exploitation. La conformité validait la configuration, et la fiabilité du service relevait du travail de développement. En pratiquant DevOps dans ce sens, beaucoup de problèmes disparaissent.

  • Je ne vois pas nmap, netstat ni nc. Ces outils m’ont aussi sauvé plusieurs fois.

  • Si je ne devais en ajouter qu’un, ce serait nmap.
    Les problèmes de connexion réseau n’apparaissent pas toujours clairement dans certaines applications.

    • screen, tmux, byobu, pv, rsync, et bien sûr vim, sont également nécessaires.