O Workers Analytics Engine é uma nova ferramenta, anunciada no início deste ano, que permite que desenvolvedores e equipes de produtos criem análises de dados de séries temporais sobre qualquer coisa, com alta dimensionalidade, alta cardinalidade e escala, sem esforço. Criamos o Analytics Engine para que as equipes obtenham informações sobre o código em execução no Workers, forneçam análises aos clientes finais ou até mesmo criem faturamento baseado no uso.
Neste post do blog, explicamos como usamos o Analytics Engine para criar o Analytics Engine. Instrumentamos nossa própria API SQL do Analytics Engine usando o próprio Analytics Engine e usamos esses dados para encontrar bugs e priorizar novos recursos do produto. Esperamos que isso sirva de inspiração para outras equipes que procuram maneiras de instrumentar seus próprios produtos e obter feedback.
Por que precisamos do Analytics Engine?
O Analytics Engine permite gerar eventos (ou “pontos de dados”) a partir do Workers com apenas algumas linhas de código. Usando a API SQL ou GraphQL, você pode consultar esses eventos e criar informações úteis sobre a pilha de negócios ou tecnologia. Para saber mais sobre como começar a usar o Analytics Engine, confira nossa documentação para desenvolvedores.
Desde que lançamos o beta aberto do Analytics Engine, em setembro, adicionamos novos recursos rapidamente com base no feedback dos desenvolvedores. No entanto, tivemos duas grandes lacunas em nossa visibilidade do produto.
Primeira, nossa equipe de engenharia precisa responder a perguntas clássicas de observabilidade, como: quantas solicitações estamos recebendo, quantas dessas solicitações resultam em erros, qual é a natureza desses erros etc. Eles precisam ser capazes de visualizar dados agregados (como taxa de erro média ou tempo de resposta p99) e detalhar eventos individuais.
Segunda, como este é um produto recém-lançado, estamos buscando informações sobre o produto. Ao instrumentar a API SQL, podemos entender as consultas que nossos clientes escrevem e os erros que eles veem, o que nos ajuda a priorizar os recursos que faltam.
Percebemos que o Analytics Engine seria uma ferramenta incrível para responder às nossas perguntas de observabilidade técnica e também para coletar informações sobre o produto. Isso ocorre porque podemos registrar um evento para cada consulta em nossa API SQL e, em seguida, consultar problemas de desempenho agregados, bem como erros individuais e consultas executadas por nossos clientes.
Na próxima seção, mostramos como usamos o Analytics Engine para monitorar essa API.
Adicionar instrumentação à nossa API SQL
A API SQL do Analytics Engine permite consultar dados de eventos da mesma forma que faria em um banco de dados comum. Por décadas, o SQL tem sido a linguagem mais comum para consultar dados. Queríamos fornecer uma interface que permitisse que você começasse imediatamente a fazer perguntas sobre seus dados sem precisar aprender uma nova linguagem de consulta.
Nossa API SQL analisa as consultas SQL do usuário, as transforma e valida e, em seguida, as executa nos servidores de banco de dados de back-end. Em seguida, gravamos informações sobre a consulta novamente no Analytics Engine para que possamos executar nossas próprias análises.
Escrever dados no Analytics Engine a partir do Cloudflare Workers é muito simples e está explicado em nossa documentação. Instrumentamos nossa API SQL da mesma forma que nossos usuários e este trecho de código mostra os dados que gravamos no Analytics Engine:
Com esses dados agora armazenados no Analytics Engine, podemos obter informações sobre todos os campos que estamos relatando.
Consultar insights
Ter nossas análises em um banco de dados SQL dá a você a liberdade de escrever qualquer consulta que desejar. Comparado ao uso de algo como métricas, que geralmente são predefinidas e com finalidade específica, você pode definir qualquer conjunto de dados personalizado que quiser e interrogar seus dados para fazer novas perguntas com facilidade.
Precisamos oferecer suporte a conjuntos de dados que compreendem trilhões de pontos de dados. Para conseguir isso, implementamos um método de amostragem chamado Adaptive Bit Rate (ABR). Com o ABR, se você tiver grandes quantidades de dados, suas consultas podem retornar eventos amostrados para responder em tempo razoável. Se você tiver quantidades de dados mais comuns, o Analytics Engine consultará todos os seus dados. Isso permite que você execute qualquer consulta que desejar e ainda obtenha respostas em um curto espaço de tempo. No momento, você deve levar em consideração a amostragem na forma como faz suas consultas, mas estamos investigando para torná-la automática.
Qualquer ferramenta de visualização de dados pode ser usada para visualizar suas análises. Na Cloudflare, usamos muito o Grafana (e você também pode). Ele é particularmente útil para casos de uso de observabilidade.
Observando os tempos de resposta da consulta
Uma consulta à qual prestamos atenção nos fornece informações sobre o desempenho de nossos clusters de banco de dados de back-end:
Como você pode ver, o percentil 99% (correspondente ao 1% das consultas mais complexas a serem executadas) às vezes atinge picos de até 300 ms. Mas, em média, nosso back-end responde às consultas em 100 ms.
Essa visualização é gerada a partir de uma consulta SQL:
Insights de clientes a partir de dados de alta cardinalidade
Outro uso do Analytics Engine é extrair insights do comportamento dos clientes. Nossa API SQL é particularmente adequada para isso, pois você pode aproveitar ao máximo o poder do SQL. Graças à nossa tecnologia ABR, até consultas extensas podem ser realizadas em grandes conjuntos de dados.
Usamos essa capacidade para ajudar a priorizar melhorias no Analytics Engine. Nossa API SQL oferece suporte a um dialeto bastante padrão de SQL, mas ainda não possui recursos completos. Se um usuário tentar fazer algo sem compatibilidade em uma consulta SQL, ele receberá uma mensagem de erro estruturada. Essas mensagens de erro são relatadas no Analytics Engine. Podemos agregar os tipos de erros que nossos clientes encontram, o que ajuda a informar quais recursos priorizar em seguida.
A API SQL retorna erros no formato type of error: more details, e assim podemos pegar a primeira parte, antes dos dois pontos, para nos informar o tipo de erro. Agrupamos por ela e obtemos uma contagem de quantas vezes esse erro aconteceu e quantos usuários ele afetou:
Para realizar a consulta acima usando um sistema de métricas comum, precisaríamos representar cada tipo de erro com uma métrica diferente. Relatar tantas métricas de cada microsserviço cria desafios de escalabilidade. Esse problema não acontece com o Analytics Engine, porque ele foi projetado para lidar com dados de alta cardinalidade.
Outra grande vantagem de um armazenamento de alta cardinalidade, como o Analytics Engine, é que você pode se aprofundar em detalhes. Se houver um grande pico de erros de SQL, podemos querer descobrir quais clientes estão tendo problemas para ajudá-los ou identificar qual função eles desejam usar. Isso é fácil de fazer com outra consulta SQL:
Dentro da Cloudflare, historicamente confiamos em consultar nossos servidores de banco de dados de back-end para esse tipo de informação. A API SQL do Analytics Engine agora nos permite abrir nossa tecnologia para nossos clientes, para que eles possam obter facilmente informações sobre seus serviços em qualquer escala.
Conclusão e o que vem a seguir
Os insights que reunimos sobre o uso da API SQL são uma entrada super útil para nossas decisões de priorização de produtos. Já adicionamos compatibilidade para as funções substring e position que foram usadas nas visualizações acima.
Observando os principais erros de SQL, vemos vários erros relacionados à seleção de colunas. Esses erros vêm principalmente de alguns problemas de usabilidade relacionados ao plug-in Grafana. Adicionar compatibilidade para a função DESCRIBE deve mitigar isso porque, sem isso, o plug-in Grafana não entende a estrutura da tabela. Isso, assim como outras melhorias em nosso plug-in Grafana, está em nosso roteiro.
Também podemos ver que os usuários estão tentando consultar intervalos de tempo para dados mais antigos, que não existem mais. Isso sugere que nossos clientes gostariam de estender a retenção de dados. Recentemente, estendemos nossa retenção de 31 para 92 dias e ficaremos observando para ver se devemos oferecer mais extensão.
Vimos muitos erros relacionados a falhas comuns ou mal-entendidos da sintaxe SQL adequada. Isso indica que poderíamos fornecer melhores exemplos ou explicações de erros em nossa documentação para ajudar os usuários a solucionar suas dúvidas.
Fique atento à nossa documentação para desenvolvedores para se manter informado conforme continuamos a iterar e adicionar mais recursos.
Você pode começar a usar o Workers Analytics Engine agora. O Analytics Engine está em versão beta aberta com retenção gratuita de 90 dias. Comece a usá-lo hoje ou junte-se à nossa comunidade no Discord para conversar com a equipe.