Decodificando a observabilidade do eBPF:

Tem havido muita conversa sobre o eBPF em comunidades nativas da nuvem nos últimos 2 anos. O eBPF foi um da KubeCon, e estão crescendo rapidamente em popularidade, empresas como Google e Netflix há anos e novos casos de uso estão surgindo o tempo todo. Especialmente em observabilidade, espera-se que o eBPF seja um divisor de águas.

Então, vamos olhar para o eBPF - o que é a tecnologia, como ela está impactando a observabilidade, como ela se compara com as práticas de observabilidade existentes e o que o futuro reserva?

O que é realmente o eBPF?

eBPF é uma estrutura de programação que nos permite executar com segurança programas em área restrita no kernel do Linux sem alterar o código do kernel.

Ele foi originalmente desenvolvido para Linux (e ainda é onde a tecnologia está mais madura atualmente), mas a Microsoft está desenvolvendo rapidamente a .

Os programas eBPF são altamente eficientes e seguros por design - eles são verificados pelo kernel para garantir que não arrisquem a estabilidade ou a segurança do sistema operacional.

Então, por que o eBPF é importante?

Para entender isso, precisamos entender o espaço do usuário e o espaço do kernel.

O espaço do usuário é onde todos os aplicativos são executados. O espaço do kernel fica entre o espaço do usuário e o hardware físico. Os aplicativos no espaço do usuário não podem acessar o hardware diretamente. Em vez disso, eles fazem chamadas de sistema para o kernel, que então acessa o hardware.

Todo o acesso à memória, leitura/gravação de arquivos e tráfego de rede passam pelo kernel. O kernel também gerencia processos concorrentes.

Basicamente, tudo passa pelo kernel (veja a figura abaixo). E o eBPF fornece uma maneira segura de estender a funcionalidade do kernel.

Historicamente, por razões óbvias, alterar qualquer coisa no código-fonte do kernel ou na camada dos sistemas operacionais tem sido muito difícil.

O kernel do Linux tem e leva vários anos para que qualquer mudança passe de uma ideia para uma ampla disponibilidade. Primeiro, a comunidade Linux precisa concordar com isso. Então, ele deve se tornar parte do lançamento oficial do Linux. Então, depois de alguns meses, ele é escolhido por distribuições como Red Hat e Ubuntu, que o levam a um público mais amplo.

Tecnicamente, pode-se carregar módulos do kernel para o próprio kernel e fazer alterações diretamente, mas isso é um risco muito alto e envolve programação complexa no nível do kernel, portanto, é quase universalmente evitado.

O eBPF vem e resolve isso - e fornece um mecanismo seguro e eficiente para anexar e executar programas no kernel.

Vejamos como o eBPF garante segurança e desempenho.

Altamente seguro

• Verificação rigorosa - Antes que qualquer programa eBPF possa ser carregado em um kernel, ele é verificado pelo verificador eBPF , que garante que o código seja absolutamente seguro - por exemplo, sem loops rígidos, acesso inválido à memória, operações inseguras.

  
  

• Sandboxed - os programas eBPF são executados em uma sandbox isolada de memória dentro do kernel, separada de outros componentes do kernel. Isso evita o acesso não autorizado à memória do kernel, estruturas de dados e código-fonte do kernel.

  
  

• Operações limitadas - os programas eBPF normalmente precisam ser escritos em um pequeno subconjunto da linguagem C - um conjunto restrito de instruções. Isso limita as operações que os programas eBPF podem realizar, reduzindo o risco de vulnerabilidades de segurança.

Alto desempenho / leve

• Executar como código de máquina nativo - os programas eBPF são executados como instruções de máquina nativas na CPU. Isso leva a uma execução mais rápida e melhor desempenho.

  
  

• Sem trocas de contexto - Um aplicativo regular troca de contexto regularmente entre o espaço do usuário e o espaço do kernel, o que consome muitos recursos. Os programas eBPF, conforme executados na camada do kernel, podem acessar diretamente as estruturas e recursos de dados do kernel.

  
  

