Decodificación de eBPF Observabilidad:

Se ha hablado mucho sobre eBPF en las comunidades nativas de la nube durante los últimos 2 años. eBPF fue un en KubeCon, y están creciendo rápidamente en popularidad, empresas como Google y Netflix han estado durante años y surgen nuevos casos de uso todo el tiempo. Especialmente en la observabilidad, se espera que eBPF cambie las reglas del juego.

Entonces, echemos un vistazo a eBPF: ¿qué es la tecnología, cómo está afectando la observabilidad, cómo se compara con las prácticas de observabilidad existentes y qué podría deparar el futuro?

¿Qué es realmente eBPF?

eBPF es un marco de programación que nos permite ejecutar de forma segura programas de espacio aislado en el kernel de Linux sin cambiar el código del kernel.

Originalmente se desarrolló para Linux (y todavía es donde la tecnología está más madura en la actualidad), pero Microsoft está evolucionando rápidamente con la .

Los programas eBPF son, por diseño, altamente eficientes y seguros: el núcleo los verifica para garantizar que no pongan en riesgo la estabilidad o la seguridad del sistema operativo.

Entonces, ¿por qué eBPF es tan importante?

Para entender esto, necesitamos entender el espacio de usuario y el espacio del kernel.

El espacio de usuario es donde se ejecutan todas las aplicaciones. El espacio del kernel se encuentra entre el espacio del usuario y el hardware físico. Las aplicaciones en el espacio del usuario no pueden acceder al hardware directamente. En cambio, hacen llamadas al sistema al kernel, que luego accede al hardware.

Todo el acceso a la memoria, la lectura/escritura de archivos y el tráfico de red pasan por el núcleo. El núcleo también gestiona procesos concurrentes.

Básicamente, todo pasa por el kernel (vea la figura siguiente). Y eBPF proporciona una forma segura de ampliar la funcionalidad del núcleo.

Históricamente, por razones obvias, cambiar cualquier cosa en el código fuente del kernel o en la capa del sistema operativo ha sido muy difícil.

El kernel de Linux tiene , y se necesitan varios años para que cualquier cambio pase de ser una idea a estar ampliamente disponible. Primero, la comunidad de Linux tiene que estar de acuerdo. Luego, tiene que convertirse en parte del lanzamiento oficial de Linux. Luego, después de unos meses, lo recogen distribuciones como Red Hat y Ubuntu, que lo llevan a un público más amplio.

Técnicamente, uno podría cargar módulos de kernel en el kernel de uno y hacer cambios directamente, pero esto es un riesgo muy alto e implica una programación compleja a nivel de kernel, por lo que se evita casi universalmente.

eBPF aparece y resuelve esto, y brinda un mecanismo seguro y eficiente para adjuntar y ejecutar programas en el kernel.

Veamos cómo eBPF garantiza tanto la seguridad como el rendimiento.

Altamente seguro

• Verificación estricta : antes de que cualquier programa eBPF se pueda cargar en un kernel, se verifica mediante el verificador eBPF , lo que garantiza que el código sea absolutamente seguro, por ejemplo, sin bucles duros, acceso a memoria no válido, operaciones inseguras.

  
  

• Sandboxed : los programas eBPF se ejecutan en un sandbox con memoria aislada dentro del kernel, separado de otros componentes del kernel. Esto evita el acceso no autorizado a la memoria del kernel, las estructuras de datos y el código fuente del kernel.

  
  

• Operaciones limitadas : los programas eBPF generalmente deben escribirse en un pequeño subconjunto del lenguaje C: un conjunto de instrucciones restringido. Esto limita las operaciones que pueden realizar los programas eBPF, lo que reduce el riesgo de vulnerabilidades de seguridad.

Alto rendimiento / ligero

• Ejecutar como código de máquina nativo : los programas eBPF se ejecutan como instrucciones de máquina nativas en la CPU. Esto conduce a una ejecución más rápida y un mejor rendimiento.

  
  

• Sin cambios de contexto : una aplicación normal cambia de contexto regularmente entre el espacio del usuario y el espacio del núcleo, lo que requiere muchos recursos. Los programas eBPF, ya que se ejecutan en la capa del kernel, pueden acceder directamente a las estructuras de datos y recursos del kernel.

  
  

