Você se lembra do momento em que aprendeu que os logs não são gratuitos? Eu com certeza sim. Foi logo após um marco importante que nossa equipe alcançou - acabamos de lançar um novo e brilhante serviço escalável que está prestes a substituir um serviço herdado extremamente ineficiente e com taxa de transferência extremamente alta. Acabamos de reduzir o tamanho da frota de aproximadamente 300 instâncias do EC2 para aproximadamente 30 pods em um cluster kubernetees de vários locatários. Alcançando melhor confiabilidade, menor latência de processamento e reduzindo custos em uma ordem de magnitude.

Foi então que, sem querer, fizemos nossa conta do provedor de log disparar. Estávamos registrando grandes volumes de dados em alta taxa de transferência. Quase apagamos toda a economia de custo operacional.

Foi então que aprendi o quão caros podem ser aqueles logs que uso diariamente e sem problemas, sem pensar muito.

Nesta postagem, abordarei as etapas que adotamos para reduzir o custo do registro gerado por nossos sistemas e as práticas gerais sobre registro eficaz.

Qualquer otimização começa com a medição

Não podemos otimizar o uso de log se não soubermos quanto usamos, o que estamos registrando e por quê.

Na época, estávamos usando um fornecedor terceirizado para logs - uma plataforma ELK gerenciada, se você puder.

Então, começamos medindo a quantidade de logs que estamos indexando e quem são os “principais ofensores” — ou seja, quais são os logs mais enviados.

As duas coisas legais que podem ajudá-lo aqui (ao usar o Kibana, mas provavelmente podem ser aplicadas em qualquer lugar) é medir o tamanho do log:

E a guia de modelo que mostra os padrões de log mais comuns:

Como esse era um sistema totalmente novo, nunca usamos logs gerados por esse sistema ainda - portanto, seu valor era bastante difícil de acessar - enquanto o custo era óbvio. Isso nos levou a pensar muito sobre o sistema como um todo.

Entenda o uso

Para que seus logs serão usados?

• Eles serão usados ​​apenas durante as interrupções para entender o que acontece na produção?
• Os logs são usados ​​para fins de auditoria para entender uma jornada de solicitação? Eles serão usados ​​para depurar casos de uso de negócios?
• Esses logs são valiosos após uma hora? Depois de um dia?
• O sistema atende solicitações de longa duração? Ou os pedidos são temporais?
• Os logs fazem parte de algum requisito regulamentar?
• Qual é o custo de uma interrupção?

Vamos a alguns exemplos:

Digamos que você tenha um sistema onde cada solicitação é crítica, cada solicitação falha afetará negativamente os negócios da empresa. O melhor exemplo para tal sistema é um site de comércio eletrônico - cada pedido que não foi feito é perda de receita! Provavelmente, desejaríamos registrar cada etapa da jornada dessa solicitação para saber o que aconteceu, o que falhou e talvez usar esses registros para responder a perguntas como "por que o pedido passa pelo fluxo X e não pelo fluxo Y".

Nesse caso de uso, os logs são muito valiosos e devem ser retidos por um período razoavelmente longo — provavelmente de 7 a 14 dias.

Uma boa regra geral para o período de retenção de log necessário — o tempo geral que leva para dar suporte às consultas e às solicitações.

No entanto, em nosso caso - as solicitações eram de um sistema de suporte, sem correlação próxima com a receita, cada solicitação é muito curta e temporal, e o custo da interrupção é bastante baixo.

Além disso - o sistema tinha um número muito baixo de fluxos de processamento, portanto, a probabilidade de um problema afetar apenas um subconjunto específico de solicitações é muito baixa - ou seja, no caso de um problema, provavelmente será um tipo de interrupção total ou nada .

Além disso — nenhuma solicitação — a auditoria de nível é necessária, ninguém jamais nos perguntará por que a solicitação X se comportou da maneira que se comportou.

Esta análise nos levou às seguintes conclusões:

• A única solicitação não tem sentido em nosso sistema
• Além de falhas de processamento, não conseguimos encontrar nenhum motivo para verificarmos os logs do sistema (temos seu comportamento e SLI cobertos pelo monitoramento de métricas)
• Os dados são tão temporais que não há chance de alguém se importar com solicitações algumas horas após seu processamento