• Orientados a eventos - os programas eBPF normalmente são executados apenas em resposta a eventos específicos do kernel em vez de estarem sempre ativos. Isso minimiza a sobrecarga.

  
  

• Otimizado para hardware - os programas eBPF são compilados em código de máquina pelo compilador JIT (Just-In-Time) do kernel logo antes da execução, de modo que o código é otimizado para o hardware específico em que é executado.

  
  

Portanto, o eBPF fornece um gancho seguro e eficiente no kernel para programação. E como tudo passa pelo kernel, isso abre várias novas possibilidades que não eram possíveis até agora.

Por que isso é importante apenas agora ?

A tecnologia em torno do eBPF evoluiu ao longo de um longo período de tempo e levou aproximadamente 30 anos para ser desenvolvida.

Nos últimos 7 a 8 anos, o eBPF foi usado em escala por várias grandes empresas e agora estamos entrando em uma era em que o uso do eBPF está se tornando comum. Veja , co-criador do Linux e co-mantenedor do eBPF, sobre a evolução do eBPF.

eBPF - uma breve história

• 1993- Um do Lawrence Berkeley National Lab explora o uso de um agente de kernel para filtragem de pacotes. É daí que vem o nome BPF (“Berkeley Packet Filter”).
• 1997 - BPF é oficialmente introduzido como parte do kernel do Linux (versão 2.1.75).
• 1997-2014 - Vários recursos são adicionados para melhorar, estabilizar e expandir os recursos do BPF.
• 2014 - Uma atualização significativa é introduzida, chamada "Filtro de pacote Berkeley estendido" (eBPF). Esta versão faz grandes mudanças na tecnologia BPF e a torna mais amplamente utilizável - daí a palavra "estendido"

  
  

O motivo dessa versão ser grande é que isso facilitou a extensão da funcionalidade do kernel.

Um programador pode codificar mais ou menos como faria com um aplicativo regular - e a infraestrutura eBPF ao redor cuida da verificação, segurança e eficiência de baixo nível. Todo um ecossistema de suporte e estrutura em torno do eBPF tornam isso possível (veja a figura abaixo).

Fonte: Melhor ainda, os programas eBPF podem ser carregados e descarregados do kernel sem nenhuma reinicialização. Tudo isso de repente permitiu uma ampla adoção e aplicação.

Adoção generalizada em sistemas de produção

A popularidade do eBPF explodiu nos últimos 7-8 anos, com várias grandes empresas usando-o em sistemas de produção em escala.

• Em 2016, a Netflix estava usando amplamente o eBPF para rastreamento. , que o implementou, tornou-se amplamente conhecido nos círculos de infraestrutura e operações como uma autoridade em eBPF.
• 2017 - de código aberto do Facebook, seu balanceador de carga baseado em eBPF. Todos os pacotes para desde 2017 passaram pelo eBPF.
• 2020- O Google tornou o eBPF parte de sua oferta Kubernetes. O eBPF agora capacita a do GKE. Até agora, também há ampla adoção corporativa em empresas como e .
• 2021 - Facebook, Google, Netflix, Microsoft e Isovalent se uniram para anunciar a para gerenciar o crescimento da tecnologia eBPF.

  
  

Agora existem milhares de empresas usando eBPF e centenas de projetos de eBPF surgindo a cada ano explorando diferentes casos de uso.

O eBPF agora é um subsistema separado dentro do kernel do Linux com uma ampla comunidade para apoiá-lo. A própria tecnologia se expandiu consideravelmente com várias novas adições.

Então, o que podemos fazer com o eBPF?

Os casos de uso mais comuns para eBPF estão em 3 áreas -

1. rede
2. Segurança
3. Observabilidade

A segurança e a rede tiveram uma adoção e aplicação mais ampla, impulsionadas por projetos como . Em comparação, as ofertas de observabilidade baseadas em eBPF estão no início de sua evolução e estão apenas começando.

Vejamos primeiro os casos de uso em segurança e rede.

Segurança

