Este artigo foi compilado a partir do discurso compartilhado por Xiang Yang, líder de produto DeepFlow da Yunshan Network, na QCon Global Software Development Conference (Pequim) 2024 , com o tema "eBPF + LLM: Infraestrutura para Realizar Agentes Observáveis". Revise o link e baixe o PPT .
Contagem regressiva para inscrições do segundo dia! Venha e participe do Meetup de desenvolvedores de código aberto de observabilidade da Nanjing Station |
Hoje tenho o prazer de compartilhar com vocês alguns dos trabalhos que o DeepFlow realizou em agentes de observabilidade. O tópico de hoje inclui principalmente dois aspectos: como usar o eBPF para resolver problemas de qualidade de dados e como usar o LLM para construir agentes eficientes com base nisso. A partir desses dois aspectos, podemos ver porque o eBPF e o LLM são infraestruturas essenciais para a realização de agentes de observabilidade .
A primeira questão acima é, na verdade, uma questão de governança de dados. Existem muitas maneiras de obter dados de alta qualidade, como usar especificações organizacionais e melhorar a eficiência da engenharia de P&D. O que estou compartilhando hoje é principalmente o último, especificamente como usar o eBPF, uma tecnologia inovadora, para obter dados de observabilidade full-stack com zero intrusão. Depois de termos dados de alta qualidade, podemos usar o LLM, combinado com engenharia de palavras imediatas, RAG, ajuste fino e outros métodos, para construir um agente observável eficiente. As práticas compartilhadas hoje vêm do nosso produto de observabilidade DeepFlow, que também é um projeto de código aberto cada vez mais popular. Por fim, também compartilharei meus pensamentos sobre a evolução dos agentes observáveis.
01
Crie fontes de sinais de observabilidade de alta qualidade usando eBPF
A essência da primeira questão é a governança de dados, com o objetivo de obter dados de observabilidade de alta qualidade. Vamos primeiro dar uma olhada nas soluções tradicionais. Por exemplo, usamos APM para coletar dados. Como garantir a integridade e relevância dos dados neste momento? Especialmente em um ambiente nativo da nuvem, quando o cliente acessa o servidor, ele pode passar por redes K8s complexas, vários gateways, vários middlewares, bancos de dados, DNS e outros serviços básicos. Esses links intermediários não são cobertos pelo APM. , até mesmo a localização observada do APM e a solicitação de rede real do processo serão diferentes. Quando fazemos governança e análise de dados com base nisso, geralmente descobrimos que há problemas com a integridade e consistência dos dados. Muitas vezes, leva muito tempo e energia para promover e melhorar a cobertura da instrumentação do lado comercial, e também levamos muito tempo e energia. precisa usar captura de pacotes e Logs e outros métodos são usados para concatenar dados heterogêneos de um grande número de serviços básicos. Acredita-se que a imagem abaixo seja um problema que frequentemente encontramos ao usar APM: o atraso observado pelo cliente é de 500ms, mas o atraso observado pelo servidor é de apenas 10ms. O pior é que o servidor pode não ter enviado a instrumentação. ainda.
Mais perto de casa, por que dizemos que o eBPF é a infraestrutura para fontes de sinais de observabilidade de alta qualidade ? A tecnologia eBPF é uma tecnologia programável de kernel. Cada abelhinha na imagem abaixo é uma posição de função que o eBPF pode enganchar. Podemos usar o eBPF para perceber todos os estados internos de qualquer processo no host da nuvem por meio de funções de negócios Hook, chamadas de sistema, funções de kernel, funções de rede e driver de disco. Mais importante ainda, esta ação é completamente segura devido à existência do verificador eBPF e, devido ao mecanismo de compilação JIT, seu desempenho é comparável ao código nativo do kernel.
A tecnologia eBPF tem duas vantagens exclusivas e pode resolver os problemas de qualidade de dados enfrentados pelo APM. A primeira vantagem é a intrusão zero (Código Zero) . A operação de um programa eBPF não requer modificação de código, recompilação ou reinicialização de qualquer processo de aplicação. É uma tecnologia plug-and-play que pode ser carregada em sua produção a qualquer momento. tempo. A segunda vantagem é o Full Stack . Seja um processo de negócios, um gateway, uma fila de mensagens, um banco de dados ou um sistema operacional, o eBPF pode ser usado para coletar dados de observação. Portanto, quando um processo está em execução, sua interação com toda a pilha de software, desde a lógica de negócios até o tempo de execução da linguagem, desde bibliotecas compartilhadas até o kernel e drivers de hardware, pode ser coberta usando eBPF. Na figura abaixo, podemos ver que os dados brutos que o eBPF pode coletar são muito ricos, incluindo: eventos de processo, eventos de arquivo, eventos de desempenho, eventos de soquete, eventos de kernel e eventos de hardware. O tema da sessão QCon de hoje é observabilidade de negócios . Para este tópico, focamos primeiro nos primeiros quatro tipos de dados.
No entanto, os dados que você vê na imagem acima são apenas dados brutos. Requer identificação, extração, conversão, associação, agregação e outras operações para obter dados de observabilidade de negócios que podemos usar diariamente. A imagem abaixo é um resumo de parte do processamento de dados brutos do eBPF no DeepFlow. Você pode ver que podemos extrair os indicadores dourados de solicitação/erro/atraso da API com base em eventos de soquete. , e correlacionando todas as chamadas Cadeias de chamadas de rastreamento distribuídas podem ser formadas e, ao agregar essas cadeias de chamadas, um mapa de API mais refinado pode ser construído. Entre eles, o rastreamento distribuído de intrusão zero baseado em eBPF é o recurso original do DeepFlow. O rastreamento distribuído pode ser alcançado sem instrumentação ou injeção de TraceID. Os parceiros interessados podem fazer o download e experimentá-lo em nosso repositório GitHub . Além disso, os logs de início e parada do processo podem ser extraídos de eventos de processo, o log de acesso a arquivos pode ser extraído de eventos de arquivo e CPU, memória, GPU, memória de vídeo, eventos de bloqueio podem ser extraídos de eventos de desempenho e gráficos de chama de análise de desempenho podem ser retirou.
Além de obter o sinal de observação, uma tarefa importante que precisamos realizar é injetar rótulos unificados nos dados. Por exemplo, injetar tags de recursos e de negócios obtidas de K8s, Cloud e CMDB nos ajuda a associar horizontalmente dados de pilha completa, injetando tags em nível de sistema, como processos, threads e corrotinas, bem como tags em nível de rede, como sub-rede, IP e TCP SEQ nos ajudam a associar verticalmente cadeias de chamadas distribuídas.
Tomando o rastreamento distribuído como exemplo, vamos dar uma olhada no efeito do DeepFlow usando eBPF. A figura a seguir compara a diferença entre os resultados de rastreamento do APM e do eBPF: o uso do APM geralmente pode cobrir o processo Java, mas geralmente é difícil cobrir o gateway API, gateway de microsserviço, grade de serviço, DNS, Redis, MySQL, etc. aplicação, e é difícil cobrir outros não-O custo de cobertura de aplicação da linguagem Java também é relativamente alto. Usando o eBPF, baseado em intrusão zero e dados full-stack, toda a pilha de chamadas pode cobrir todos os processos de negócios e processos de infraestrutura, bem como transmissão de rede K8s, leitura e gravação de arquivos e outros eventos. Esse recurso é uma inovação de ponta. Publicamos esse trabalho em um artigo acadêmico de quase 20 páginas, que foi aceito pela ACM SIGCOMM, a principal conferência acadêmica da American Computer Society, no ano passado.
Voltando ao tópico de observabilidade de negócios da sessão de hoje , como os dados obtidos pelo eBPF do kernel são associados ao negócio? eBPF é uma tecnologia central e toda a discussão ecológica se concentra no sistema, desempenho, segurança, etc., enquanto os aplicativos se concentram na semântica de negócios e os desenvolvedores esperam obter informações de negócios e eficiência. Como fazer com que a observabilidade do eBPF rompa a barreira dimensional, do sistema ao negócio, deixe-me falar sobre a abordagem do DeepFlow. Tomando dados de soquete como exemplo, ao realizar a análise de protocolo nos dados obtidos pelo eBPF, geralmente analisamos apenas os campos de cabeçalho de protocolos padrão (como HTTP, MySQL, etc.). DeepFlow agora oferece suporte a mais de 20 análises de protocolo, abrangendo categorias HTTP1/2/S, RPC, MQ, DB e Rede. Os recursos de análise integrados do DeepFlow podem extrair campos padrão dos cabeçalhos desses protocolos e até mesmo cargas úteis, como URLs, instruções SQL, códigos de erro, etc. No entanto, informações como códigos de erro comercial, números de série de transações, IDs de pedidos e números de chassis de carros localizados na carga útil HTTP não podem ser extraídas de acordo com a lógica unificada. E às vezes a empresa usará Protobuf, Thrift e outros métodos para serialização, e precisa ser combinado com o esquema correspondente para analisar a carga útil.
Aqui usamos outra tecnologia WebAssembly para resolver este problema. Na verdade, se pensarmos que eBPF é uma tecnologia programável em kernel, então WebAssembly é uma tecnologia programável em modo de usuário. DeepFlow o usa para implementar um conjunto de mecanismos de plug-in seguros, de alto desempenho e de carregamento a quente. Os usuários podem usar Golang, Rust, C/C++ e outras linguagens para escrever plug-ins para obter análise sob demanda de cargas úteis de negócios. analisando assim o Log de Solicitação e o Log de Acesso ao Arquivo. Aguarde que os dados de observação do eBPF sejam aprimorados. Por exemplo, você pode escrever um programa Golang baseado no Plugin SDK fornecido pelo DeepFlow para analisar a carga útil do protobuf HTTP e extrair os campos de interesse comercial. Você pode até usar o código de erro, a mensagem de erro e outras informações no Payload para reescrever os campos correspondentes no log de solicitação HTTP original.
Finalmente, o título desta seção é "Construindo fontes de sinais de observabilidade de alta qualidade usando eBPF". Portanto, nossa visão é que o eBPF é uma infraestrutura e o primeiro passo em toda a construção da observabilidade. Com base na base sólida de capacidades de observabilidade de intrusão zero, podemos incorporar dados intrusivos tradicionais sob demanda e injetar rótulos unificados para construir uma plataforma de observabilidade mais poderosa. Os recursos do eBPF são como digitar uma seção no início de Star Wars Whos your daddypara abrir totalmente o mapa , enquanto os dados intrusivos tradicionais são como o lado comercial usando bolas científicas para conduzir a exploração de pontos fixos de áreas locais sob demanda;
02
Use LLM para construir agentes de observabilidade eficientes
O segundo ponto partilhado hoje é como utilizar as capacidades do LLM para construir inteligência observável com base em dados de alta qualidade. No passado, o maior problema do AIOps era a baixa qualidade dos dados (baixa cobertura, formato confuso). Quando você planeja começar a fazer AIOps, geralmente leva meio ano ou mais para promover a governança de dados. Agora, os dados de alta qualidade do eBPF significam que a base é sólida. Ao mesmo tempo, coincide com a era AGI, e o LLM demonstrou capacidades muito mais poderosas do que os pequenos modelos anteriores. Portanto, acreditamos que o eBPF + LLM é a infraestrutura para a realização de agentes de observabilidade . Deixe-me compartilhar algumas práticas do DeepFlow nesta área.
Neste estágio, o DeepFlow não cria agentes para todos os problemas. Esperamos explorar os problemas em todo o processo de desenvolvimento, teste, operação e manutenção e selecionar dois ou três que sejam mais difíceis de resolver, combinando observabilidade + agentes. Para entender os pontos problemáticos, primeiro concentre-se nesses dois ou três pontos. O primeiro cenário que encontramos são as ordens de serviço , especificamente o processo caótico nos estágios iniciais de criação de um grupo de ordens de serviço, o segundo cenário são as mudanças , especificamente a rápida demarcação da degradação do desempenho após as mudanças, o terceiro cenário são as vulnerabilidades ; esse cenário, e hoje compartilharemos algumas de nossas reflexões preliminares.
Ineficiência das ordens de serviço : Vamos primeiro supor que um alarme na sua empresa irá desencadear a criação de um chat em grupo, como um grupo Feishu. Vejamos um cenário típico que vemos no escritório de um cliente: depois que a primeira pessoa é incluída no grupo de ordens de serviço, ela pode examinar os dados de rastreamento da cadeia de chamadas, fazer algumas análises e descobrir que o problema não é dele; segunda pessoa no grupo de ordem de serviço entrou no grupo, essa pessoa olhou alguns dados do indicador, e depois de fazer algumas análises, descobriu que não era problema dele, então trouxe uma terceira pessoa para o grupo, essa pessoa olhou para o; dados do evento, e depois de fazer algumas análises, ele ainda descobriu que não era problema dele; então puxou a quarta pessoa, a quinta pessoa,...; Wang, foi puxado para o grupo, e foi feita uma análise e resumo mais aprofundado e detalhado, de que o caixão poderia ser finalizado e o trabalho encaminhar o pedido para o responsável correto, Xiao Li . Muitas vezes descobrimos que antes que a ordem de serviço seja correspondida a Xiao Li, o processo é muito confuso e ineficiente e pode levar mais de uma hora. Mesmo que as pessoas que foram contratadas no início não participem de todo o processo, a existência deste grupo de ordens de serviço interromperá seu trabalho normal de tempos em tempos, o que tem um impacto significativo na eficiência de todos na ordem de serviço. grupo.
Como um agente de observabilidade pode resolver esse problema? Quando uma ordem de serviço é criada, o robô controlado pelo AI Agent será automaticamente colocado no grupo de ordens de serviço. O agente AI primeiro chama a API DeepFlow para visualizar rastreamento, indicadores, eventos, logs e outros tipos de dados e usa uma série de algoritmos estatísticos para resumir os recursos dos dados (reduzindo efetivamente o número de tokens) e, em seguida, usa essas informações de recursos como prompts para chamar o LLM (atualmente, o GPT4 é usado principalmente para análise. Depois de analisar um tipo de dados, o Agente de IA usa os recursos de chamada de função ou modo JSON do LLM para decidir que outro tipo ou tipos de dados precisam ser analisados. Por fim, o Agente de IA solicita ao LLM que faça um resumo com base em todos os resultados da análise.
Nesse processo, o eBPF do DeepFlow fornece dados de observabilidade completos e full-stack, e o AutoTagging injeta rótulos unificados e semanticamente ricos em todos os dados . Com base nos resultados da análise, o Agente de IA pode usar rótulos como label.owner para puxar com precisão a pessoa responsável correspondente para o grupo de ordens de serviço. Nesta fase, embora a precisão da delimitação da ordem de serviço do Agente AI não possa atingir 100%, ele conseguiu comprimir com sucesso o período inicial muito caótico do grupo de ordens de serviço de mais de uma hora para um minuto na maioria dos casos, e tem melhorou significativamente a eficiência do grupo de ordens de serviço. O número de pessoas no grupo de ordens de serviço é reduzido, melhorando significativamente a eficiência do trabalho de toda a equipe .
Ineficiência das mudanças : Descobrimos que em um ambiente nativo da nuvem, os motivos para a degradação do desempenho após o lançamento do serviço podem ser multifacetados e, devido à complexidade da cadeia de chamadas e da pilha de códigos de software, às vezes é difícil para os parceiros responsáveis pelo On Call localizar A causa raiz é que também é muito possível julgar mal facilmente devido à ignorância do conteúdo além do escopo do próprio conhecimento. Após a ocorrência desse tipo de problema, a única maneira é expandir temporariamente a capacidade ou reverter para restaurar o negócio e aguardar que o problema seja corrigido antes de lançar a versão novamente. No entanto, o ambiente de teste pode não ser capaz de reproduzir os problemas no ambiente de produção, por isso temos que introduzir uma série de mecanismos de reprodução de tráfego para auxiliar na análise da causa raiz do problema. Nesse cenário, esperamos que o AI Agent possa ajudar os desenvolvedores a identificar rapidamente as causas principais da degradação do desempenho e colocar a versão online novamente muito mais cedo.
Para cenários com cadeias de chamadas complexas, já temos uma boa solução no exemplo do agente de ordem de serviço. Para cenários com pilhas de chamadas de funções complexas, esta é a especialidade do eBPF. Ele pode obter funções de negócios, funções de biblioteca, funções de tempo de execução e pilhas de chamadas de funções do kernel quando o processo está em execução sem qualquer intrusão. Devido à segurança e à baixa sobrecarga do eBPF, a criação de perfil pode ser ativada continuamente. Portanto, os dados de criação de perfil geralmente são acumulados por um período de tempo antes que o desempenho se deteriore a um nível intolerável após a alteração. dados para concluir rapidamente a delimitação da causa raiz.
Os dados do perfil eBPF cobrem uma ampla gama de pilhas de tecnologia e é difícil para qualquer desenvolvedor de negócios compreender todas as informações. Este cenário é o que o AI Agent faz bem. Conforme mostrado na figura abaixo, o LLM geralmente é capaz de compreender o conhecimento das funções do kernel, funções de tempo de execução e funções básicas da biblioteca, de modo que os resultados da análise dessas funções podem ser fornecidos diretamente. Mesmo que haja coisas em que o LLM não seja bom, uma vez que os projetos de software onde tais funções estão localizadas não são atualizados com frequência e pertencem ao conhecimento comum, podemos considerar o aprimoramento das partes que o LLM não domina por meio de ajustes finos. Vamos dar uma olhada em algumas funções de biblioteca de aplicativos comumente usadas, como solicitações do Python, etc. Essas bibliotecas são caracterizadas por um grande número, iteração rápida e documentação de interface rica. Podemos considerar a vetorização da documentação de tais funções e o uso do mecanismo RAG para. aprimorar a análise LLM. Mais acima estão os códigos de negócios internos da empresa. Eles não são de conhecimento comum, são maiores em quantidade e mudam mais rapidamente. Portanto, optamos por otimizar palavras de prompt para alimentá-los diretamente no LLM. O rótulo commit_id no recurso AutoTagging do K8s pode facilmente permitir que o agente de IA localize o registro de modificação de código recente por meio de commit_id e notifique o LLM. Pode-se observar que, por meio do uso combinado de tecnologia LLM, ajuste fino, RAG e Prompt Engineering, todos os campos profissionais envolvidos nos dados de perfil full-stack eBPF podem ser completamente cobertos, ajudando os desenvolvedores a identificar rapidamente as causas raízes .
Ineficiência das vulnerabilidades : Um relatório afirmou: "A retificação de vulnerabilidades pode ser 76% inútil e apenas 3% das vulnerabilidades devem receber atenção prioritária." DeepFlow ainda está explorando como usar o AI Agent para melhorar a eficiência neste link. O certo é que o eBPF é uma excelente tecnologia de coleta de dados para Cloud Workload Security. Isovalente resume os quatro sinais dourados de observação da segurança: Execução de Processo, Soquete de Rede, Acesso a Arquivos e Identidade de Rede da Camada 7 . Atualmente, o DeepFlow tem cobertura parcial desses quatro sinais e continuará a aprimorá-los no futuro. Acredito que com a conclusão desses dados, combinados com o LLM, seremos capazes de criar um agente de IA de cena de segurança muito atraente.
No final desta parte, vamos falar sobre como melhorar continuamente o AI Agent. Tomando o cenário da ordem de serviço como exemplo, usamos a engenharia do caos no ambiente de teste para construir uma grande quantidade de dados anormais. Como conhecemos as causas raiz corretas dessas anomalias, elas podem ser usadas para avaliar o AI Agenl. e melhorá-lo continuamente. No ambiente de produção (nota: o lado direito do PPT deve ser o ambiente de produção), adicionamos um mecanismo para os usuários pontuarem, e os desenvolvedores do Agente farão melhorias com base nas pontuações.
03
Exemplos práticos de agentes de observabilidade para usuários do DeepFlow
Então, como é o agente AI do DeepFlow agora? Vamos dar uma rápida introdução a esta parte. Atualmente, na página DeepFlow Enterprise Edition, o Agente AI pode ser convocado a partir do mapa de topologia, rastreamento da cadeia de chamadas e páginas de análise contínua. Ao mesmo tempo, a API do Agente também pode ser chamada pelo Feishu ChatBot para implementar a função. de um especialista em ordens de serviço. Depois que o Agente de IA fornecer a primeira rodada de resumo, ele também fornecerá cerca de três ou quatro perguntas que você pode continuar a fazer. Você pode clicar diretamente nessas perguntas para continuar a conversa. Claro, os usuários também podem inserir diretamente suas próprias perguntas para o diálogo.
Além disso, o recurso AI Agent também foi lançado hoje no DeepFlow Community Edition e atualmente é capaz de analisar os dados atuais do Painel Grafana. Atualmente oferecemos suporte a dois painéis, Topo e Tracing, e estamos adaptados a quatro modelos grandes: GPT, Tongyi Qianwen, Wenxinyiyan e ChatGLM.
04
Reflexões sobre as direções da evolução futura
Por fim, deixe-me compartilhar a direção da evolução futura do DeepFlow AI Agent.
Agora, o eBPF pode cobrir totalmente os aplicativos em nuvem. Em seguida, ampliaremos seus recursos para o lado final, incluindo direção autônoma e controle de domínio espacial inteligente em carros inteligentes, bem como alguns cenários de smartphones onde as permissões são permitidas.
Por outro lado, também descobrimos que o RAG tem muito espaço para otimização. Aqui está uma revisão do RAG: Retrieval-Augmented Generation for Large Language Models: A Survey .
05
O que é Deep Flow
DeepFlow é um produto de observabilidade desenvolvido pela Yunshan Network , com o objetivo de fornecer observabilidade profunda para infraestruturas de nuvem complexas e aplicativos nativos de nuvem. Com base no eBPF, o DeepFlow realiza coleta de sinais de observação com intrusão zero ( Zero Code), como indicadores de desempenho de aplicativos, rastreamento distribuído e análise contínua de desempenho, e combina com a tecnologia de etiqueta inteligente ( SmartEncoding) para obter correlação full-stack ( Full Stack) e acesso eficiente de todos sinais de observação. Usando o DeepFlow, os aplicativos nativos da nuvem podem ter observabilidade profunda automaticamente, eliminando assim a pesada carga de instrumentação contínua sobre os desenvolvedores e fornecendo às equipes de DevOps/SRE recursos de monitoramento e diagnóstico do código à infraestrutura.
Endereço GitHub: https://github.com/deepflowio/deepflow
Visite o DeepFlow Demo para experimentar zero instrumentação, cobertura completa e observabilidade totalmente relevante.
Visualização do Evento | Observabilidade Encontro de Desenvolvedores de Código Aberto "Observabilidade Inteligente: Evolução Observável Impulsionada por Grandes Modelos"