• Impulsado por eventos : los programas eBPF generalmente se ejecutan solo en respuesta a eventos específicos del kernel en lugar de estar siempre activos. Esto minimiza los gastos generales.

  
  

• Optimizado para hardware : el compilador JIT (Just-In-Time) del kernel compila los programas eBPF en código de máquina justo antes de la ejecución, por lo que el código está optimizado para el hardware específico en el que se ejecuta.

  
  

Entonces, eBPF proporciona un gancho seguro y eficiente en el núcleo para la programación. Y dado que todo pasa por el kernel, esto abre varias posibilidades nuevas que no eran posibles hasta ahora.

¿Por qué es esto un gran problema sólo ahora ?

La tecnología en torno a eBPF ha evolucionado durante mucho tiempo y lleva unos 30 años en desarrollo.

En los últimos 7 u 8 años, varias grandes empresas han utilizado eBPF a gran escala y ahora estamos entrando en una era en la que el uso de eBPF se está convirtiendo en la corriente principal. Vea , cocreador de Linux y comantenedor de eBPF, sobre la evolución de eBPF.

eBPF - una breve historia

• 1993: un del Lawrence Berkeley National Lab explora el uso de un agente kernel para el filtrado de paquetes. De ahí proviene el nombre BPF ("Berkeley Packet Filter").
• 1997 - BPF se presenta oficialmente como parte del kernel de Linux (versión 2.1.75).
• 1997-2014: se agregan varias características para mejorar, estabilizar y expandir las capacidades de BPF.
• 2014: se presenta una actualización importante, denominada "filtro de paquetes de Berkeley extendido" (eBPF). Esta versión realiza grandes cambios en la tecnología BPF y la hace más utilizable, de ahí la palabra "extendida".

  
  

La razón por la que este lanzamiento fue grande fue porque facilitó la extensión de la funcionalidad del kernel.

Un programador podría codificar más o menos como lo haría con una aplicación normal, y la infraestructura eBPF circundante se encarga de la verificación, la seguridad y la eficiencia de bajo nivel. Todo un ecosistema de apoyo y un andamiaje alrededor de eBPF lo hacen posible (ver la figura a continuación).

Fuente: Aún mejor, los programas eBPF se pueden cargar y descargar desde el kernel sin reiniciar. Todo esto permitió repentinamente una adopción y aplicación generalizadas.

Adopción generalizada en los sistemas de producción

La popularidad de eBPF se ha disparado en los últimos 7 u 8 años, con varias grandes empresas usándolo en sistemas de producción a escala.

• En 2016, Netflix usaba ampliamente eBPF para el rastreo. , quien lo implementó, se volvió ampliamente conocido en los círculos de infraestructura y operaciones como una autoridad en eBPF.
• 2017: de código abierto de Facebook, su balanceador de carga basado en eBPF. Todos los paquetes enviados a desde 2017 han pasado por eBPF.
• 2020: Google hizo eBPF parte de su oferta de Kubernetes. eBPF ahora impulsa la de GKE. A estas alturas, también existe una amplia adopción empresarial en empresas como y .
• 2021: Facebook, Google, Netflix, Microsoft e Isovalent se unieron para anunciar la para gestionar el crecimiento de la tecnología eBPF.

  
  

Ahora hay miles de empresas que utilizan eBPF y cientos de proyectos de eBPF que surgen cada año para explorar diferentes casos de uso.

eBPF ahora es un subsistema separado dentro del kernel de Linux con una amplia comunidad para respaldarlo. La tecnología en sí se ha expandido considerablemente con varias adiciones nuevas.

Entonces, ¿qué podemos hacer con eBPF?

Los casos de uso más comunes para eBPF se encuentran en 3 áreas:

1. Redes
2. Seguridad
3. Observabilidad

La seguridad y las redes han tenido una adopción y una aplicación más amplias, impulsadas por proyectos como . En comparación, las ofertas de observabilidad basadas en eBPF son más tempranas en su evolución y apenas están comenzando.

Veamos primero los casos de uso en seguridad y redes.

Seguridad

