bcc tools en la práctica: guía práctica para la ingeniería de rendimiento en Linux con eBPF

Te voy a explicar paso a paso cómo Herramientas de BCC utilizo eBPF para identificar y resolver rápidamente los cuellos de botella en los servidores Linux. Para ello, utilizo flujos de trabajo prácticos, mido las latencias reales en el núcleo y relaciono los eventos de la CPU, las E/S y la red para obtener una borrar Análisis de las causas.

Puntos centrales

• eBPF Ofrece un seguimiento detallado con una carga mínima.
• Herramientas de BCC abarcan la CPU, las E/S, la red y los procesos.
• Cercano a la producción Se puede utilizar sin necesidad de modificar la aplicación.
• Lista de control con diez herramientas para empezar.
• Seguridad mediante Verifier y unas políticas claras.

¿Por qué utilizar eBPF para la ingeniería de rendimiento en Linux?

Busco eBPF, porque quiero medir los eventos del kernel de forma segura, selectiva y con muy poca sobrecarga. Las herramientas clásicas muestran totales, pero rara vez explican por qué los hilos están en espera, por qué se reenvían los paquetes o por qué se bloquea la E/S; eBPF cubre esta laguna con concreto Eventos. Los programas se ejecutan en el núcleo, el verificador los comprueba previamente y puedo iniciarlos sin necesidad de reiniciar el sistema. De este modo, correlaciono las llamadas del espacio de usuario con las rutas del núcleo y obtengo una visión general que permite realizar optimizaciones inmediatas. Quien desee profundizar en el tema, encontrará una visión general en mi breve introducción a la Análisis del rendimiento de eBPF, que describe la interacción entre el rastreo y la observabilidad.

¿Qué son las herramientas de BCC y dónde las puedo encontrar?

El cco Las herramientas «tools» son programas de diagnóstico ya preparados basados en eBPF y suelen encontrarse en /usr/share/bcc/tools. Las ejecuto directamente desde el shell, obtengo resultados claros en la salida estándar y no tengo que modificar mis aplicaciones. La colección abarca procesos, llamadas al sistema, sistemas de archivos, E/S de bloques, red, programadores y análisis de rendimiento, por lo que resulta adecuada para productivo Análisis. Como activo el rastreo de forma selectiva, la influencia es mínima y los errores de medición debidos a la supervisión son insignificantes. Para casos más complejos, complemento las herramientas con mi propio eBPF o utilizo además perfiles de muestreo.

Instalación y requisitos

Voy a instalar la cco Herramientas disponibles a través del gestor de paquetes (bcc-tools o bpfcc-tools) en las distribuciones más habituales. Se requiere un kernel con soporte para eBPF (a partir de la versión 4.x, preferiblemente 4.9 o superior), funciones BPF activadas y permisos suficientes para cargar los programas. En servidores de producción, compruebo previamente las capacidades de eBPF del núcleo y de la distribución en un entorno de prueba, para que las mediciones posteriores fiable funcionan. Evito los perfiles de seguridad que bloquean completamente eBPF mediante políticas adaptadas. Las breves instrucciones sobre Herramientas de análisis de eBPF.

Antes de la salida: comprobaciones del sistema y de seguridad

Antes de realizar mediciones en producción, compruebo las capacidades básicas del host. De este modo, evito errores iniciales y obtengo resultados reproducibles.

• Comprobar las características del núcleo: uname -r y las funciones BPF disponibles (por ejemplo, mediante Feature-Check). Son importantes kprobes/tracepoints, BTF (para obtener información estable sobre los tipos) y los eventos perf.
• Derechos y políticas: Me aseguro de que solo los usuarios autorizados puedan cargar eBPF (CAP_BPF/CAP_SYS_ADMIN o la política correspondiente) y de que los perfiles LSM no bloqueen la carga.
• Parámetros del sistema: kernel.unprivileged_bpf_disabled Suele estar activo en entornos productivos. Por eso, trabajo deliberadamente desde sesiones seguras y con un control de auditoría claro.
• Rutas transparentes: Considero que los directorios como /sys/kernel/debug/tracing y /sys/fs/bpf en mente, para eliminar los artefactos tras las mediciones.

Esta rigurosidad me permite realizar mediciones de forma precisa y reproducible, sin efectos secundarios.

Guía práctica: Las diez primeras herramientas

