Cómo elegir un rastreador de Linux

tracer es una herramienta avanzada de diagnóstico y análisis de rendimiento, pero no dejes que el término te asuste. Si has usado strace y tcpdump, en realidad has usado tracer. El rastreador del sistema puede capturar más llamadas y paquetes del sistema. Por lo general, pueden rastrear núcleos y aplicaciones arbitrarios.

Hay demasiados rastreadores de Linux para elegir. Cada uno tiene su propia mascota unicornio de dibujos animados oficial (o no oficial), suficiente para apoyar un "espectáculo infantil".

Entonces, ¿qué trazador debemos utilizar?

Responderé esta pregunta para dos tipos de lectores, la mayoría de las personas y los ingenieros de rendimiento/kernel. Estos pueden cambiar con el tiempo, y continuaré dándoles seguimiento y agregándolos, probablemente actualizándolos una vez al año.

La mayoría de las personas

A la mayoría de las personas (desarrolladores, administradores de sistemas, gerentes de desarrollo, personal de operaciones, revisores, etc.) no les importan los detalles de los rastreadores del sistema. Esto es lo que debe saber y hacer con respecto a los rastreadores:

1. Utilice perf_events para analizar el rendimiento de la CPU

Utilice perf_events para realizar análisis del rendimiento de la CPU. Los indicadores de rendimiento se pueden visualizar utilizando herramientas como el gráfico de llamas.

git clone --profundidad 1 /brendangregg/FlameGraph

perf record -F 99 -a -g -- sleep 30

perf script ./FlameGraph | /stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > perf.svg

Linux perf_events (también conocido como "perf", el mismo que el nombre del comando) es el rastreador y analizador de rendimiento oficial de Usuarios de Linux. Integrado en el código del kernel, bien mantenido (recibió mejoras rápidas recientemente), generalmente agregado a través de kits de herramientas de línea de comandos de Linux.

perf tiene muchas funciones. Si sólo puedo recomendar una, elegiría el análisis del rendimiento de la CPU. Aunque esto es solo un muestreo y no un seguimiento técnico de eventos. La parte más difícil es obtener la pila completa y la información. Ya hablé sobre este tema en Linux Profiling en Netflix, una charla que di para java y node.js

2. Conozca otros Tracers. /p>

Como dijo un amigo mío: "No necesitas saber cómo operar un What, de modo que cuando realmente necesites un rastreador en tu trabajo, puedas elegir aprender a usarlo más tarde, o puedes contratar a la persona correspondiente para completarlo.

En resumen: casi todo se puede analizar y rastrear utilizando tracer. Por ejemplo, sistemas de archivos, procesadores de red, controladores de hardware y todas las aplicaciones. Puede consultar el artículo sobre ftrace en mi sitio web personal, así como la introducción al documento perf_events que escribí, que puede usarse como ejemplo de seguimiento (o análisis de rendimiento).

3. Busque herramientas de soporte front-end

Si está buscando comprar una herramienta de análisis de rendimiento que pueda admitir el seguimiento de Linux (hay muchas empresas que venden este tipo de herramientas). Imagine poder "conocer" todo el núcleo del sistema con solo un clic en la interfaz, incluidos mapas de calor ocultos de diferentes ubicaciones de la pila. Presenté dicha herramienta con una interfaz gráfica en la charla de Monitorama.

Abrí algunas herramientas front-end que desarrollé yo mismo, aunque era solo una CLI (interfaz de línea de comandos) en lugar de una (interfaz gráfica). Estas herramientas también harán que el uso del trazador sea más rápido y sencillo.

Por ejemplo, en el siguiente ejemplo, uso mi perf_tool para rastrear un nuevo proceso:

# ./execsnoopTracing exec()s Ctrl-C para finalizar.

PID PPID ARGS.

22898 22004 man ls

22905 22898 preconv -e UTF-8

22908 22898 buscapersonas -s

22907 22898 nroff -mandoc -rLL= 164n -rLT=164n -Tutf8