La seguridad es un caso de uso muy popular para eBPF. Usando eBPF, los programas pueden observar todo lo que sucede a nivel del kernel, procesar eventos a alta velocidad para verificar comportamientos inesperados y generar alertas mucho más rápido que de otra manera.

Por ejemplo -

• usa eBPF para la detección de intrusos a escala
• usa eBPF para implementar la seguridad de los contenedores

  
  

Varias ahora usan eBPF para recopilar y monitorear datos.

Redes

La creación de redes es otro caso de uso ampliamente aplicado. Estar en la capa eBPF permite una observabilidad integral de la red, como la visibilidad de la ruta completa de la red, incluidos todos los saltos, junto con la IP de origen y destino. Con los programas eBPF, uno puede procesar eventos de red de gran volumen y manipular paquetes de red directamente dentro del núcleo con una sobrecarga muy baja.

Esto permite varios casos de uso de redes, como equilibrio de carga, prevención de DDoS, modelado de tráfico y calidad de servicio (QoS).

• usa eBPF para detectar y prevenir ataques DDoS, procesando sin afectar el rendimiento de la red.
• , basado en eBPF de Meta, equilibra la carga de todo Facebook

Observabilidad

A estas alturas, debe ser sencillo cómo eBPF puede ser útil en Observabilidad.

Todo pasa por el núcleo. Y eBPF proporciona una forma segura y de alto rendimiento de observar todo desde el kernel.

Profundicemos más en la observabilidad y veamos las implicaciones de esta tecnología.

¿Cómo afecta exactamente eBPF a la observabilidad?

Para explorar esto, salgamos del universo eBPF y entremos en el universo de Observabilidad y veamos qué constituye nuestra solución de observabilidad estándar.

Cualquier solución de observabilidad tiene 4 componentes principales:

1. Recopilación de datos : obtención de datos de telemetría de aplicaciones e infraestructura

2. Procesamiento de datos : filtrado, indexación y realización de cálculos en los datos recopilados

3. Almacenamiento de datos : almacenamiento de datos a corto y largo plazo

4. Capa de experiencia del usuario : determinar cómo el usuario consume los datos

   
   

De esto, lo que impacta eBPF (a partir de hoy) es realmente solo la capa de recopilación de datos: la fácil recopilación de datos de telemetría directamente desde el kernel utilizando eBPF.

Entonces, lo que queremos decir cuando decimos "observabilidad eBPF" hoy, es usar eBPF como mecanismo de instrumentación para recopilar datos de telemetría, en lugar de usar otros métodos de instrumentación. Otros componentes de una solución de observabilidad no se ven afectados.

Cómo funciona la observabilidad de eBPF

Para comprender completamente los mecanismos subyacentes detrás de la observabilidad de eBPF, debemos comprender el concepto de ganchos.

Como vimos anteriormente, los programas eBPF se basan principalmente en eventos, es decir, se activan cada vez que ocurre un evento específico. Por ejemplo, cada vez que se realiza una llamada de función, se puede llamar a un programa eBPF para capturar algunos datos con fines de observación.

Primero, estos ganchos pueden estar en el espacio del núcleo o en el espacio del usuario. Por lo tanto, eBPF se puede usar para monitorear tanto las aplicaciones del espacio del usuario como los eventos a nivel del kernel.

En segundo lugar, estos ganchos pueden ser predeterminados/estáticos o insertarse dinámicamente en un sistema en ejecución (¡sin reinicios!)

Cuatro mecanismos eBPF distintos permiten cada uno de estos (ver la figura a continuación)

	Predeterminado/Manual	Dinámica
Núcleo	Puntos de seguimiento del kernel	ksondas
espacio de usuario	USDT	sube

Enlaces eBPF estáticos y dinámicos en el espacio del usuario y el espacio del kernel

1. Puntos de seguimiento del kernel : se utilizan para conectarse a eventos predefinidos por los desarrolladores del kernel (con macros TRACE_EVENT)

2. USDT : se utiliza para conectarse a puntos de seguimiento predefinidos establecidos por los desarrolladores en el código de la aplicación

3. Kprobes (Kernel Probes): se utiliza para conectarse dinámicamente a cualquier parte del código del kernel en tiempo de ejecución