Para realizar una comprobación rápida del rendimiento, sigo un orden fijo. De este modo, delimito con claridad las causas relacionadas con la CPU, las E/S o la red, y decido si debo profundizar en las pilas o en los tiempos de respuesta. La tabla muestra la función principal de las herramientas y la cuestión que pretendo aclarar con ellas. Al principio mantengo la duración de la ejecución breve y repito las mediciones en cuanto tengo alguna sospecha confirmar quiero. Así evito los puntos ciegos y no pierdo tiempo en situaciones de emergencia Incidentes.

Herramienta	Observado	Pregunta típica
execsnoop	Nuevos procesos	¿Quién crea puestos de trabajo efímeros que generan carga?
opensnoop	Apertura de archivos	¿Qué rutas se abren o se registran constantemente?
ext4 más lento (xfs*, btrfs*, zfs*)	Operaciones FS lentas	¿Qué visitas presentan latencias elevadas por volumen?
biolatencia	Distribución de E/S en bloques	¿Se producen picos de latencia esporádicos o continuos?
biosnoop	Solicitudes de E/S individuales	¿Qué proceso hace que determinados dispositivos dejen de funcionar?
cachestat	Comportamiento de la caché de páginas	¿Merece la pena aumentar la memoria RAM o la aplicación sufre fallos?
tcpconnect	Nuevas conexiones TCP	¿Quién recurre a qué servicio y con qué frecuencia?
tcpaccept	Conexiones aceptadas	¿Qué sockets de servidor están sometidos a una carga elevada?
tcpretrans	Retransmisiones	¿La pérdida de paquetes indica que las rutas son inestables?
runqlat	Latencias del programador	¿Los hilos esperan demasiado tiempo para obtener tiempo de CPU?

También utilizo perfiles para detectar puntos críticos en el espacio de usuario o del núcleo y agregar pilas de llamadas. De este modo, detecto expresiones regulares costosas, controladores ineficientes o spinlocks, que luego corrijo en el código o en la configuración. Utilizo intervalos de muestreo cortos y comparo varias ejecuciones para detectar valores atípicos visible . Esta combinación de visión general y análisis en profundidad me ahorra mucho tiempo de análisis. A continuación, vuelvo a probar la optimización con la misma carga.

Ampliación: hacer visibles las operaciones fuera de la CPU, los bloqueos y los tiempos de espera

No toda la latencia elevada está relacionada con la CPU. A menudo, los hilos „fuera de la CPU“ esperan a que se produzcan operaciones de E/S, bloqueos o activaciones. En estos casos, resultan útiles las herramientas y los perfiles complementarios de bcc:

• Análisis «Off-CPU»: Mido cuánto tiempo pasan los hilos fuera de la CPU y qué pilas conducen hasta allí. Esto permite diferenciar el tiempo de cálculo del tiempo de espera y muestra los bloqueos.
• Contendencia de bloqueos: analizo específicamente los bloqueos críticos del núcleo y del espacio de usuario. Los tiempos de retención prolongados o las altas tasas de contendencia indican puntos de serialización que procuro eliminar (por ejemplo, mediante fragmentación, una granularidad más fina u otras estructuras de datos).
• Rutas de activación: las latencias entre „se ha activado“ y „vuelve a funcionar“ revelan problemas de programación y prioridades, o un tamaño excesivo de los grupos de trabajadores.

Correlaciono estas señales con runqlat y biolatencia, para distinguir entre causas relacionadas con la memoria, las E/S y el programador.

Higiene en las mediciones: filtros, duración, umbrales

Para que las mediciones de eBPF sigan siendo reproducibles, sigo tres reglas básicas:

• De forma breve y concisa: al principio, solo dejo que las herramientas se ejecuten durante un breve periodo de tiempo (por ejemplo, entre 10 y 30 segundos) y me centro en los PID, contenedores o sockets sospechosos.
• Establecer umbrales: con las herramientas „*slower*“, filtro las latencias pequeñas para reducir el ruido y ver solo las llamadas problemáticas.
• Limitar la tasa: Utilizo filtros selectivos (por ejemplo, nombre del proceso, TID, puertos) para mantener bajas las tasas de eventos. De este modo, la sobrecarga es mínima y evito que se pierdan eventos.

Solo cuando veo un patrón, prolongo la duración o amplío el alcance. De este modo consigo limpiar y muestras representativas.

Escenario práctico 1: Carga de la CPU inexplicablemente alta

