Herramientas de crisis para Linux

 (brendangregg.com)
2 puntos por GN⁺ 2024-03-25 | 1 comentarios | Compartir por WhatsApp
  • Si empiezas a instalar herramientas de diagnóstico después de una falla de rendimiento, perderás más tiempo en la preparación que en la recuperación, por lo que las imágenes de servidores Linux deberían incluir de antemano herramientas de crisis
  • La lista recomendada incluye procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool, entre otras; es el conjunto mínimo de paquetes para revisar de inmediato CPU, disco, red y trazas del kernel
  • bcc y bpftrace tienen muchas herramientas superpuestas, pero bcc ofrece más opciones de CLI y bpftrace es más fácil de editar en campo; al ejecutarse, ambos emiten el mismo bytecode BPF
  • Instalar durante una falla puede provocar una pérdida de decenas de minutos por variables como SSH lento, configuración de apt rota, repositorios bloqueados, firewalls, sistemas de archivos inmutables o errores de permisos
  • El costo está sobre todo en espacio en disco y tiempo de despliegue de la imagen, pero la mayoría de los paquetes recomendados son pequeños; incluirlos por defecto en distribuciones Linux empresariales permitiría empezar más rápido la respuesta a fallas de rendimiento

Herramientas mínimas que conviene tener antes de una falla

  • Cuando ocurre una falla de rendimiento, el propio tiempo de instalación de las herramientas necesarias para diagnosticar la causa se convierte en pérdida, por lo que es más seguro tener herramientas de crisis instaladas por defecto en los servidores Linux
  • La lista se basa en la tabla “Linux Crisis Tools” de Systems Performance 2nd Edition
  • Con paquetes de Ubuntu como referencia, las herramientas recomendadas son las siguientes
    • procps: ps, vmstat, uptime, top
      • Revisión de estadísticas básicas
    • util-linux: dmesg, lsblk, lscpu
      • Revisión de logs del sistema e información de dispositivos
    • sysstat: iostat, mpstat, pidstat, sar
      • Revisión de estadísticas de dispositivos y del sistema
    • iproute2: ip, ss, nstat, tc
      • Herramientas de red preferidas
    • numactl: numastat
      • Revisión de estadísticas NUMA
    • tcpdump: tcpdump
      • Sniffing de red
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • Revisión de estadísticas de profiler y PMU
    • bpfcc-tools o bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile, entre otras
      • Herramientas eBPF ya preparadas
    • bpftrace: bpftrace, versiones básicas de opensnoop, execsnoop, runqlat, biosnoop, entre otras
      • Scripting con eBPF
    • trace-cmd: trace-cmd
      • CLI de Ftrace
    • nicstat: nicstat
      • Estadísticas de dispositivos de red
    • ethtool: ethtool
      • Información de dispositivos de red
    • tiptop: tiptop
      • Top de PMU/PMC
    • cpuid: cpuid
      • Detalles de CPU
    • msr-tools: rdmsr, wrmsr
      • Investigación detallada de CPU

Cómo ver bcc y bpftrace juntos

  • bcc y bpftrace tienen muchas herramientas superpuestas, pero difieren en los puntos donde conviene usarlos
  • Las herramientas de bcc tienen más funciones, como opciones de CLI, por lo que son cómodas de usar como herramientas terminadas
  • Las herramientas de bpftrace pueden editarse al instante en campo, lo que facilita comprobaciones ajustadas a la situación
  • Esto no significa que una sea más rápida que la otra
    • Ambas herramientas emiten el mismo bytecode BPF
    • Durante la ejecución son igual de rápidas
  • bcc está evolucionando hacia trasladar herramientas basadas en Python a libbpf en C
    • Usa CO-RE y BTF
    • Los paquetes todavía no se han reelaborado
    • En el futuro, bpfcc-tools debería ser reemplazado por un paquete libbpf-tools más pequeño que contenga solo los binarios de las herramientas