Segurança é um caso de uso altamente popular para eBPF. Usando o eBPF, os programas podem observar tudo o que acontece no nível do kernel, processar eventos em alta velocidade para verificar comportamentos inesperados e emitir alertas muito mais rapidamente do que de outra forma.

Por exemplo -

• usa eBPF para detecção de intrusão em grande escala
• usa eBPF para implementar segurança de container

  
  

Várias agora usam eBPF para coleta e monitoramento de dados.

rede

A rede é outro caso de uso amplamente aplicado. Estar na camada eBPF permite a observação abrangente da rede, como visibilidade do caminho completo da rede, incluindo todos os saltos, juntamente com o IP de origem e destino. Com programas eBPF, é possível processar eventos de rede de alto volume e manipular pacotes de rede diretamente no kernel com sobrecarga muito baixa.

Isso permite vários casos de uso de rede, como balanceamento de carga, prevenção de DDoS, modelagem de tráfego e qualidade de serviço (QoS).

• usa o eBPF para detectar e prevenir ataques DDoS, processando sem afetar o desempenho da rede.
• baseado em eBPF da Meta faz balanceamento de carga para todo o Facebook

Observabilidade

Até agora deve estar claro como o eBPF pode ser útil em Observabilidade.

Tudo passa pelo kernel. E o eBPF fornece uma maneira segura e de alto desempenho de observar tudo do kernel.

Vamos mergulhar mais fundo na observabilidade e ver as implicações dessa tecnologia.

Como exatamente o eBPF impacta a observabilidade?

Para explorar isso, vamos sair do universo eBPF e entrar no universo de observabilidade e ver o que compõe nossa solução de observabilidade padrão.

Qualquer solução de observabilidade tem 4 componentes principais -

1. Coleta de dados - Obtendo dados de telemetria de aplicativos e infraestrutura

2. Processamento de dados - filtragem, indexação e execução de cálculos nos dados coletados

3. Armazenamento de dados - Armazenamento de dados de curto e longo prazo

4. Camada de experiência do usuário - Determinando como os dados são consumidos pelo usuário

   
   

Disso, o que o eBPF impacta (a partir de hoje) é realmente apenas a camada de coleta de dados - a fácil coleta de dados de telemetria diretamente do kernel usando o eBPF.

Então, o que queremos dizer quando dizemos "observabilidade do eBPF" hoje é usar o eBPF como o mecanismo de instrumentação para coletar dados de telemetria, em vez de usar outros métodos de instrumentação. Outros componentes de uma solução de observabilidade permanecem inalterados.

Como funciona a observabilidade do eBPF

Para entender completamente os mecanismos subjacentes à observabilidade do eBPF, precisamos entender o conceito de ganchos.

Como vimos anteriormente, os programas eBPF são principalmente orientados a eventos - ou seja, são acionados sempre que ocorre um evento específico. Por exemplo, toda vez que uma chamada de função é feita, um programa eBPF pode ser chamado para capturar alguns dados para fins de observabilidade.

Primeiro, esses ganchos podem estar no espaço do kernel ou no espaço do usuário. Portanto, o eBPF pode ser usado para monitorar aplicativos de espaço do usuário, bem como eventos no nível do kernel.

Em segundo lugar, esses ganchos podem ser pré-determinados/estáticos ou inseridos dinamicamente em um sistema em execução (sem reinicializações!)

Quatro mecanismos distintos de eBPF permitem cada um deles (veja a figura abaixo)

	Predeterminado/Manual	Dinâmico
Núcleo	Pontos de rastreio do kernel	kprobes
Espaço do usuário	USDT	questiona

O eBPF estático e dinâmico se conecta ao espaço do usuário e ao espaço do kernel

1. Pontos de rastreamento do kernel - usados para conectar-se a eventos predefinidos pelos desenvolvedores do kernel (com macros TRACE_EVENT)

2. USDT - usado para conectar-se a tracepoints predefinidos definidos por desenvolvedores no código do aplicativo

3. Kprobes (Kernel Probes) - usado para conectar-se dinamicamente a qualquer parte do código do kernel em tempo de execução