Si el indicador de la CPU muestra valores elevados de forma constante, empiezo por execsnoop, para detectar procesos de corta duración. A continuación, mido con runqlat cuánto tiempo esperan los hilos a que la CPU les asigne tiempo de ejecución y compruebo si las colas de ejecución están saturadas o si las prioridades son inadecuadas. Si se observan tiempos de espera excesivos, reduzco el número de trabajadores, modifico los grupos de hilos o distribuyo mejor las tareas programadas para que el programador agarra puedo. Con «profile» recopilo «stacks» y localizo los verdaderos puntos críticos en las bibliotecas y en mi propio código. Solo cuando reúno toda esta información, tomo decisiones sobre límites, recolección de basura, afinidades o opciones del compilador.

Escenario práctico 2: Latencias de E/S y aplicaciones lentas

Si los usuarios se quejan de que el sistema se cuelga con una baja carga de la CPU, compruebo con ext4 más lento Llamadas lentas al sistema de archivos por proceso. A continuación, utilizo «biolatency» para analizar la distribución de los tiempos de E/S por bloques por dispositivo, con el fin de detectar picos esporádicos o cuellos de botella persistentes. «biosnoop» me muestra si un servicio concreto está generando un número excesivo de pequeñas escrituras y, con ello, provocando colas que ralentizan a otros procesos. Con «cachestat» compruebo si la caché de páginas acierta o si se producen fallos. dominar y que más RAM sería de ayuda. Al final, decidiré si merece la pena optar por escrituras por lotes, búferes más grandes o cambiar a un almacenamiento más rápido.

Escenario práctico 3: Rutas de red y microservicios

En entornos distribuidos, empiezo con tcpconnect, para medir el establecimiento de conexiones entre servicios. A continuación, compruebo con tcpaccept qué sockets del servidor tienen un número especialmente elevado de entradas y si se aplican los límites por parte del listener. tcpretrans detecta los reenvíos y distingue los problemas de transporte de los errores de aplicación antes de ajustar los tiempos de espera y los reintentos. Con estas tres señales, puedo ver si la red, la aplicación o un servicio de nivel superior es el responsable de la Latencia . A continuación, ajusto las estrategias de backoff, los valores de keepalive, la configuración del equilibrador de carga y los tamaños de los búferes.

Seguridad operativa y fiabilidad de eBPF

Solo subo fiable Pruebo primero mis propios programas eBPF en el entorno de staging. El verificador del núcleo bloquea los programas defectuosos, pero además establezco límites para los mapas y los búferes, con el fin de que el uso de la memoria se mantenga dentro de unos límites adecuados. Conservo los registros para supervisar el comportamiento y los efectos secundarios, y poder intervenir rápidamente si es necesario. Las políticas establecen quién puede cargar eBPF, de modo que el control permanezca en manos del equipo de la plataforma y se cumplan los requisitos de seguridad. Estas reglas garantizan que el rastreo en entornos de producción Fiable se mantiene y no da lugar a sorpresas.

Entornos de contenedores y Kubernetes

En los contenedores, separo los problemas sistemáticos de los efectos específicos de cada pod. Para ello, filtro las mediciones por cgroup, espacio de nombres o rango de PID. Muchas herramientas de bcc permiten filtrar por nombre o ID de proceso; como alternativa, realizo las mediciones en el host y asigno los eventos a las cargas de trabajo mediante cgroup. Importante:

• Espacio de nombres de PID: los PID son diferentes entre el host y el contenedor. Asigno los ID o los filtro por nombre de proceso o puerto.
• Cuotas de recursos: la limitación de la CPU mediante las cuotas del CFS se manifiesta en largos tiempos de espera sin que el sistema esté a plena capacidad. Lo detecto a través de runqlat en combinación con métricas de cuotas.
• Espacios de nombres de red: Para los análisis de sockets, me aseguro de utilizar el espacio de nombres correcto. Realizo las mediciones en la interfaz del host y las correlaciono con las direcciones IP y los puertos de los pods.

De este modo, los resultados de las mediciones siguen siendo fiables, incluso cuando hay muchas cargas de trabajo ejecutándose muy próximas entre sí.

Integración en pilas de observabilidad

No voy a sustituir mi sistema de seguimiento, sino que lo voy a complementar con eBPF. Las herramientas de bcc me proporcionan la profundidad, mientras que los sistemas de métricas, los registros y el APM muestran la amplitud; juntos ofrecen una visión coherente. Cuando es necesario, redirijo los rastros de bcc a los flujos de registros, activo instantáneas ante incidentes y documento los resultados con el equipo. Para perfiles puntuales, utilizo el muestreo además de las líneas temporales de las métricas, con el fin de detectar anomalías tangible . Quien prefiera utilizar scripts como complemento, encontrará en bpftrace en el alojamiento web Una forma sencilla de responder a preguntas puntuales con miniescritos.