Herramientas adicionales según el tipo de servidor

  • La lista anterior es, ante todo, una lista mínima
  • Si el servidor tiene aceleradores, también deben incluirse las herramientas para analizar ese hardware
    • Servidor con GPU Intel: intel-gpu-tools
    • Servidor NVIDIA: nvidia-smi
  • También se pueden preinstalar herramientas de depuración como gdb si se quieren usar de inmediato en una crisis
  • Como las herramientas de análisis imprescindibles no cambian con frecuencia, tal vez baste con actualizar esta lista una vez cada algunos años

Costo real de instalarlas por defecto

  • La desventaja que aparece primero al agregar paquetes es el uso de disco
  • En instancias cloud, incluso unos pocos MB adicionales en la imagen base del servidor pueden aumentar el tiempo de despliegue de una instancia en unos segundos o en fracciones de segundo
  • La mayoría de los paquetes recomendados son pequeños y se espera que bcc también se reduzca, por lo que el costo en capacidad y tiempo no debería ser grande
  • debuginfo llega a alrededor de 1 GB en total, por lo que sí hubo una preocupación real de capacidad que impidió incluirlo por defecto

Cómo se traba la instalación durante una falla

  • Si intentas instalar herramientas después de que ocurre una falla, el tiempo puede irse en resolver problemas de instalación más que en el diagnóstico
  • Un flujo de ejemplo es el siguiente
    • 4:00pm: el sitio de la empresa cae o queda demasiado lento para usarse
    • 4:01pm: en el dashboard de monitoreo se ve que el grupo de servidores backend está en estado anormal y se sospecha de alto I/O de disco
    • 4:02pm: se intenta acceder al servidor por SSH, pero el login es muy lento
    • 4:03pm: se intenta ejecutar iostat -xz 1, pero no existe iostat y aparece una indicación para instalar sysstat
    • 4:07pm: la instalación del paquete falla porque no puede resolver los repositorios, y sale a la luz un problema de configuración en /etc/apt
    • 4:10pm: con la configuración corregida hay que ejecutar apt-get update, pero va muy lento
    • 4:13pm: se produce un timeout de conexión y se empieza a sospechar de problemas de conexión al repositorio o de rendimiento
    • 4:17pm: el equipo de seguridad de red confirma que bloqueó tráfico inesperado y solicitudes apt salientes HTTP/HTTPS/FTP
    • 4:20pm: después de desactivar el firewall, apt-get update funciona, pero la instalación produce un error de permisos
    • 4:24pm: el equipo de seguridad de plataforma explica que se trata de un sistema inmutable donde está bloqueada la escritura en algunas partes del sistema de archivos, como las zonas de binarios ejecutables
    • 4:27pm: el equipo SRE anuncia un incidente mayor y la gerencia pide actualizaciones de estado y un ETA de recuperación, pero el diagnóstico real casi no avanzó
    • 4:30pm: se intenta usar cat /proc/diskstats como reemplazo rudimentario de iostat, pero hay que leer la documentación de Linux y solo se confirma el hecho ya conocido de que el disco está ocupado
    • 4:55pm: se levanta una nueva imagen de servidor con un sistema de archivos escribible y ya se puede instalar sysstat, pero el sitio volvió solo por el reinicio del servidor y la causa no fue corregida
    • 12:50am: el ejemplo continúa con el sitio hackeado por haber dejado apagados el firewall y la seguridad del sistema de archivos
  • El incidente de las 12:50am no es una experiencia real, pero el resto es un ejemplo basado en experiencias reales
  • En un trabajo anterior, alrededor del minuto 15 el “equipo de tráfico” podía iniciar un failover de región cloud, y para cuando terminaba la instalación de iostat, el sistema objetivo ya podía estar inactivo

