Ir al contenido 
Voy a mostrar cómo bpftrace en entornos de alojamiento Linux reduce drásticamente el tiempo necesario para localizar la causa de un error y, al mismo tiempo, Núcleo-que permite aprovechar las señales. En lugar de ir a ciegas, mido las llamadas al sistema, las latencias de E/S y los eventos de red en tiempo real en el eBPF-Contexto: sin detener los servicios.
Puntos centrales
Los siguientes puntos clave ofrecen una visión general rápida de los aspectos principales de este artículo.
- Una visión en profundidad en llamadas al sistema, E/S y red directamente desde el núcleo
- Baja sobrecarga gracias a los programas eBPF seguros del núcleo
- Localización rápida de cuellos de botella en los procesos, las E/S y las bases de datos
- Seguimiento flexible con filtros, histogramas y trazas de pila
- Flujo de trabajo en la consulta para incidentes graves en cuestión de minutos
Por qué bpftrace permite detectar más rápidamente los problemas en el alojamiento web
En las estructuras de alojamiento modernas, muchos servicios compiten por Recursos, mientras que los paneles de control clásicos suelen mostrar solo valores superficiales. Yo voy un paso más allá: bpftrace se acopla a las llamadas al sistema, los puntos de rastreo y los ganchos de función, y me muestra qué es lo que realmente ralentiza el sistema. Los tiempos de espera con una carga de CPU discreta suelen indicar latencias de E/S o llamadas bloqueantes. Es precisamente ahí donde bpftrace destaca con recuentos, histogramas de latencia y trazas de pila directamente desde el Núcleo. De este modo, asigno las fuentes de carga a procesos, contenedores o consultas concretos y actúo de forma específica.
Cómo interactúan eBPF y bpftrace
eBPF ejecuta programas pequeños y verificados en el Núcleo y proporciona eventos de primera mano. bpftrace compila scripts en tiempo de ejecución en código byte eBPF y los vincula a sondas, filtros y acciones. Por ejemplo, elijo un punto de seguimiento para las lecturas de archivos, filtro por nombre de proceso y agrego las latencias en un histograma. El patrón „sonda – filtro – acción“ sigue siendo sencillo de gestionar, incluso cuando mido varias señales al mismo tiempo. Así, en cuestión de minutos construyo una observación que me proporciona los datos decisivos Indicadores suministros.
Frases ingeniosas para situaciones de emergencia
En situaciones de emergencia, la rapidez es fundamental. Utilizo frases breves y concisas que muestran un patrón en cuestión de segundos. Estas son algunas de mis frases iniciales de probada eficacia:
# Contar los accesos „ruidosos“ a archivos por nombre de proceso (borrar cada 5 s)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'
Histograma de latencia # para lecturas de archivos (por proceso)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
@lat[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
Agrupar las retransmisiones TCP # con las pilas del núcleo
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'
# Sumar los tiempos de SoftIRQ (ventana de 10 s)
bpftrace -e '
tracepoint:irq:softirq_entry { @t[args->vec] = nsecs; }
tracepoint:irq:softirq_exit /@t[args->vec]/ {
@soft[args->vec] = sum(nsecs - @t[args->vec]);
delete(@t[args->vec]);
}
interval:s:10 { print(@soft); clear(@soft); }'
Mostrar la carga de # accept() en el servidor de base de datos o en el servidor web
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'
Con estas „sondas“ puedo detectar rápidamente si un servicio abre un número anormal de archivos, si la E/S se ralentiza o si la red se satura. A continuación, afino los filtros para PID, nombres de procesos o rutas.
Diagnóstico de procesos y recursos en servidores en producción
Si una sola cuenta o un solo contenedor ralentiza un servidor compartido, cuento las llamadas al sistema por Proceso y localizo las fuentes de „ruido“. Un número llamativo de llamadas a execve indica un inicio excesivo de procesos, lo que delata, por ejemplo, tareas de cron defectuosas. Si un servicio abre innumerables archivos, lo detecto de inmediato y limito la comprobación a determinadas rutas mediante filtros. Para servidores web muy concurridos, esto tiene un valor incalculable, ya que me permite aislar rápidamente las fuentes de interferencias. Quien quiera profundizar en ideas sobre herramientas, puede consultar además enfoques sobre Herramientas de análisis de eBPF y aplica el principio a sus propios servidores.
Vista de contenedores y Kubernetes con cgroups
En servidores multitenant o de Kubernetes necesito una separación clara entre clientes. Para ello, bpftrace me ofrece la cgroup-La perspectiva como clave:
# Agrupar llamadas al sistema por cgroup (contenedor) y nombre de proceso
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'
Así puedo identificar qué contenedor es el que genera ruido sin tener que recopilar manualmente los PID uno por uno. Para realizar análisis más específicos, aplico filtros adicionales:
# Analizar únicamente PHP-FPM (por ejemplo, en un contenedor de aplicaciones)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'
En Kubernetes suelo medir en el Nodo y agruparé por cgroup. Documentaré la asignación de los ID de cgroup a los nombres de los pods y contenedores en mi runbook (kubectl/CRI), para poder hacer referencia a los resultados de las mediciones de forma clara.
Medir de forma fiable las latencias de E/S y del sistema de archivos
La lentitud de las páginas, a pesar de tener una CPU „aceptable“, suele indicar E/S-Puntos de estrangulamiento. Mido las operaciones de lectura y escritura por proceso, registro las rutas lentas y elaboro histogramas de latencia. En entornos de WordPress, esto me permite detectar si son muchos archivos PHP pequeños o archivos multimedia de gran tamaño los que limitan el rendimiento. A continuación, decido si lo más eficaz es aplicar primero el almacenamiento en caché, la caché de opcodes de PHP o un ajuste del sistema de archivos. Quien quiera profundizar más, encontrará información adicional sobre Latencias de disco en el almacenamiento y puede ajustar los puntos de medición de forma específica.
Mostrar los tiempos de espera «off-CPU» y «lock»
No todo el tiempo de espera corresponde a E/S: los subprocesos pueden fuera de la CPU bloquear —por ejemplo, en Locks—. Para ello utilizo eventos de Futex y del programador.
Tiempos de espera de Futex # (contendencia de bloqueos) en forma de histograma
bpftrace -e '
tracepoint:syscalls:sys_enter_futex { @ts[tid] = nsecs; }
tracepoint:syscalls:sys_exit_futex /@ts[tid]/ {
@futex[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
Con estos perfiles puedo ver si los trabajadores de PHP-FPM o los hilos de la base de datos están esperando bloqueos. Combinándolo con los historiales de E/S, desconecto Almacenamiento- de Concurrencia-Problemas.
Mostrar los errores de red, las SoftIRQ y las retransmisiones
Las quejas sobre los tiempos de espera esporádicos las atribuyo a menudo a Red-Señales de retransmisión. Superviso las retransmisiones TCP, los eventos RST y las desconexiones directamente en el núcleo. Además, echo un vistazo a las SoftIRQ, ya que las colas de red sobrecargadas dejan allí rastros. El patrón formado por las retransmisiones y el aumento de los tiempos de SoftIRQ indica pérdidas de paquetes, cuellos de botella en los búferes o problemas de calidad de servicio (QoS). Un buen complemento para la identificación de las causas son los artículos de fondo sobre SoftIRQ y rendimiento de la red, que relaciono con las mediciones de bpftrace.
Caso práctico: Alojamiento de WordPress con tiempos de espera 504 esporádicos
Un servidor compartido muestra un error 504; la CPU solo está al 35%. Mi procedimiento:
- Hipótesis „Red o E/S“. Inicio las retransmisiones y la medición del tiempo de las SoftIRQ. Resultado: pocas retransmisiones, SoftIRQ estables.
- Cambio a E/S: el histograma de latencia de vfs_read muestra una cola larga de hasta 80 ms para php-fpm. Muchas llamadas a openat por solicitud.
- Filtrar por rutas bajo «wp-content» y «wp-includes»: predominan innumerables lecturas de archivos pequeños.
- Contraverificación de los «locks»: Futex-Histo sin anomalías; no hay contención de «locks».
- Medida: ajustar la configuración de OPCache para almacenar en caché los recursos estáticos de forma más agresiva. A raíz de ello, se reducirán los recuentos de «openat» y las latencias.
Con menos de 15 minutos de rastreo activo, queda claro: no es la red, sino Entrada/salida de archivos y ausencia de almacenamiento en caché provocan los tiempos de espera.
Bases de datos y PHP-FPM: cómo identificar rápidamente los cuellos de botella
En MySQL/MariaDB, analizo las llamadas al sistema, los bloqueos y las latencias de E/S de la Procesos de la base de datos . Realizo un seguimiento de las fases «accept» y «connect» para comprobar si las conexiones se ralentizan o si los handshakes TLS se bloquean. En el caso de PHP-FPM, compruebo si el uso de «execve» y los accesos a archivos son anormalmente elevados, lo que indicaría una falta de almacenamiento en caché. Mediante los trazas de pila en determinadas llamadas al sistema, identifico en qué punto del código se están atascando las solicitudes. De este modo, descarto paso a paso la red, la aplicación y la base de datos hasta encontrar el punto más crítico. Lugar.
Buenas prácticas para servidores productivos
Empiezo cada seguimiento con una clara Planteamiento y limito las pruebas con filtros. Los límites temporales o los intervalos permiten mantener el volumen de datos bajo control. Para los análisis recurrentes, guardo scripts con filtros predeterminados útiles, como el PID, el cgroup o el nombre del proceso. Antes de utilizarlos en los servidores de los clientes, pruebo los scripts más complejos en sistemas de prueba. De este modo, la sobrecarga es mínima y evito Efectos secundarios.
Calidad de la medición, sobrecarga y límites en la práctica
bpftrace mantiene una sobrecarga de CPU de un porcentaje de un solo dígito con sondas específicas, siempre que tenga en cuenta lo siguiente:
- Filtrado en la entrada: Filtro desde el principio (por ejemplo, por comm/PID), en lugar de esperar a filtrar en Maps.
- Muestreo: Para muestras muy calientes, utilizo el muestreo, por ejemplo, 1% de los eventos:
tracepoint:syscalls:sys_enter_openat / rand() % 100 == 0 / { @[comm] = count(); } - Trazas de pila concisas: kstack/ustack solo cuando sea necesario: primero contar, luego profundizar.
- Tamaño del búfer: Cuando se producen picos de eventos, aumento el tamaño del búfer circular:
export BPFTRACE_PERF_RB_PAGES=4096 - Mantener la ventana abierta brevemente: Los intervalos (5-30 s) y un final claro evitan la confusión en los datos.
Si veo „eventos perdidos“, aumento el búfer, reduzco la profundidad de la pila o aplico filtros más estrictos. Para mayor precisión, prefiero Puntos de seguimiento (ABI estable) frente a kprobes (los nombres de las funciones del kernel pueden variar).
Seguridad, gobernanza y normas de multitenencia
En los servidores compartidos, presto especial atención a Protección de datos y unos ámbitos bien definidos. Realizo el rastreo de señales técnicas, no de datos de clientes, y documento el motivo, el alcance y la duración. Para entornos multitenant, establezco directrices fijas: quién puede iniciar el rastreo, qué filtros son necesarios y cuándo lo detengo. Minimizo o seudonimizo los registros que contienen rutas sensibles. De este modo, obtengo datos técnicos útiles sin traspasar los límites de los tenants y mantengo la Conformidad en.
Instalación y requisitos previos en servidores Linux modernos
Para bpftrace utilizo Linux 5.x, porque las funciones y Estabilidad allí son notablemente mejores, aunque se considera que 4,9 es el límite mínimo. Instalo bpftrace mediante apt o dnf e incluyo los encabezados del kernel en cuanto se necesitan sondas más complejas. A continuación, compruebo las configuraciones de cgroups, los entornos de ejecución de contenedores y los módulos de seguridad que regulan el acceso a las sondas. Una breve prueba con puntos de seguimiento sencillos garantiza que las firmas y los símbolos coincidan. De este modo, nada se interpone en un inicio estructurado y puedo realizar las primeras Medidas conducir.
Portabilidad: BTF, resolución de símbolos y sondas estables
Para crear scripts robustos, apuesto por BTF-Información sobre el tipo (vmlinux) que ayuda a bpftrace a resolver los campos. Si falta, prefiero utilizar puntos de traza en lugar de kprobes. Para uprobes (En el espacio de usuario) necesito binarios sin eliminar los símbolos o símbolos de depuración independientes; esto resulta especialmente útil en el caso de PHP-FPM o mysqld. Compruebo las versiones con „bpftrace –info“ y incluyo un pequeño bloque de compatibilidad en los scripts, por si los nombres de los eventos varían en función del kernel.
Flujo de trabajo en la consulta: del síntoma a la causa en 15 minutos
En primer lugar, voy a formular la Hipótesis: ¿Red, E/S, CPU o base de datos? Entonces configuro un rastreo rápido en el nivel más probable, por ejemplo, en las retransmisiones o en las latencias de los archivos. Si los primeros minutos apuntan a un patrón, afino los filtros, añado trazas de pila y limito el tiempo de ejecución. Si se confirma la sospecha, realizo mediciones más detalladas en el servicio afectado y solo registro las rutas relevantes. Con este enfoque evito avanzar a ciegas y llego rápidamente a la causa más concreta Causa.
Manual de procedimientos: Intervención inicial de 15 minutos
- Minuto 0-2: Seleccionar hipótesis (red/E/S/CPU/base de datos). Iniciar el «Baseline One-Liner».
- Minutos 3-5: Identificar la primera anomalía (por ejemplo, un recuento elevado de «openat», retransmisiones, histogramas de «Futex»).
- Minutos 6-8: Optimizar los filtros (comm/PID/cgroup, rutas) y añadir histogramas de latencia.
- Minutos 9-12: Activa los rastros de pila solo en el punto caliente para hacer visibles las partes del código.
- Minutos 13-15: Determinar la medida a tomar (almacenamiento en caché, límites, cambio de configuración) y probarla brevemente.
Tabla comparativa: ventajas y usos en el día a día
En la tabla siguiente se muestran los Probes, su ámbito de aplicación y una ventaja clave en el contexto del alojamiento web. Las utilizo como guía rápida cuando quiero elegir rápidamente el punto de medición adecuado.
| Tipo de muestra | Utilice | Ejemplo | Beneficio |
|---|---|---|---|
| tracepoint:syscalls | Contar/filtrar llamadas al sistema | sys_enter_openat, execve | „Sonidos“ Procesos Encuentre |
| kprobe/kretprobe | Medir las funciones del núcleo | vfs_read, tcp_retransmit | E/S y red-Latencias visible |
| uprobes/uretprobes | Rastrear funciones de Userland | Iconos de mysqld y php-fpm | Localizar puntos de acceso a bases de datos y aplicaciones |
| tracepoint:net/* | Identificar eventos de networking | Retransmisiones TCP, RST | Tiempo de espera-Causas delimitar |
| perf events | Perspectiva de la CPU y del programador | Perfiles «on-cpu» y «off-cpu» | Detectar cuellos de botella en la programación |
Resumen para administradores y profesionales de DevOps
bpftrace me da un error grave Lente en señales del núcleo y de las aplicaciones que la monitorización clásica suele pasar por alto. Empiezo poco a poco, filtro de forma selectiva y controlo los tiempos de ejecución para que los resultados de la medición sean claros. Con unas pocas líneas de script, detecto el ruido de los procesos, las latencias de los archivos, las retransmisiones de red y los tiempos de espera de las bases de datos. Este enfoque reduce notablemente el tiempo medio de resolución (Mean Time to Resolution) en los servidores de producción. Quien integre bpftrace en su flujo de trabajo resuelve los incidentes de alojamiento de forma específica y mantiene los sitios web y las API notablemente receptivo.