4. Upprobes (User Probes) - usado para se conectar dinamicamente a qualquer parte de um aplicativo de espaço de usuário em tempo de execução

   
   

Existem vários ganchos predefinidos no espaço do kernel aos quais é possível anexar facilmente um programa eBPF (por exemplo, chamadas de sistema, entrada/saída de função, eventos de rede, pontos de rastreamento do kernel). Da mesma forma, no espaço do usuário, muitos tempos de execução de linguagem, sistemas de banco de dados e pilhas de software expõem ganchos predefinidos para ferramentas BCC do Linux às quais os programas eBPF podem se conectar.

Mas o que é mais interessante são kprobes e uprobes. E se algo estiver quebrando na produção e eu não tiver informações suficientes e quiser adicionar instrumentação dinamicamente em tempo de execução? É aí que kprobes e uprobes permitem uma observabilidade poderosa.

Por exemplo, usando uprobes, pode-se conectar a uma função específica dentro de um aplicativo sem modificar o código do aplicativo, em tempo de execução . Sempre que a função é executada, um programa eBPF pode ser acionado para capturar os dados necessários. Isso permite possibilidades empolgantes, como depuração .

Agora que sabemos como a observabilidade com eBPF funciona, vamos ver os casos de uso.

Casos de uso de observabilidade de eBPF

O eBPF pode ser usado para quase todos os casos de uso comuns de observabilidade existentes e, além disso, abre novas possibilidades.

1. Monitoramento de sistema e infraestrutura: o eBPF permite o monitoramento profundo de eventos no nível do sistema, como uso de CPU, alocação de memória, E/S de disco e tráfego de rede. Por exemplo, .

   
   

2. Monitoramento de contêineres e Kubernetes: visibilidade das métricas específicas do Kubernetes, uso de recursos e integridade de contêineres e pods individuais.

   
   

3. Monitoramento de Desempenho de Aplicativos (APM): Observabilidade refinada em aplicativos de espaço de usuário e visibilidade de taxa de transferência, taxas de erro, latência e rastreamentos de aplicativos.

   
   

4. Observabilidade personalizada: Visibilidade em métricas personalizadas específicas para aplicativos ou infra que podem não estar facilmente disponíveis sem escrever código personalizado.

   
   

5. Observabilidade avançada: o eBPF pode ser usado para casos de uso de observabilidade avançada, como , e .

   
   

Existem novas aplicações de eBPF em Observabilidade surgindo todos os dias.

O que isso significa para como a observabilidade é feita hoje? É provável que o eBPF substitua as formas existentes de instrumentação? Vamos comparar com as opções existentes.

eBPF vs métodos de instrumentação existentes

Hoje, existem duas formas principais de instrumentar aplicações e infraestrutura para Observabilidade, além do eBPF.

1. Instrumentação baseada em agente: SDKs/bibliotecas de software independentes integrados ao código do aplicativo ou nós de infraestrutura para coletar dados de telemetria.

1. Instrumentação baseada em proxy sidecar : Sidecars são processos leves e independentes que são executados juntamente com um aplicativo ou serviço. Eles são populares em microsserviços e arquiteturas baseadas em contêineres, como o Kubernetes.

   
   

Para obter uma comparação detalhada de como a instrumentação baseada em eBPF se compara a agentes e sidecars, . Abaixo está uma visão resumida -

	eBPF	Agentes	Sidecars
1. Visibilidade/granualidade dos dados	Alta (mas com algumas lacunas)	Alto	Baixo
2. Intrusividade	Baixo (fora da banda)	Alto (em linha)	Alto (em linha)
3. Sobrecarga de desempenho	Baixo	Médio	Alto
4. Segurança e proteção	Alto	Médio	Médio
5. Facilidade de implementação	Alto	Baixo	Médio
6. Facilidade de manutenção e atualizações	Alto	Baixo	Médio
7. Escalabilidade	Alto	Médio	Baixo

Como podemos ver, o eBPF supera os métodos de instrumentação existentes em quase todos os parâmetros. Existem vários benefícios -

