⚕️ 🕦 🧛 Log e rastreamento de consultas são práticas recomendadas. Relatório Yandex 📩 👩🏽‍💼 🌅

O Yandex.Market possui uma grande arquitetura de microsserviço. A solicitação do navegador da página principal do Market gera dezenas de solicitações incorporadas em diferentes serviços (back-end) desenvolvidos por pessoas diferentes. Nesse sistema, pode ser difícil entender por que motivo a solicitação caiu ou demorou muito tempo para processar.

Anatoly Ostrovsky megatóliaexplica como sua equipe resolveu esse problema e compartilha práticas específicas para o mercado, mas geralmente relevantes para qualquer ótimo serviço. Seu relatório é baseado em sua própria experiência de implantar um novo mercado em um tempo bastante curto. Por vários anos, Tolya liderou a equipe de desenvolvimento de interfaces no mercado e agora mudou-se para a direção de veículos não tripulados.

- Todos os nossos mercados são construídos de acordo com princípios gerais. Este é um grande sistema único. Mas se falamos sobre o frontend, do ponto de vista do usuário, os aplicativos são completamente diferentes.

Ao mesmo tempo, nossos frontends vão para muitos backends. Às vezes, esses back-end são semelhantes entre si (instâncias diferentes do mesmo aplicativo). E, às vezes, eles são exclusivos para o serviço (cobrança especial). A estrutura desse sistema pode ser considerada uma arquitetura clássica de microsserviço.

Sempre há um problema em um serviço grande - é difícil entender o que exatamente está acontecendo nele. Ou, por exemplo, o que acontece no momento em que ocorre um erro de pagamento com o usuário. Suponha que aconteceu ontem na casa dele e hoje precisamos entender o que aconteceu.

O back-end 2 pode "queimar" para um produto específico, ou em um horário específico, ou para usuários específicos. Precisamos ser capazes de responder a qualquer situação.

Temos muitos back-ends e, como eu disse, eles podem andar por conta própria. Se isso for apresentado na forma de um gráfico, será bastante confuso. Na vida real, pode haver centenas de microsserviços. Imagine quantas conexões haverá entre eles.

Existem muitas etapas para abordar esse tópico. Vou falar brevemente sobre cada um deles.

Antes de tudo, concorde com colegas do back-end em um sistema comum de marcação de solicitações - é mais fácil encontrá-los mais tarde. Em seguida, você precisa poder reproduzir rapidamente o problema. Suponha que ocorreu um erro de pagamento - tente entender rapidamente como isso aconteceu e em qual back-end. Armazene logs não apenas em arquivos, mas também no banco de dados para que as agregações possam ser feitas. E, é claro, uma parte importante do processo são gráficos e monitoramento. Em seguida, em ordem.

Sistema de identificação de solicitação unificada

Essa é uma das ferramentas mais fáceis de entender o que está acontecendo com o serviço. Concorde com os colegas que, por exemplo, seu front-end gera algum tipo de solicitação de ID (a variável requestId na figura) e, em seguida, lança-o em todos os pontos de extremidade dos back-ends. E o back-end em si não reinventa nada. Ele pega o requestId que chegou e o encaminha mais adiante nos pedidos aos seus back-ends. Ao mesmo tempo, ele pode especificar seu prefixo, para que, entre o requestId idêntico, seja possível encontrar esse back-end específico.

Portanto, quando você devora seus logs, certificando-se de que digam, por exemplo, que o back-end é quinhentos, pode haver duas opções. Você fornecerá esse ID de solicitação aos seus colegas e eles o examinarão nos registros deles ou você verá por si mesmo.

Todos os nossos logs são marcados com esse ID, não apenas para entender o que aconteceu e em que momento, mas também para manter o contexto dessa solicitação. É assíncrono; posteriormente, pode adicionar algo ao log. E se você morder a requestId, nada de bom resultará disso.

ondulação

Para reproduzir o problema, usamos o utilitário cURL. Este é um utilitário de console que faz solicitações de rede - http e https. O cURL suporta muitos mais protocolos diferentes, mas ao fazer o desenvolvimento da Web, é mais fácil assumir que essa é uma ferramenta para trabalhar com solicitações de http (s).