Usando o tempo de retenção correto

Começamos com uma solução rápida - reduzimos a retenção de nossos logs para um período mínimo de 1 dia, o que nos permitiu reduzir o custo rapidamente, antes de resolver o problema subjacente raiz.

Mas há uma lição aqui também: os níveis de retenção padrão de 7 a 14 dias que a maioria das empresas usa são padrões silenciosos e aleatórios e podem ter entre 10 e 90% de impacto nos custos.

Pense por quanto tempo seus logs permanecem valiosos em seus casos de uso? Ajuste a retenção para o valor mínimo.

Estenda e reduza os níveis de retenção necessários dinamicamente à medida que suas necessidades mudam — o lançamento de grandes recursos é uma ótima causa para retenções mais longas, enquanto longas janelas de manutenção podem ser boas chances de reduzir a retenção.

Faz uma grande diferença se você tiver 5 TB de logs diários que armazena por um dia ou um mês.

Logs significativos e não usar logs como métricas

É bastante comum ver mensagens de log como “Serving request” . A menos que você registre o que é essa solicitação e haja um significado real e valioso por trás dessa solicitação - isso é uma métrica , isso pode ser substituído por um contador simples!

Esses logs são bastante sem sentido:

Portanto, não use log para métricas, use métricas para métricas , é mais barato e muito mais eficaz.

Quanto aos logs - registre dados significativos, se essa solicitação for valiosa, registre o que é essa solicitação, como encontrá-la, o que a torna significativa e seus dados! Algo na linha de:

Atendendo à conta Premium <nome da conta>, solicitação <id>, <algum contexto adicional sobre o fluxo e a solicitação>

Como construímos um serviço de alto throughput, excluímos ~centenas de GBs de "solicitações de serviço" e "concluímos o processo x" , reduzindo nosso custo de registro em aproximadamente 5 a 10%.

Além disso, isso limpou nossos logs de serviço desordenados e tornou a busca de problemas muito mais fácil.

Registro baseado em gravidade

Normalmente definimos o nível mínimo de log em produção para INFO , dessa forma excluímos ou as linhas de depuração que usamos para desenvolver o sistema, sem perder o contexto do que está acontecendo.

Decidimos ir mais longe — e colocar o nível de log em WARNING , e mais tarde em ERROR .

Aprendemos que não precisamos do contexto e só nos importamos com o log quando o sistema está falhando e travando.

Isso reduziu nosso uso de log em aproximadamente 90%, sem nenhuma perda real de usabilidade.

Adicionamos um sinalizador de configuração dinâmica que permitia níveis de log mais baixos sob demanda para qualquer caso.

Registro Dinâmico

À medida que começamos a reduzir os logs, ficou claro que executar manualmente as coisas nos ambientes de produção e preparação tornou-se um pouco mais difícil, pois nossos logs quase sempre estavam vazios.

Ficou claro que, embora raramente usemos logs, ainda precisamos de alguma indicação sobre o que acontece em nossos sistemas. precisamos de *alguns* logs.

Construímos um mecanismo que decide dinamicamente se deve registrar os logs de uma solicitação por propriedades da solicitação. Por exemplo:

• Para teste e exploração, habilitamos o log para qualquer ID de solicitação começando com test. Ou enviado de algumas de nossas contas de teste.
• Ativamos o log completo para solicitações de teste sintético por propriedades da solicitação testada, portanto, teremos algum grupo de controle constante.
• Para a integração do produto/cliente, habilitamos os logs durante os primeiros estágios da integração por prefixos de nome do cliente.

Isso manteve nossos custos baixos, permitindo uma melhor usabilidade do nosso sistema.

Amostragem de nível de rastreamento

Geralmente não sou fã de soluções de amostragem. Amostragem para aqueles que não estão familiarizados - está usando um recurso apenas em um subconjunto do tráfego ou casos de uso - por exemplo, habilitar logs para apenas 10% do tráfego ou apenas tráfego de espaço ou região de ip específico.

Em nosso caso, podemos facilmente reduzir custos registrando apenas um subconjunto de pods em nossa implantação ou registrando apenas uma pequena porcentagem de solicitações.

