"Instrumentação em escala, tendo seu bolo de desempenho e comendo-o também". Meu nome é Brian Martin. Meus pronomes são ele/eles. Sou cofundador da IOP Systems, que significa aproximadamente Otimização e Desempenho de Infraestrutura. Na minha empresa, éramos a equipe de desempenho de infraestrutura do Twitter. Então nos separamos e somos nossa própria empresa. Eu trabalho em alguns projetos de código aberto. Um deles é chamado Rezolus, que é um agente de telemetria de desempenho de sistemas.
Somos capazes de instrumentar caminhos de syscall. Conseguimos obter algumas métricas granulares muito interessantes, como a pilha TCP e coisas assim. Oferece exposição do Prometheus, porque essa é a forma comum de consumir telemetria. É código aberto. Está disponível em rezolus.com, que apenas redireciona para o GitHub. Confira se você precisa de telemetria de sistemas eBPF.
Também vou falar um pouco sobre uma biblioteca de métricas em que trabalho, chamada metriken. É uma biblioteca de métricas de baixa sobrecarga. É usada em todos os projetos em que trabalho. É realmente otimizada para caminhos críticos de desempenho. Foi construída por necessidade para obter métricas no RPC-Perf e no Pelikan, e depois a aproveitamos também no Rezolus. Ela usa um truque em tempo de link para descobrir as métricas, então posso instrumentar bibliotecas e fazer com que essas métricas sejam reunidas no aplicativo. É apenas uma coisa legal sobre como funciona. Já que mencionei eBPF, o que é isso? É o Extended Berkeley Packet Filter, mas agora é usado para muitas outras coisas onde você pode executar programas em sandbox no kernel Linux. Isso nos permite observar o comportamento do kernel que não poderíamos ver de outra forma, sem fazer nenhuma alteração de código no kernel. Somos capazes de nos anexar a funções do kernel, tracepoints, até mesmo funções de espaço do usuário, e podemos compartilhar dados de volta via mapas BPF para o espaço do usuário, então é uma técnica muito legal para obter detalhes do espaço do kernel.
Por que a instrumentação é importante?
Vamos começar nossa conversa sobre instrumentação. Por que a instrumentação é importante? Você precisa de visibilidade em seus sistemas para entender o que está acontecendo. Sem instrumentação suficiente, você perderá problemas de desempenho, como se simplesmente não soubesse sobre eles. Você não será capaz de diagnosticar incidentes de produção. Acho que a pior página para se obter não é o sistema estar inoperante, mas o sistema estar lento. A instrumentação ajuda a responder à questão do porquê. Sem instrumentação suficiente, você não pode melhorar o desempenho porque não pode melhorar o que não pode medir. A instrumentação não é opcional. Isso é absolutamente necessário para executar serviços de produção. Acho que é absolutamente necessário ao projetar uma biblioteca. É muito importante. Não é sem problemas. O problema é sempre o custo. Sempre há alguma sobrecarga quando você adiciona instrumentação. Quanto mais você instrumenta, mais esses custos são importantes. Se for instrumentação em um caminho quente, será muito crítico.
Basicamente, o número de vezes que você liga é um multiplicador do custo. Se for muito caro e raramente ligar, talvez não haja problema. À medida que você começa a ligar mais, esse custo importa muito mais. Vamos falar sobre alguns custos reais. Esta é a mesma operação com implementações diferentes. Entraremos em detalhes sobre isso mais tarde. Este é um pequeno teaser para que você entenda o quão importante isso é. Os incrementos do contador podem variar entre 5 nanossegundos para um atômico não contestado até mais de 1 microssegundo. Isso é uma diferença de custo de 200 vezes. Os histogramas em algumas das implementações que testei são executados entre 7 nanossegundos não disputados até microssegundos de dois dígitos totalmente disputados, ou seja, uma diferença de 1400x. Eu acho que isso realmente importa tanto em termos de implementação quanto de tempo de execução e se é contestado ou não. Iremos mergulhar nisso um pouco mais tarde.
O que esperamos aprender hoje é que existe esse espectro de custos de instrumentação. Veremos o que algumas bibliotecas reais fazem. Técnicas para o que estou começando a chamar de instrumentação destemida. Em Rust temos uma simultaneidade destemida. Quero poder instrumentar as coisas sem medo do custo de adicionar instrumentação.
Uma introdução rápida sobre os tipos de métricas, para que estejamos todos na mesma página. A primeira coisa que temos é um contador, que é um valor monotonicamente não decrescente. Ou sobe ou permanece igual. Nunca cai. É como o número de solicitações que você atendeu. Os contadores podem ser zerados, e esse é o caso em que você verá descontinuidade no valor. Caso contrário, você nunca tirará. Você fez o trabalho. Você está incrementando. Também existem medidores. Esses são valores pontuais. Realmente não há regras sobre isso. É apenas o nível atual de algo, como a profundidade da fila ou o nível da água, se você estiver olhando para um rio, ou a te
As informações são do site InfoQ