[...]

En Netflix, creamos un Vector, una instancia de una herramienta de análisis y el front-end final para rastreador en Linux.

Para ingenieros de rendimiento o kernel

Nuestro trabajo se está volviendo cada vez más difícil y mucha gente nos preguntará cómo rastrearlo y qué ruta se puede utilizar. Para comprender correctamente un camino, a menudo es necesario dedicar al menos 100 horas a hacerlo. Comprender todos los caminos de Linux para tomar decisiones racionales es una tarea enorme. (Probablemente soy el único que ha estado cerca de hacer esto)

Aquí están mis sugerencias:

A) Elija un camino universal, y estandarizarlo implicaría gastar un mucho tiempo descubriendo los matices y la seguridad del mismo en un entorno de prueba. Ahora recomiendo la última versión de SystemTap (es decir, creada desde el código fuente). Sé que algunas empresas han elegido LTTng y lo están utilizando muy bien, aunque no es muy potente (aunque es más seguro). Sysdig podría ser otro candidato si puede agregar puntos de seguimiento o kprobes.

B) Siguiendo el diagrama de flujo que proporcioné anteriormente, significará usar ftrace o perf_event tanto como sea posible, eBPF se integrará y luego otras rutas como SystemTap/LTTng llenarán el vacío. Eso es lo que estoy haciendo actualmente en Netflix.

comentarios de tracer:

1. ftrace

Me gusta usar ftrace, es la primera opción de los piratas informáticos del kernel, integrado en el kernel del sistema, usted puede Utilice puntos de seguimiento (punto de control estático), puede llamar a las herramientas de depuración kprobes y uprobes del kernel. Y proporciona varias de estas funciones: función de seguimiento de eventos con filtros y parámetros opcionales, funciones de sincronización y recuento de eventos para estadísticas en el kernel y función de recorrido de flujo de funciones; Puede echar un vistazo al ejemplo ftrace.txt en el código del kernel para comprenderlo. ftrace está controlado por /sys y solo es compatible con un único usuario root (pero puedes modificarlo para que admita varios usuarios a través de una instancia de búfer). A veces, la interfaz de operación de Ftrace es muy engorrosa, pero de hecho es muy "pirateada" y tiene una interfaz frontal. Steven Rostedt, el autor principal de ftace, creó la herramienta de comando trace-cmd y yo creé el conjunto de herramientas perf. Mi mayor queja con esta herramienta es que no es programable. Por ejemplo, no puede guardar y recuperar marcas de tiempo, calcular retrasos y guardar los resultados de estos cálculos en forma de histograma. Debe volcar los eventos al nivel de usuario y tomarse un tiempo para procesar los resultados. ftrace se puede hacer programable a través de eBPF.

2.perf_events

perf_events es la principal herramienta de seguimiento para usuarios de Linux. Está integrada en el código fuente del kernel y generalmente se agrega a través de linux-tools-commom. También llamado "perf", al igual que el nombre de la herramienta de front-end, generalmente se usa para rastrear y volcar información en un archivo llamado perf.data. El archivo perf.data es equivalente a un búfer dinámico para guardar los resultados. que deben ser procesados ​​más tarde.

La mayor parte de lo que ftrace puede hacer, perf_events también lo puede hacer. perf-events no puede realizar un recorrido de flujo de funciones, lo cual es un poco menos "truco" (pero tiene mejor soporte para seguridad/verificación de errores). Puede realizar perfiles de CPU y estadísticas de rendimiento, análisis de pila a nivel de usuario y también puede utilizar información de depuración generada al rastrear variables locales en cada línea. También admite operaciones simultáneas multiusuario. Al igual que ftrace, no admite programabilidad. Si tuviera que recomendar solo un trazador, sería perf. Resuelve numerosos problemas y es relativamente seguro.

3. eBPF

