Integrar o AWS CloudWatch com ferramentas de observação de terceiros pode mudar o jogo para monitorar serviços sem servidor.
Esta postagem do blog explicará por que você deve integrar o CloudWatch com uma ferramenta de observação de terceiros em um ambiente de serviços sem servidor.
Você também aprenderá a exportar logs do CloudWatch de forma eficaz usando tecnologia sem servidor para ferramentas de observação de terceiros, como DataDog, Grafana e outras, para simplificar o gerenciamento de logs e fornecer insights mais profundos sobre o desempenho dos seus serviços.
Índice
Do you export your CloudWatch logs?
Yes
No
No, but I plan to export in the future
O caso sem servidor para exportar logs do CloudWatch
O monitoramento de um serviço sem servidor começa com logs de serviço. O AWS Lambda e o CloudWatch têm uma integração nativa e transparente. As funções do Lambda produzem seus logs para grupos de log do CloudWatch por padrão. Você pode aprender mais sobre as melhores práticas de registro em log em uma postagem anterior aqui .
Depois que os logs aparecem no console do CloudWatch, a próxima etapa no monitoramento do seu serviço é criar um painel. Você pode aprender mais sobre as melhores práticas de criação de painéis em um post anterior aqui .
No entanto, os painéis do CloudWatch têm desvantagens: eles não permitem uma única visualização de várias contas da AWS. Essa capacidade é crítica quando você trabalha em uma empresa com vários serviços abrangendo várias contas da AWS e precisa depurar ações do usuário em vários serviços em um único painel. Além disso, algumas empresas preferem ferramentas de observabilidade de terceiros, como Grafana Cloud, DataDog e outras, devido à sua facilidade de uso e outros recursos avançados.
Então por que você deve continuar usando o CloudWatch? Por que não simplesmente enviar os logs diretamente para uma ferramenta de observabilidade de terceiros?
Se você usa tecnologia serverless, faz mais sentido continuar usando o CloudWatch como saída de logs padrão. Aqui está o motivo:
Desempenho. Vamos supor que exportamos todos os logs diretamente para um terceiro e não gravamos no CloudWatch. A integração com essas ferramentas de terceiros pode exigir o uso de um SDK. Os SDKs afetam o desempenho da função Lambda, pois o processo Lambda exporta os logs com uma chamada de API para o terceiro durante a invocação.
Menos dependências de implantação. Outra opção para integrar com ferramentas de terceiros é usar uma extensão Lambda (na forma de uma camada Lambda - como DataDog ). A camada lambda tem suas desvantagens que eu discuto aqui , mas a maior desvantagem é que ela adiciona outra dependência de tempo de implantação.
Fácil de mudar. Se você quiser mudar de um terceiro para outro (sim, isso acontece!), você deve mudar TODAS as suas funções para usar um novo SDK ou extensão Lambda — uma dor enorme. No entanto, se você gravar todos os logs no CloudWatch e exportá-los de uma solução centralizada em sua conta para um terceiro - mudar um terceiro se traduz em mudar o exportador de logs enquanto seus serviços não mudam!
Por outro lado, a única grande desvantagem de usar o CloudWatch e uma ferramenta de terceiros simultaneamente é armazenar logs em ambos os sistemas e o custo adicional que eles trazem. No entanto, você pode reduzir custos reduzindo a retenção de log no CloudWatch ou usando as ferramentas de terceiros apenas em contas de produção e não em contas de desenvolvimento.
Para resumir, escrever logs de funções do Lambda no CloudWatch em vez de exportá-los diretamente para a ferramenta de terceiros significa melhor desempenho, menos dependências de implantação e uma troca mais fácil para uma ferramenta de terceiros diferente no futuro, mas esses recursos têm um custo adicional.
Agora, tudo o que resta a fazer é implementar um exportador de logs centralizado que enviará os logs do CloudWatch para um terceiro de sua escolha sem afetar nenhum dos seus serviços.
Exportadores sem servidor do CloudWatch Logs
Analisaremos vários designs para um exportador de logs centralizado. Você o implantará em suas contas em toda a organização e ele garantirá que os logs sejam exportados para a ferramenta de terceiros. Conforme observado antes, seus serviços sem servidor não têm conhecimento do exportador de logs ou das ferramentas de terceiros.
Os designs a seguir dependem de um recurso de assinatura do CloudWatch para assinar grupos de logs em um destino, o que significa que o CloudWatch envia fluxos de logs para um destino de sua escolha: Kinesis DataStream, Amazon OpenSearch, função Lambda ou Kinesis Firehose.
Estas são as opções possíveis para os pontos de entrada do design.
Você pode usar assinaturas para obter acesso a um feed em tempo real de eventos de log do CloudWatch Logs e entregá-lo a outros serviços, como um fluxo do Amazon Kinesis, um fluxo do Amazon Kinesis Data Firehose ou AWS Lambda para processamento personalizado, análise ou carregamento para outros sistemas. Quando os eventos de log são enviados ao serviço de recebimento, eles são codificados em base64 e compactados com o formato gzip.
Você pode adicionar um filtro para selecionar quais grupos de logs você não quer exportar. Para mais informações, consulte a documentação .
Analisaremos vários projetos de exportadores de logs, discutiremos seus prós e contras e como é fácil alternar entre terceiros.
Todos os projetos contam com arquitetura sem servidor para manter os custos de gerenciamento e manutenção os mais baixos possíveis.
Observe que não cubro custos neste post. Certifique-se de calcular um design de sua escolha e combiná-lo com suas necessidades e orçamento.
Mangueira de incêndio Kinesis
No design a seguir, usaremos o Kinesis Firehose como o ponto de entrada que recebe um lote de logs. Quando eventos de log são enviados para o serviço de recebimento, eles são codificados em base64 e compactados com o formato gzip, de acordo com a documentação .
O FireHose pode invocar uma função Lambda de transformação por lote. A função Lambda pode processar o lote, alterá-lo e retornar a saída processada para o Firehose. A função tem cinco minutos por lote para processá-lo. A transformação Lambda fornece vários recursos poderosos que você pode implementar:
Filtre os logs do lote, controlando assim quais logs você exporta para terceiros.
Enriquecer logs com metadados (etiquetas de pilha, etc.)
Remova informações pessoais identificáveis (PII) dos logs antes de enviá-los a terceiros. Você tem controle total.
Uma vez processado, o Firehose envia o lote para um destino de endpoint HTTP. Você pode enviá-lo para parceiros de observabilidade da AWS, como Datadog , Dynatrace, LogicMonitor, MongoDB, New Relic, Splunk ou Sumo Logic.
Prós:
Solução totalmente sem servidor.
O Firehose lida com falhas de invocação de funções de transformação .
Excelente depuração. Você pode configurar o Firehose para enviar lotes com falha para um bucket S3. Cada lote inclui logs que ajudam a depurar a falha do destino HTTP. Consulte a documentação aqui .
Capacidades da função Lambda de transformação conforme descrito acima.
Fácil alternar entre terceiros suportados: tudo o que você precisa fazer é alterar a URL de destino (e as chaves secretas da API).
Não é necessário escrever código que envie solicitações HTTPS e gerencie novas tentativas, pois o Firehose faz isso para você.
Todos os recursos de design oferecem suporte ao dimensionamento automático.
Contras:
Se uma resposta não estiver em conformidade com os requisitos abaixo, o servidor Kinesis Firehose a tratará como se tivesse um código de status 500 sem corpo. - AWS
O Firehose tem um formato de solicitação/resposta HTTP exclusivo; nem todas as ferramentas de terceiros o suportam. Consulte a documentação aqui .
Kinesis DataStreams e Pipes EventBridge
Uma das principais desvantagens do design anterior era que nem TODAS as ferramentas de observabilidade de terceiros eram suportadas, por exemplo, Grafana. Os dois designs a seguir resolvem isso e permitem que você exporte para qualquer ferramenta de terceiros. Vamos revisar o primeiro design.
Este design se tornou realidade a partir de uma discussão com um colega herói do AWS serverless, Aidan Steele , que sugeriu EventBridge pipes como uma opção. Obrigado, Aidan!
Neste exemplo, assinaremos nossos logs para Kinesis DataStreams. Definiremos a saída dos DataStreams para um EventBridge Pipe. Não podemos usar Firehose como um ponto de entrada porque ele não suporta exportação para um EventBridge pipe.
Pipes são destinados a integrações ponto a ponto entre fontes e alvos suportados, com suporte para transformações e enriquecimento avançados. Ele reduz a necessidade de conhecimento especializado e código de integração ao desenvolver arquiteturas orientadas a eventos
Os pipes do EventBridge obterão um lote de logs do Kinesis DataStreams, acionarão uma função Lambda de enriquecimento e enviarão o lote para um destino de API de nossa escolha por HTTPS.
Neste exemplo, exportaremos os logs para o Grafana.
Você pode usar os recursos de filtro do EventBridge Pipe, mas como os logs são compactados, filtrar logs no Lambda de enriquecimento é mais simples.
A função Lambda de enriquecimento pode implementar recursos semelhantes ao Lambda de transformação no projeto Firehose:
Filtre os logs do lote, controlando assim quais logs são exportados para terceiros.
Enriquecer logs com metadados (etiquetas de pilha, etc.)
Remova informações pessoais identificáveis (PII) dos logs antes de enviá-los a terceiros. Você tem controle total.
Retorne uma carga útil que o terceiro espera receber, ou seja, a carga útil JSON que o Grafana Loki espera receber - veja o exemplo nos documentos e a imagem abaixo:
O Lambda de enriquecimento retorna o payload que contém os logs filtrados e enriquecidos no formato que um terceiro específico espera. O pipe EventBridge então envia o payload para o destino da API.
O EventBridge oferece suporte ao envio de falhas com informações de depuração para um S3 semelhante ao Firehose. Este é um novo recurso que foi anunciado em 15 de novembro de 2023 - https://aws.amazon.com/blogs/compute/introducing-logging-support-for-amazon-eventbridge-pipes/ .
Prós:
Solução totalmente sem servidor.
O design oferece suporte a TODOS os terceiros por meio de exportações de logs em lote HTTP.
Capacidades da função Lambda de enriquecimento - filtro, PII, enriquecimento.
Não é necessário escrever código que envie solicitações HTTPS e gerencie novas tentativas, pois o EventBridge Pipes cuida disso para você.
EventBridge Pipes e Lambda oferecem suporte ao dimensionamento automático.
Lotes de logs com falha são enviados para um bucket S3 com informações de depuração.
Contras:
É mais difícil alternar entre terceiros. Você precisa alterar o destino da API do Pipe e reescrever a função de enriquecimento para corresponder à carga útil do outro terceiro.
O KinesisData Streams pode custar mais que o Firehose se você não selecionar o mecanismo de escala correto que se ajuste aos seus bursts de log ( sob demanda vs. provisionado ).
Kinesis DataStreams e função Lambda
Este terceiro design substitui os Pipes do EventBridge e oferece controle total sobre tratamento de erros e novas tentativas ao custo de código extra.
Substituiremos os Pipes do EventBridge por uma Função Lambda, conforme descrito aqui .
Esta única função agora é necessária para processar nossos logs, filtrar, enriquecer, remover PII e enviar o lote para o terceiro com uma solicitação HTTP. Ele deve tentar novamente, manipular erros e enviar lotes com falha ou entradas de log para o bucket S3 de backup.
Se você acha que a função faz muito, você pode dividi-la em duas com um SQS entre elas: função (filtrar, enriquecer, PII) -> SQS -> função (exportar, enviar falhas para S3) , onde a segunda função lida com a exportação para a terceira parte. Este design é mais robusto, mas adiciona latência ao processo de exportação.
Prós:
Solução totalmente sem servidor.
O design oferece suporte a TODOS os terceiros por meio de chamadas em lote HTTP.
Capacidades da função Lambda de enriquecimento - filtro, PII, enriquecimento.
Ela oferece a melhor capacidade de depuração, pois você controla a parte crítica da cadeia: a função Lambda.
O Lambda suporta dimensionamento automático.
Os logs com falha são enviados para um bucket S3 de backup.
Contras:
Você precisa escrever muito código para que tudo funcione.
É mais difícil alternar entre terceiros: você precisa reescrever a função de enriquecimento para corresponder à carga útil do outro terceiro e alterar o código que exporta via HTTP.
O KinesisData Streams pode custar mais que o Firehose se você não selecionar o mecanismo de escala correto que se ajuste aos seus bursts de log ( sob demanda vs. provisionado ).
Resumo
Abordamos três designs sem servidor para exportar logs do CloudWatch para terceiros.
Cada um tem seus prós e contras. Primeiro, selecione o terceiro que se encaixa em seus requisitos de observabilidade, então escolha o design que pode corresponder ao seu terceiro.
Lembre-se de estimar os custos de exportação e projetar o mecanismo de implantação para implantar o exportador de logs em sua organização. Certifique-se de gerenciá-lo por meio de infraestrutura como código (IaC) para que seja fácil implantar, gerenciar e atualizar em toda a organização.
Comments