4. Uprobes (User Probes): se utiliza para conectarse dinámicamente a cualquier parte de una aplicación de espacio de usuario en tiempo de ejecución

   
   

Hay varios ganchos predefinidos en el espacio del kernel a los que uno puede adjuntar fácilmente un programa eBPF (por ejemplo, llamadas al sistema, entrada/salida de funciones, eventos de red, puntos de seguimiento del kernel). De manera similar, en el espacio del usuario, muchos tiempos de ejecución de lenguajes, sistemas de bases de datos y pilas de software exponen ganchos predefinidos para las herramientas BCC de Linux a las que se pueden conectar los programas eBPF.

Pero lo que es más interesante son kprobes y uprobes. ¿Qué pasa si algo se rompe en la producción y no tengo suficiente información y quiero agregar instrumentación dinámicamente en tiempo de ejecución? Ahí es donde kprobes y uprobes permiten una observabilidad poderosa.

Por ejemplo, al usar uprobes, uno puede conectarse a una función específica dentro de una aplicación sin modificar el código de la aplicación, en tiempo de ejecución . Cada vez que se ejecuta la función, se puede activar un programa eBPF para capturar los datos requeridos. Esto permite posibilidades emocionantes como la depuración .

Ahora que sabemos cómo funciona la observabilidad con eBPF, veamos los casos de uso.

Casos de uso de observabilidad de eBPF

eBPF se puede utilizar para casi todos los casos de uso comunes de observabilidad existentes y, además, abre nuevas posibilidades.

1. Supervisión del sistema y la infraestructura: eBPF permite una supervisión profunda de los eventos a nivel del sistema, como el uso de la CPU, la asignación de memoria, la E/S del disco y el tráfico de red. Por ejemplo, .

   
   

2. Supervisión de contenedores y Kubernetes: visibilidad de las métricas específicas de Kubernetes, el uso de recursos y el estado de contenedores y pods individuales.

   
   

3. Monitoreo del rendimiento de la aplicación (APM): observabilidad detallada de las aplicaciones del espacio del usuario y visibilidad del rendimiento de la aplicación, las tasas de error, la latencia y las trazas.

   
   

4. Observabilidad personalizada: visibilidad de métricas personalizadas específicas de aplicaciones o infraestructura que pueden no estar fácilmente disponibles sin escribir un código personalizado.

   
   

5. Observabilidad avanzada: eBPF se puede usar para casos de uso de observabilidad avanzada, como , y .

   
   

Cada día surgen nuevas aplicaciones de eBPF en Observabilidad.

¿Qué significa esto para la forma en que se realiza la observabilidad hoy en día? ¿Es probable que eBPF reemplace las formas existentes de instrumentación? Comparemos con las opciones existentes.

eBPF vs métodos de instrumentación existentes

Hoy en día, existen dos formas principales de instrumentar aplicaciones e infraestructura para Observabilidad, además de eBPF.

1. Instrumentación basada en agentes: SDK/bibliotecas de software independientes integradas en el código de la aplicación o nodos de infraestructura para recopilar datos de telemetría.

1. Instrumentación basada en proxy sidecar : los sidecars son procesos ligeros e independientes que se ejecutan junto con una aplicación o servicio. Son populares en microservicios y arquitecturas basadas en contenedores como Kubernetes.

   
   

Para obtener una comparación detallada de cómo la instrumentación basada en eBPF se compara con agentes y sidecars, . A continuación se muestra una vista resumida:

	eBPF	Agentes	Sidecars
1. Visibilidad de datos/Granualidad	Alto (pero con algunas lagunas)	Alto	Bajo
2. Intrusión	Bajo (fuera de banda)	Alto (en línea)	Alto (en línea)
3. Gastos generales de rendimiento	Bajo	Medio	Alto
4. Seguridad y Protección	Alto	Medio	Medio
5. Facilidad de implementación	Alto	Bajo	Medio
6. Facilidad de mantenimiento y actualizaciones	Alto	Bajo	Medio
7. Escalabilidad	Alto	Medio	Bajo

Como podemos ver, eBPF supera a los métodos de instrumentación existentes en casi todos los parámetros. Hay varios beneficios -