1. Pode abranger tudo de uma só vez (infraestrutura, aplicativos)

2. Menos intrusivo - o eBPF não está em linha com cargas de trabalho em execução, como agentes de código, que são executados sempre que a carga de trabalho é executada. A coleta de dados é fora de banda e em área restrita, portanto, não há impacto em um sistema em execução.

3. Baixa sobrecarga de desempenho - o eBPF é executado como código de máquina nativo e não há troca de contexto.

4. Mais seguro - devido a medidas de segurança integradas, como verificação.

5. Fácil de instalar - pode ser inserido sem qualquer alteração de código ou reinicialização.

6. Fácil de manter e atualizar - novamente sem alteração de código e reinicializações.

7. Mais escalável - impulsionado pela fácil implementação e manutenção e baixa sobrecarga de desempenho

   
   

Em termos de contras, a principal lacuna com a observabilidade do eBPF hoje está no rastreamento distribuído ( , mas o caso de uso ainda está em estágios iniciais).

Em suma, dadas as vantagens significativas que o eBPF oferece sobre os métodos de instrumentação existentes, podemos razoavelmente esperar que o eBPF surja como a plataforma padrão de instrumentação da próxima geração.

Implicações para a observabilidade

O que isso significa para a indústria de observabilidade? O que muda? Imagine uma solução de observabilidade:

• que você pode colocar no kernel em 5 minutos
• nenhuma mudança de código ou reinicia
• abrange tudo de uma vez - infraestrutura, aplicativos, tudo
• tem sobrecarga quase zero
• é altamente seguro

  
  

É isso que o eBPF torna possível. E essa é a razão pela qual há tanto entusiasmo em torno da tecnologia.

Podemos esperar que a próxima geração de soluções de observabilidade seja toda instrumentada com eBPF em vez de agentes de código.

Players tradicionais como Datadog e NewRelic já estão investindo na construção de instrumentação baseada em eBPF para aumentar seu portfólio de agentes baseados em código. Enquanto isso, existem vários fornecedores de próxima geração construídos no eBPF, resolvendo e para .

Enquanto os players tradicionais tiveram que construir agentes de código individuais idioma por idioma e para cada componente de infraestrutura ao longo de vários anos, os novos players podem obter o mesmo grau de cobertura em poucos meses com o eBPF. Isso permite que eles também se concentrem em inovar no topo da cadeia de valor, como processamento de dados, experiência do usuário e até . Além disso, suas camadas de processamento de dados e experiência do usuário também são construídas para suportar os novos casos de uso, volumes e frequência.

Tudo isso deve impulsionar uma grande quantidade de inovação neste espaço e tornar a observabilidade mais contínua, segura e fácil de implementar nos próximos anos.

Quem deve usar a observabilidade do eBPF?

Primeiro, se você estiver em um ambiente nativo de nuvem moderno (Kubernetes, microsserviços), as diferenças entre as abordagens baseadas em eBPF e baseadas em agente são mais visíveis (sobrecarga de desempenho, segurança, facilidade de instalação, etc.).

Em segundo lugar, se você estiver operando em grande escala, os agentes leves baseados em eBPF promoverão melhorias drásticas em relação ao status quo. Esta é provavelmente uma das razões pelas quais a adoção do eBPF tem sido maior em empresas de tecnologia com pegadas massivas como LinkedIn, Netflix e Meta.

Em terceiro lugar, se você estiver com falta de tecnologia. capacidade e estiver procurando uma solução de observabilidade que quase não exija esforço para instalar e manter, vá direto para uma solução baseada em eBPF.

Resumo

Em resumo, ao oferecer um mecanismo de instrumentação significativamente melhor, o eBPF tem o potencial de reformular fundamentalmente nossa abordagem de observabilidade nos próximos anos.

Embora neste artigo tenhamos explorado principalmente o aplicativo do eBPF na coleta/instrumentação de dados, os aplicativos futuros poderão ver o eBPF usado no processamento de dados ou mesmo nas camadas de armazenamento de dados. As possibilidades são amplas e ainda inexploradas.

Referências

Também publicado