É um caso de uso bastante comum para reduzir custos operacionais. No entanto, em nosso caso, depois de todas as otimizações feitas, não vimos razão para isso, mas se você optar por fazê-lo, lembre-se de registrar todo o registro de solicitação e de amostrar cada linha de registro separadamente - você obtenha fluxos interrompidos e nenhum valor real dessa maneira.

Limitação de “tempestades de erros”, custos de registro previsíveis

Como nosso sistema agora registra apenas mensagens de log com severidade de ERRO , descobrimos um fenômeno interessante, que apelidamos de “tempestade de erros”.

A tempestade de erros é o que acontece em seu sistema quando ele chega a um estado errôneo, uma interrupção. Quando isso acontece, nossos logs são preenchidos com uma onda massiva de logs de erros repetidos, registrando o mesmo erro repetidamente. E em grande escala - tem muito pouco valor.

Implementamos uma pequena trava na memória (um mecanismo que “trava” em um determinado estado), que trava quando a mesma mensagem de log é registrada por mais de X vezes e interrompe a tempestade de erros.

Isso nos deu informações suficientes sobre o erro e interrompeu a enxurrada de erros, reduzindo assim os custos adicionais durante as interrupções e, mais importante, tornando nossos custos de registro previsíveis durante as interrupções.

Também é importante mencionar aqui que tivemos uma ótima cobertura de métricas, portanto precisávamos desses logs de erro apenas para contexto e informações adicionais do erro em questão.

Limite o bloqueio do fornecedor e alterne os fornecedores

Conseguimos reduzir aproximadamente 50% do custo geral trocando os fornecedores de registro.

Essencialmente, estávamos pagando por um OpenSearch gerenciado glorificado (ElasticSearch na época), não estávamos usando muitos dos recursos avançados das ferramentas.

A maioria de nossas visualizações era baseada em métricas, e a que tínhamos em logs era a visualização básica do Kibana , que funcionaria em qualquer outra plataforma compatível com o Kibana.

Portanto, por meio de um processo de migração não muito complicado, conseguimos economizar grandes somas nos custos gerais de extração de madeira. Alguns dos fornecedores têm processos de migração para facilitar a mudança de seus concorrentes. Use-o.

Se você não está aproveitando os recursos avançados de sua plataforma de log de escolha e sua pilha de monitoramento não é exclusivamente ou principalmente baseada em log, não tenha medo de comprar fornecedores e entrar em guerras de preços.

Não tenha medo de SSH e Kubectl

Em alguns (geralmente sistemas muito sem estado), você não precisa necessariamente ter logs centralizados. Se seus requisitos de segurança permitirem, você pode conectar-se a uma máquina por padrão usando a ferramenta de sua escolha e executar tail-ing , cat-ing e less-ing log e stdout. Eu sei que é bárbaro e muito 1998. Mas funciona e é barato.

Em nossos sistemas, embora os logs ELK fossem de gravidade de erro, todos os logs INFO ainda estavam disponíveis em um arquivo de log rotativo na instância, portanto, ao acessar a instância, poderíamos obter muito contexto, se necessário.

Como tivemos conquistas incríveis de redução de custos por meio das etapas mencionadas acima, não fomos tão longe, mas fizemos um pequeno POC de uso de logs dessa maneira e não foi tão ruim em nosso caso de uso específico.

Pensamentos finais

Você pode pensar que exageramos aqui e nos superamos aqui. Você provavelmente estará certo. Mas:

Em primeiro lugar, usamos esse esforço de redução de custos como uma alavancagem adicional durante as negociações de preços com o fornecedor de madeira, para que tenha valor adicional e possamos realmente colocar um preço nele.

Em segundo lugar, além do mecanismo de “travamento”, a maior parte desse esforço foi realmente fácil, com o mínimo de esforço de desenvolvimento necessário.

Em terceiro lugar, usamos esse esforço como uma oportunidade de aprendizado para alguns dos desenvolvedores juniores da equipe, focando nas dificuldades de fazer qualquer coisa em escala — e “treinar” suas mentes para pensar — ​​em escala em qualquer coisa em que ponham as mãos.

Resumindo, o custo dos logs não deve ser o primeiro item da sua agenda, mas eles fazem parte da sua postura de observabilidade e podem ser um gasto enorme.

Não deveria ser.

Como sempre, pensamentos e comentários são bem-vindos no twitter em @cherkaskyb