Por qué deben ir en la imagen base

  • El escenario anterior muestra lo frágil que es instalar herramientas más tarde durante una falla de producción
  • Algunas empresas ya usan imágenes de servidor personalizadas creadas por el equipo de OS con las herramientas necesarias incluidas
  • Aun así, muchos sitios siguen operando con versiones Linux base tal cual, y en esos casos recién se dan cuenta de la necesidad después de sufrir una falla
  • Si las distribuciones Linux empresariales incluyeran estas herramientas de crisis por defecto, empresas grandes y pequeñas podrían empezar el diagnóstico apenas se produzca una falla de rendimiento

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-25
Opiniones en Hacker News

  • Esta lista es útil. En situaciones en las que el servidor en sí queda enredado, como cuando falla la resolución de repositorios de apt, la nube muchas veces encaja bien.
    En vez de quedarse intentando arreglarlo, se mata la máquina o se la saca del pool y se levanta una nueva; así la máquina nueva y la app arrancan limpias y se termina la caída. La máquina problemática se puede investigar aparte, fuera del hot path.

    • Después de “resolver” el problema, nadie tiene tiempo o autorización para investigar esa máquina, así que con el tiempo el enfoque de reconstruir desde cero termina haciendo que se pierdan la capacidad real de resolver problemas y el conocimiento acumulado.
      Se vuelve la versión de software de la gente que en el mundo físico solo cambia piezas.
    • “4:10pm: el mismo problema de rendimiento continúa en la máquina nueva”.
    • Eso no es necesariamente una ventaja exclusiva de la nube, sino más bien de operar servidores virtualizados y reemplazables (cattle).
    • Si matas la máquina, también puede desaparecer la evidencia. Puede que todos los logs estén afuera, pero normalmente algo falta.

  • No todos los servidores están contenerizados, pero muchos sí lo están, y eso trae sus propias dificultades.
    Las herramientas de depuración dentro de una imagen Docker muchas veces son marcadas por los escáneres automáticos de seguridad como “herramientas innecesarias que ayudan a un atacante a observar o modificar el comportamiento del sistema”. En casos como gdb es una preocupación válida, pero en muchos otros no.
    Por eso algunas herramientas se dejan en un volumen separado, idealmente como binarios estáticos, o se compilan e instalan usando la ruta de montaje como prefijo de instalación. Cuando hace falta depurar, se le pide al equipo de operaciones que las monte temporalmente en solo lectura.
    Además, si alguna herramienta de depuración requiere activar una función específica del kernel, suelen aparecer preguntas y preocupaciones sobre qué impacto tendrá en otros contenedores del mismo host.

    • Si un atacante puede ejecutar archivos desde el sistema de archivos, y lo único que le falta para ejecutar algo es que ese archivo exista, parecería que simplemente podría escribir el archivo él mismo.
      No veo muchos escenarios en los que esta política tenga sentido, salvo que “la organización está usando mal el escáner de seguridad”.
    • Una mejor forma es crear una segunda imagen que incluya herramientas de depuración y el usuario root, y ejecutarla unida a los namespaces de PID y red del contenedor de producción.
      Para usar un depurador se necesitan muchos flags como permisos SYS_PTRACE, usuario 0 y --privileged, así que normalmente es mejor levantar un segundo contenedor.
      Con este enfoque no hace falta reiniciar el contenedor de producción, lo que también reduce la posibilidad de perder evidencia para reproducir el problema.
      Eso sí, en medio de un incidente no es fácil recordar este procedimiento, así que conviene probarlo de antemano y anotarlo paso a paso en un runbook.

  • Relacionado con eso, desde FreeBSD 5.2, es decir, desde 2004, todos los sistemas FreeBSD tienen /rescue/*.
    Es un único binario enlazado estáticamente que agrupa unas 150 herramientas esenciales y está hardlinkeado con sus nombres habituales; pesa unos 17 MB.
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • En 15 años nunca tuve que usarlo. En los últimos 4 o 5 años he estado portando todo lo posible a *BSD por salud mental.

  • Cuando estuve en Netflix, Brendan y su equipo hicieron posible tener instaladas por todos lados herramientas de depuración como bpftrace, bcc y un perf que funcionaba bien.
    Fueron herramientas que me salvaron la vida varias veces.

  • Me sorprendió que strace no estuviera en esa lista. Normalmente es una de las primeras herramientas que uno toma.
    En especial cuando un programa devuelve mensajes de error inútiles o incorrectos, strace es realmente útil.

  • En entrevistas para puestos tipo SRE siempre se cubren este tipo de herramientas.
    Lo importante no es cuánto tenga memorizado el candidato sobre comandos específicos, y si te enseña una herramienta nueva impresiona, pero se evalúa qué sabe que es posible hacer, qué herramientas existen y cómo usarlas.
    Es clave tener la intuición de que se puede capturar y analizar tráfico de red, llamadas al sistema y perfiles de ejecución, además de revisar el estado del sistema operativo y del hardware.

  • Si en este tipo de crisis no se pueden instalar herramientas, se pueden ejecutar muchas utilidades con Docker.
    Por ejemplo, se puede construir un contenedor en una sola línea, conectarlo a la red del host para ejecutar herramientas tipo netstat, o montar /proc y usar --privileged, --net host, --pid host para correr herramientas de sistema como iostat, sar, vmstat, mpstat y pidstat.
    Claro que yum install es mejor, pero si puedes usar Docker y soportar los mapeos necesarios, es una alternativa. En configuraciones rootless o con Podman probablemente no funcione muy bien.

    • ¿Hay situaciones en las que apt no puede descargar e instalar paquetes, pero Docker sí puede traer un contenedor nuevo?
      ¿Tal vez cuando se dañaron las bibliotecas de apt o algo así?
    • La excepción es un entorno con redes aisladas. Si quieres traer la imagen “Ubuntu”, buena suerte.
    • En ese contexto, me gustaría que busybox incluyera más de estas herramientas.
      Sería de mucha ayuda tener un archivo de alrededor de 1 MB que puedas subir al servidor y ejecutar directamente.

  • ¿A todos les dan acceso root? Yo, haga lo que haga, tengo que levantar un ticket para el administrador del sistema.

    • Ahora soy consultor y cada pocos meses voy a una empresa nueva. Siempre hay gente con la que conviene llevarse bien.
      Conviene memorizar los nombres del personal de seguridad, de las personas con sacos incómodos que te dejan entrar al edificio, y tener a mano tarjetas de Starbucks.
      También conviene ser amable con el personal de limpieza y recordar sus nombres: tu lugar queda más limpio. A veces vale la pena quedarse tarde para conocer a estas personas.
      También conviene hacer amigos en contabilidad. Si tomas café, almuerzas y hablas de cosas que no sean trabajo mostrando interés, las personas adecuadas te avisarán cuando se viene un recorte o cuando se libera presupuesto en la empresa.
      También hay que tratar bien a IT, es decir, a quienes entregan laptops y administran el correo. Vas a ver qué tan rápido te quitan de encima las herramientas de seguridad absurdas en tu computadora y qué tan adelante quedas en la fila de upgrades.
      Lo más importante son los administradores del sistema. No solo por root, sino porque un buen administrador de sistemas sabe programar, aunque nunca lo diga en voz alta. Un buen admin te dirá en qué rincón oscuro están los cadáveres y si eso es un clóset o un cementerio. Si aprendes a construir de acuerdo con su plataforma, obtendrás mucha más libertad. Y si te piden algo, hay que hacerlo.
    • Antes me encargaba de operaciones de IT, y aquí me refiero a sistemas, SRE y seguridad.
      Este artículo está dirigido a personas que operan apps sobre infraestructura provista por IT. Si hay que interactuar como en el ejemplo, eso no es un problema técnico sino un fracaso organizacional.
      Nosotros teníamos líneas de comunicación muy claras y confiables, y la gente no se movía por chat, sino por teléfono, o hoy en día quizá en Teams, junto con desarrollo, operaciones, seguridad y compliance.
      En la práctica, todos los equipos tenían al menos un contacto responsable, y normalmente los desarrolladores corrían sus apps sobre recursos provistos por operaciones. Compliance aprobaba la configuración, y la confiabilidad del servicio era trabajo de desarrollo. Si se hace DevOps en este sentido, muchos problemas desaparecen.

  • No veo nmap, netstat ni nc. Esas herramientas también me salvaron varias veces.

  • Si agregara solo una, sería nmap.
    Los problemas de conectividad de red no siempre se manifiestan claramente en algunas apps.

    • También hacen falta screen, tmux, byobu, pv, rsync y, por supuesto, vim.