Para se familiarizar com a equipe do cURL, você pode acessar qualquer site, acessar a Rede e copiar qualquer solicitação no formato cURL. O resultado é uma linha tão grande:

se você tentar descobrir, não há com o que se preocupar. Vamos tentar desmontar.

Aqui está uma solicitação para market.yandex.ru.

Um agente do usuário foi adicionado aqui, o que já ocupa muito espaço.

De fato, o resto são cookies. Existem muitos deles no código Yandex. Na forma serializada, eles têm uma aparência muito formidável. De fato, não há mais nada além deles.

Então, para que é útil o cURL? Se você o copiou e executou, viu a mesma página market.yandex.ru que eu fiz - apenas o computador em que estava sendo executado seria diferente. Certamente, alguns efeitos colaterais podem causar diferenças nos endereços IP, mas em geral eles seriam os mesmos pedidos. Nós reproduziríamos o mesmo cenário.

Para não inventar essas consultas cURL a cada vez, você pode usar o npm-package format-curl.

Ele recebe todos os parâmetros de solicitação que a função normalmente aceita - ou seja, neste caso, apenas cabeçalhos e URL. Mas ele também sabe como consultar, corpo, etc. E a saída é apenas uma string com uma solicitação cURL.

Portanto, todos os nossos logs no ambiente de desenvolvimento também contêm solicitações cURL.

Até registramos solicitações cURL de back-end diretamente no navegador para ver imediatamente como acessamos nossos back-end sem olhar para o console do navegador.

Observe que as solicitações cURL envolvem a transferência de cookies de sessão - isso é ruim. Se você me recusou a solicitação cURL em market.yandex.ru, eu poderia entrar no Market e em qualquer outro serviço Yandex no seu login. Portanto, não armazenamos essas solicitações em nenhum lugar e as registramos apenas em bancos de teste para nós mesmos - esses dados não podem ser vazados.

Clickhouse

A seguir, falarei sobre logs estruturados. Aqui, lembrarei do banco de dados ClickHouse específico, mas você pode escolher qualquer. O ClickHouse é um DBMS colunar, é mais conveniente selecionar entre uma enorme quantidade de dados e receber grandes quantidades de dados. É bom que você salve uma grande parte do log e depois, por exemplo, faça algum tipo de agregação de um bilhão de registros.

Nesse caso, o exemplo de seleção ClickHouse é SQL simples. Aqui, mostramos o número de solicitações de códigos de status para hoje.

Como resultado, teremos 180 mil duzentos e setecentos e os demais códigos de status, por exemplo, não são interessantes para nós. Mas como podemos usar isso de maneira interessante?

Podemos dizer que a proporção de duzentos e a proporção do número total de respostas é o Indicador de Nível de Serviço, que responde à pergunta de quão bem nosso aplicativo funciona em termos de códigos de status. Embora simples, ele já está falando sobre algo.

Com base em nosso indicador, podemos criar o primeiro SLI, ou seja, por exemplo, que 99% de nossas solicitações devem ser aceitáveis. E aqui podemos comparar que realizamos nosso SLI. Se eles não tivessem concluído, poderíamos ter tentado fazer alguns dos últimos pedidos que seriam quinhentos ou simplesmente coisas críticas.

Por exemplo, erros de pagamento são críticos para nós, mas, neste caso, eles retornarão zero - é uma sorte :)

Como você pode fazer seus logs de uma forma tão conveniente e que eles podem ser obtidos via SQL?

Este é um tópico para outro grande relatório e tudo depende da sua infraestrutura. Mas parece que existem duas maneiras. Primeiro: envie os metadados diretamente para o tempo de execução, diretamente no banco de dados. Fazemos isso de maneira diferente, da segunda maneira: seguimos o arquivo de log e enviamos pedaços no banco de dados ou em um local intermediário.

Isso funciona para nós em várias camadas - enviamos logs de uma instância específica para um servidor de armazenamento remoto desses logs.

Solicitar rastreamento

Não há conceito de "rastreamento de consulta". Este termo foi cunhado pelo Google.

Se você pesquisar na Internet por "rastreamento de consulta", verá o comando traceroute. Talvez isso seja semelhante ao rastreamento de consultas.