El filtro de paquetes Berkeley extendido (eBPF) es una máquina virtual de kernel (JIT) eficiente que puede ejecutar programas en eventos. Eventualmente puede proporcionar programación del kernel para ftrace y perf_events, y mejorar otros rastreadores. Alexei Starovoitov lo está desarrollando actualmente y aún no está completamente integrado, pero a partir de la versión 4.1 hay suficiente soporte del kernel para algunas herramientas excelentes, como mapas de calor de latencia para E/S de dispositivos de bloque. Consulte las diapositivas de BPF y las muestras de eBPF de su autor principal, Alexei Starovoitov.

4. SystemTap

SystemTap es el rastreador más potente. Hace de todo, como creación de perfiles, puntos de seguimiento, sondas, uprobes (de SystemTap), USDT y programación del kernel, etc. Compila el programa en un módulo del kernel y luego lo carga, lo cual es una forma inteligente de ganar seguridad. También se desarrolla a partir de árboles y ha tenido muchos problemas (muchos terribles) en el pasado. Gran parte de esto no es culpa de SystemTap: a menudo es el primero en utilizar el seguimiento del kernel y el primero en encontrar errores. Las últimas versiones de SystemTap son mucho mejores (y deben compilarse desde el código fuente), pero muchas personas todavía se sienten intimidadas por las versiones anteriores. Si desea utilizarlo, úselo primero en un entorno de prueba y hable con los desarrolladores de #systemtap en irc.freenode.net. (Netflix es tolerante a fallas y ya usamos SystemTap, pero tal vez pensamos menos en la seguridad que usted). Mi mayor queja es que parece pensar que tiene información de depuración del kernel que a menudo no tiene. De hecho, es posible hacer mucho sin él, pero falta documentación y ejemplos (tuve que empezar a aprenderlo todo por mi cuenta).

5. LTTng

LTTng optimiza la recopilación de eventos, que es mejor que otros rastreadores. Fue desarrollado a partir de un árbol y su núcleo es simple: escribir eventos en el búfer de seguimiento a través de un pequeño conjunto de instrucciones fijas. Este método lo hace seguro y rápido. La desventaja es que no tiene una manera fácil de codificar en el kernel. . Siempre he oído que esto no es un gran problema porque a pesar del posprocesamiento requerido, ya está optimizado hasta el punto en que se mide adecuadamente. Además, fue pionero en una técnica de análisis diferente, más registros en caja negra de todos los eventos de interés que se estudiarán más adelante en forma de GUI. Mi preocupación es cómo resolver el problema de los eventos faltantes que no se consideraron en la etapa inicial para su registro, pero lo que realmente quiero hacer es dedicar más tiempo a ver cómo funciona en la práctica. Este es el rastreador al que le dediqué menos tiempo (sin ningún motivo en particular).

6. Ktap

ktap era un rastreador prometedor en el pasado. Utilizaba la máquina virtual Lua en el kernel para procesar dispositivos integrados sin información de depuración. Se dividió en varios pasos y por un tiempo pareció superar a todos los rastreadores en Linux. Luego, eBPF comienza la integración del kernel, mientras que la integración de ktap comienza solo después de que puede usar eBPF en lugar de su propia máquina virtual. Dado que eBPF seguirá integrado durante varios meses, los desarrolladores de ktap tendrán que esperar un poco más. Espero que sea remodelado a finales de este año.

7.dtrace4linux

dtrace4linux fue completado principalmente por Paul Fox en su tiempo libre. Es la versión para Linux de Sun DTrace. Es interesante y hay algunos proveedores que funcionan, pero todavía está algo incompleto y es más bien una herramienta experimental (insegura). Creo que la gente será cautelosa a la hora de contribuir con código a dtrace4linux debido a problemas de licencia: dado que DTrace de código abierto de Sun usaba el protocolo CDDL en aquel entonces, es poco probable que dtrace4linux eventualmente ingrese al kernel de Linux. Lo más probable es que el enfoque de Paul lo convierta en un complemento. Me encantaría ver DTrace en la plataforma Linux y este proyecto completado, y creo que dedicaré algún tiempo a ayudar con este proyecto cuando me una a Netflix. Sin embargo, seguiré usando los rastreadores integrados como ftrace y perf_events.