1. Puede cubrir todo de una sola vez (infraestructura, aplicaciones)

2. Menos intrusivo : eBPF no está en línea con las cargas de trabajo en ejecución como los agentes de código, que se ejecutan cada vez que se ejecuta la carga de trabajo. La recopilación de datos está fuera de banda y en un espacio aislado, por lo que no hay impacto en un sistema en ejecución.

3. Sobrecarga de bajo rendimiento : eBPF se ejecuta como código de máquina nativo y no hay cambio de contexto.

4. Más seguro : gracias a las medidas de seguridad integradas, como la verificación.

5. Fácil de instalar : se puede instalar sin cambiar el código ni reiniciar.

6. Fácil de mantener y actualizar , de nuevo sin cambio de código y reinicios.

7. Más escalable : impulsado por una fácil implementación y mantenimiento, y una sobrecarga de bajo rendimiento

   
   

En términos de contras, la brecha principal con la observabilidad de eBPF hoy en día está en el rastreo distribuido ( , pero el caso de uso aún se encuentra en las primeras etapas).

En balance, dadas las ventajas significativas que ofrece eBPF sobre los métodos de instrumentación existentes, podemos esperar razonablemente que eBPF emerja como la plataforma de instrumentación predeterminada de próxima generación.

Implicaciones para la observabilidad

¿Qué significa esto para la industria de la observabilidad? ¿Que cambios? Imagine una solución de observabilidad:

• que puedes colocar en el kernel en 5 minutos
• sin cambio de código o reinicios
• cubre todo de una sola vez: infraestructura, aplicaciones, todo
• tiene una sobrecarga cercana a cero
• es muy seguro

  
  

Eso es lo que eBPF hace posible. Y esa es la razón por la que hay tanto entusiasmo en torno a la tecnología.

Podemos esperar que la próxima generación de soluciones de observabilidad esté equipada con eBPF en lugar de agentes de código.

Los jugadores tradicionales como Datadog y NewRelic ya están invirtiendo en la construcción de instrumentación basada en eBPF para aumentar su cartera de agentes basada en código. Mientras tanto, hay varios proveedores de próxima generación basados en eBPF, que resuelven y .

Mientras que los jugadores tradicionales tenían que crear agentes de código individuales idioma por idioma y para cada componente de la infraestructura durante varios años, los nuevos jugadores pueden alcanzar el mismo grado de cobertura en unos pocos meses con eBPF. Esto les permite centrarse también en innovar más arriba en la cadena de valor, como el procesamiento de datos, la experiencia del usuario e incluso . Además, sus capas de procesamiento de datos y experiencia del usuario también se construyen desde cero para admitir los nuevos casos de uso, volúmenes y frecuencia.

Todo esto debería impulsar una gran cantidad de innovación en este espacio y hacer que la observabilidad sea más fluida, segura y fácil de implementar en los próximos años.

¿Quién debería usar la observabilidad eBPF?

En primer lugar, si se encuentra en un entorno nativo de la nube moderno (Kubernetes, microservicios), las diferencias entre los enfoques basados en eBPF y basados en agentes son más visibles (sobrecarga de rendimiento, seguridad, facilidad de instalación, etc.).

En segundo lugar, si está operando a gran escala, los agentes ligeros basados en eBPF impulsarán mejoras dramáticas sobre el statu quo. Esta es probablemente una de las razones por las que la adopción de eBPF ha sido más alta en empresas de tecnología con huellas masivas como LinkedIn, Netflix y Meta.

Tercero, si te falta tecnología. capacidad y está buscando una solución de observabilidad que no requiera casi ningún esfuerzo para instalar y mantener, entonces vaya directamente a una solución basada en eBPF.

Resumen

En resumen, al ofrecer un mecanismo de instrumentación significativamente mejor, eBPF tiene el potencial de remodelar fundamentalmente nuestro enfoque de la observabilidad en los próximos años.

Si bien en este artículo exploramos principalmente la aplicación de eBPF en la recopilación/instrumentación de datos, las aplicaciones futuras podrían ver el uso de eBPF en el procesamiento de datos o incluso en las capas de almacenamiento de datos. Las posibilidades son amplias y aún no exploradas.

Referencias

También publicado