Existe até um programa de console, e aqui eu o executei para o site bringly.ru (um serviço que desenvolvemos na primavera passada). Ajuda a entender que tipo de máquinas e servidores a solicitação passa antes de chegar ao balanceador, que responderá com o layout ou com outra coisa.

Aqui está o nosso balanceador. Por rastreamento de consulta, não queremos dizer isso, mas tudo o que acontece dentro do nosso balanceador - como a solicitação permanece mais dentro do aplicativo node.js.

Vemos isso na forma de uma linha do tempo, onde o tempo horizontal é exibido e a sequência vertical de solicitações. Nesse caso, temos uma solicitação para o cartão do produto, onde é possível ver que essa é uma solicitação para o back-end de nossa autorização. Após sua decisão, três longas filas foram - este é um pedido ao nosso principal back-end para uma cesta, cartão de produto e produtos similares. Então, temos um rastro.

Aqui você vê o mesmo pedido de autorização e, em seguida, o back-end foi. Nesse caso, o back-end não se comporta de maneira ideal, porque possui muitas consultas consecutivas no banco de dados. Provavelmente, essa consulta pode ser otimizada.

E aqui está um exemplo de rastreamento, quando não acessamos nenhum back-end, mas imediatamente fornecemos o status 500. Como esse rastreamento é útil para nós? Não precisamos incomodar colegas. Temos o ID dessa solicitação, para que possamos procurar nos logs e descobrir o que está acontecendo.

Aqui está a situação oposta. Backend disse que algo estava errado e, ao mesmo tempo, escreveu na meta-informação o que exatamente aconteceu - algum tipo de rastreamento de pilha apareceu.

Como se tornar a mesma ferramenta?

A coisa mais importante aqui é o banco de dados. Se você tiver o "INSERT INTO" mais simples no banco de dados de algumas ações com o serviço, mais tarde poderá pelo menos usar o SQL para encontrar os eventos necessários. E, se necessário, você pode fazer uma interface para isso.

Gráficos

Este é um tópico muito interessante, não vou me aprofundar em detalhes hoje, é claro, :)

Vamos falar sobre o log. Temos muitos gráficos, olhamos para eles quando lançamos algo - e nos intervalos há tanto barulho.

Os gráficos ajudam a ver visualmente que algo está errado. E então você ainda precisa examinar os logs e entender o que há de errado com eles. Nesse caso, o aumento imediatamente após a liberação significa pelo menos que essa liberação precisa ser revertida imediatamente.

Monitoramento

Uma parte ainda mais importante e um maior grau de imersão neste tópico é o monitoramento. Ao monitorar, entendo, em primeiro lugar, o monitoramento automático de gráficos e, em segundo lugar, quaisquer regras automatizadas para monitorar algo.

Monitoramos a proporção de quinhentos em relação ao número total de respostas por minuto. Também monitoramos quatrocentos, a presença de uma carga no serviço, verificando o botão de verificação de integridade, que puxa o botão de ping de cada um dos back-ends, etc.

Além disso, temos painéis de monitoramento que incluímos nas telas próximas às estações de trabalho. Então, imediatamente vemos qual dos monitoramentos "cora". Por exemplo, aqui é um dos principais, onde o front-end e nosso back-end principal são visíveis. Aqui você pode ver que algum monitoramento acende no back-end. Isso significa que, naquele momento, a pessoa responsável por esse serviço receberá uma mensagem no Telegram, ou talvez até ligue para ele - isso depende das configurações de monitoramento.

Sumário

Um único requestId ajudará você a encontrar problemas com mais facilidade em um serviço que consiste em vários aplicativos. A cURL correta permitirá reproduzir com mais precisão os problemas e ver como você mesmo, por exemplo, envia dados para o back-end. Os logs estruturados permitem criar o SLI e são mais convenientes do que os logs de texto comuns. E não esqueça de seguir os gráficos e realizar o monitoramento.

Eu recomendo a leitura do livro Engenharia de confiabilidade do site do Google, se você estiver interessado em assuntos de infraestrutura.

Log e rastreamento de consultas são práticas recomendadas. Relatório Yandex