8.OL DTrace

Oracle Linux DTrace ha hecho grandes esfuerzos para introducir DTrace en Linux, especialmente en Oracle Linux. Múltiples versiones lanzadas a lo largo de los años demuestran su progreso constante. Los desarrolladores hablan de mejorar el conjunto de pruebas DTrace de forma prometedora para el proyecto. Se han implementado muchos proveedores útiles, como: syscall, perfil, sdt, proc, sched y USDT. Estoy deseando que se complete fbt (rastreo de límites de funciones, para seguimiento dinámico del kernel), que es un gran proveedor en el kernel de Linux. El éxito final de OL DTrace dependerá de cuánto interés haya en ejecutar Oracle Linux (pagando por soporte técnico) y, por otro lado, de si es completamente de código abierto: sus elementos del kernel son de código abierto y no veo un nivel de usuario para su código.

9. sysdig

sysdig es un nuevo rastreador que utiliza una sintaxis similar a tcpdump para rastrear eventos del sistema operativo. Utiliza lua para enviar procesos. Es genial y ha revolucionado el mundo del seguimiento de sistemas. Su limitación es que solo realiza llamadas al sistema en el momento actual, volcando todos los eventos al nivel de usuario mientras la confirmación está en progreso. Puedes hacer mucho con las llamadas al sistema, sin embargo, me hubiera gustado tener soporte para tracepoints, kprobes y uprobes. También espero con ansias que admita eBPF para resúmenes del kernel. Actualmente, los desarrolladores de sysdig están agregando soporte para contenedores. Esté atento a estos.

Lectura ampliada

Mi trabajo en tracer incluye:

ftrace: mi conjunto de herramientas perf-tools (consulte el directorio de ejemplo). net Artículos sobre ftrace; discurso de LISA14; y publicaciones: conteo de funciones, iosnoop, opensnoop, execsnoop, reenvío TCP, uprobes y USDT.

perf_evenets: instancia de perf_events de mi página web; habla sobre el análisis de rendimiento de Linux de SCALE Netflix; también publica muestreos de CPU, puntos de seguimiento estáticos, mapas de calor, recuentos, seguimientos de líneas del núcleo y gráficos de tiempo fuera de la CPU.

eBPF: Publicar eBPF: Un pequeño paso y algunas herramientas de BPF (necesito publicar más).

SystemTap: Hace mucho tiempo escribí una publicación algo retrasada sobre el uso de SystemTap. Recientemente, lancé algunas herramientas systemtap-lwtools para demostrar cómo usar SystemTap sin información de diagnóstico del kernel.

LTTng: Sólo dediqué un poco de tiempo, no el suficiente para publicar nada.

ktap: Mi instancia web de ktap contiene algunas versiones anteriores de frases ingeniosas y guiones.

dtrace4linux: di algunos ejemplos en el libro Rendimiento del sistema y desarrollé algunas pequeñas correcciones, como marcas de tiempo.

OL DTrace: dado que se deriva directamente de DTrace, gran parte de mi trabajo anterior en DTrace está relacionado (sería demasiado dar un enlace aquí, puedes buscarlo en mi página de inicio). Cuando esté más completo, desarrollaré algunas herramientas especiales.

sysdig: contribuí con código para archivos de espectrograma de desplazamiento más lento y de subsegundos.

Otros: Escribí sobre notas en strace.

¡No más rastreadores, por favor! Si se pregunta por qué Linux no tiene solo un rastreador, o simplemente usa su propio DTrace, puede encontrar la respuesta en mi charla de DTrace a Linux, que comienza con la diapositiva 28.

Gracias a Deirdré Straughan por editar y rastrear ponis con General Zoi, el creador de My Little Pony.