Obstáculos habituales y cómo los supero

• «Noisy Neighbor»: algunos trabajos generan una carga de corta duración, pero muy intensa. execsnoop y perfiles Estos patrones los detecto de forma fiable; los organizo en intervalos de tiempo o los aíslo mediante cuotas.
• NUMA y afinidades: las altas latencias, a pesar de que hay núcleos libres, indican accesos entre zonas NUMA. Compruebo las afinidades de la CPU, la asignación de memoria y la distribución de las IRQ.
• Puntos críticos de IRQ/SoftIRQ: la carga de red puede saturar los núcleos ksoftirqd. Superviso las retransmisiones, distribuyo las IRQ a través de RSS/colas y ajusto los valores de RPS/XPS.
• Efectos de la caché de página: los arranques en frío son más lentos. Tengo en cuenta las fases de calentamiento y comparo cachestat-Valores antes y después de la carga.
• Actualizaciones del núcleo: los Kprobes pueden cambiar al pasar de una versión a otra. Yo prefiero los puntos de seguimiento estables, los pruebo de antemano y tengo preparado un conjunto mínimo.

Procedimientos que han demostrado su eficacia

• Instantánea del incidente: ejecución combinada de 60 a 120 segundos (execsnoop, runqlat, biolatency, tcpretrans, profile). A continuación, me centro en el subsistema que llama la atención.
• Rutina de referencia: mediciones breves semanales en las rutas principales (por ejemplo, perfil de almacenamiento y de red). De este modo, detecto las desviaciones a tiempo.
• Validación de cambios: antes y después de los cambios de configuración, comparo los mismos puntos de medición para poder cuantificar el efecto.

Ingeniería continua del rendimiento de Linux

Para mí, la performance es un proceso continuo, no un Acción puntual. En CI/CD integro comprobaciones breves basadas en eBPF para detectar las regresiones de forma temprana y detenerlas antes del lanzamiento. Durante las ventanas de mantenimiento, mido las rutas típicas bajo carga, establezco valores de referencia y documento los rangos de latencia aceptables. De este modo, detecto rápidamente las desviaciones y evito tener que dar palos de ciego durante la gestión de incidencias, ya que dispongo de datos comparativos disponible. Esta rutina contribuye directamente a la disponibilidad, al control de costes y a la experiencia del usuario.

Mini-caso práctico: del síntoma a la causa en 12 minutos

Un clúster de API indica un aumento de las latencias de 99p, mientras que el RPS se mantiene sin cambios. Inicio una instantánea de incidencia: tcpconnect no muestra anomalías en el establecimiento de la conexión, tcpretrans sigue siendo baja, pero la red no lo es, al parecer. runqlat indica tiempos de espera breves, pero frecuentes; perfiles muestra los puntos de acceso en un formato JSON. Al mismo tiempo, observo con cachestat una caída de las tasas de aciertos de la caché durante los picos. La correlación sugiere que se trata de muchas cargas útiles pequeñas que se serializan de forma sincronizada y se escriben de inmediato.

Lo verifico con ext4 más lento, que muestra fsyncs de varios milisegundos de duración en el mismo volumen para el proceso de la API; biolatencia Confirma picos esporádicos en la cola del dispositivo afectado. Medida correctiva: agrupar las operaciones de escritura, aumentar el tamaño del búfer y realizar el vaciado asíncrono en puntos menos sensibles. Tras la implementación, las latencias al 99.º percentil se reducen en un 35 %, la tasa de aciertos de la caché se recupera y runqlat vuelve a mostrar distribuciones estrechas.

Resumen para la práctica

Con cco Gracias a las herramientas y a eBPF, consigo una visión clara del rendimiento de la CPU, las E/S y la red en poco tiempo, sin necesidad de modificar las aplicaciones. La lista de herramientas, compuesta por execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans y runqlat, constituye un punto de partida coherente. Además, utilizo «profile» para identificar los puntos críticos y optimizar las rutas de código. Gracias a unas políticas, un registro y unos límites bien definidos, el uso en el núcleo seguro y fácil de entender. Quien aplique este método de forma sistemática resolverá los problemas de rendimiento más rápidamente, planificará mejor las capacidades y reducirá los costes por solicitud.