Cada serviço da AWS registra seu processamento em arquivos organizados em grupos de log do CloudWatch. Os grupos de log geralmente são nomeados após o próprio serviço para facilitar a identificação. As mensagens do sistema do serviço ou as informações de estado comum são gravadas nesses arquivos de log por padrão.
No entanto, você pode adicionar informações de mensagens de log personalizadas sobre as padrão. Se esses logs forem criados com sabedoria, eles podem servir para criar painéis úteis do CloudWatch.
Com métricas e informações estruturadas que fornecem detalhes extras sobre o processamento do trabalho. Eles não apenas podem conter widgets padrão com informações semelhantes ao sistema sobre o serviço. Você pode estender isso com seu próprio conteúdo, agregado em seu widget ou métrica personalizada.
últimas postagens
Consultar os arquivos de log
Fonte: aws.amazon.com
O AWS CloudWatch Log Insights permite pesquisar e analisar dados de log de seus recursos da AWS em tempo real. Você pode vê-lo como uma exibição de banco de dados. Você define a consulta no painel e o painel irá selecioná-la quando você a visitar ou na janela de tempo especificada no passado, conforme você a define na exibição do painel.
Ele usa uma linguagem de consulta chamada CloudWatch Logs Insights para pesquisar e analisar dados de log. A linguagem de consulta é baseada em um subconjunto da linguagem SQL. Ele permite que você pesquise e filtre dados de log. Você pode pesquisar eventos de log específicos, texto de log personalizado ou palavras-chave e filtrar dados de log com base em campos específicos. E o mais importante, agregue dados de log em um ou mais arquivos de log para gerar métricas e visualizações resumidas.
Quando você executa uma consulta, o CloudWatch Log Insights pesquisa os dados de log no grupo de logs. Em seguida, retorna os textos resultantes dos arquivos que correspondem aos seus critérios de consulta.
Exemplo de consulta de arquivo de log
Vamos dar uma olhada em algumas consultas básicas para entender o conceito.
Cada serviço, por padrão, registra alguns erros de serviço cruciais. Mesmo se você não criar um log personalizado dedicado para esses eventos de erro. Em seguida, com uma consulta simples, você pode contar o número de erros nos logs de seu aplicativo na última hora:
fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(1h)
Ou aqui está como monitorar o tempo médio de resposta de sua API no último dia:
fields @timestamp, @message | filter @message like /API response time/ | stats avg(response_time) by bin(1d)
Como, por padrão, a utilização da CPU é uma informação registrada pelo serviço no CloudWatch, você também pode coletar este tipo de métrica:
fields @timestamp, @message | filter @message like /CPUUtilization/ | stats avg(value) by bin(1h)
Essas consultas podem ser personalizadas para atender ao seu caso de uso específico e podem ser usadas para criar métricas e visualizações personalizadas nos painéis do CloudWatch. A maneira de fazer isso é colocar o widget no painel e colocar o código dentro do widget para definir o que selecionar.
Aqui estão alguns dos widgets que podem ser usados nos painéis do CloudWatch e preenchidos pelo conteúdo do Log Insights:
- Widgets de texto – exibem informações baseadas em texto, como a saída de uma consulta do CloudWatch Insights.
- Widgets de consulta de log – exibem os resultados de uma consulta de log do CloudWatch Insights, como o número de erros nos logs de seu aplicativo.
Como criar informações de log úteis para o painel
Fonte: aws.amazon.com
Para usar efetivamente as consultas do CloudWatch Insights nos painéis do CloudWatch, é bom seguir algumas práticas recomendadas ao criar logs do CloudWatch para cada um dos serviços que você usa em seu sistema. Aqui estão algumas dicas:
#1. Usar registro estruturado
Você deve seguir um formato de registro que usa um esquema predefinido para registrar dados em um formato estruturado. Isso torna mais fácil pesquisar e filtrar dados de log usando consultas do CloudWatch Insights.
Isso basicamente significa padronizar seus logs em diferentes serviços em sua plataforma de arquitetura. Tê-lo definido nos padrões de desenvolvimento ajuda tremendamente.
Por exemplo, você pode definir que cada problema relacionado a uma tabela específica do banco de dados será registrado com uma mensagem inicial como: “[TABLE_NAME] Aviso / Erro:
Ou você pode separar trabalhos de dados completos de trabalhos de dados delta por prefixos como “[FULL/DELTA]” para selecionar apenas mensagens relacionadas aos processos de dados concretos.
Você pode definir que, ao processar dados de um sistema de origem específico, o nome do sistema será um prefixo de cada entrada de log relacionada. É muito mais fácil depois filtrar essas mensagens dos arquivos de log e criar métricas sobre elas.
Fonte: aws.amazon.com
#2. Use formatos de registro consistentes
Use formatos de log consistentes em todos os seus recursos da AWS para facilitar a pesquisa e a filtragem de dados de log usando consultas do CloudWatch Insights.
Isso está bastante relacionado ao ponto anterior, mas o fato é que quanto mais padronizado for o formato do log, mais fácil será usar os dados do log. Os desenvolvedores podem então confiar nesse formato e usá-lo de forma intuitiva.
O fato cruel é que a maioria dos projetos não se preocupa com nenhum padrão em relação à exploração madeireira. Além disso, muitos projetos nem mesmo criam logs personalizados. É chocante, mas também tão comum ao mesmo tempo.
Não consigo nem dizer quantas vezes me peguei imaginando como as pessoas podem viver aqui sem nenhuma abordagem de tratamento de erros. E se alguém se esforçou para fazer algum tipo de tratamento de erro como exceção, o fez de forma errada.
Portanto, um formato de log consistente é um recurso forte. Muitos não os têm.
#3. Incluir metadados relevantes
Inclua metadados em seus dados de log, como timestamps, IDs de recursos e códigos de erro, para facilitar a pesquisa e filtragem de dados de log usando consultas do CloudWatch Insights.
#4. Ativar rotação de log
Habilite a rotação de log para evitar que seus dados de log fiquem muito grandes e para facilitar a pesquisa e filtragem de dados de log usando consultas do CloudWatch Insights.
Não ter dados de log é uma coisa, mas ter muitos deles sem estrutura é igualmente desesperador. Se você não pode usar seus dados, é como não ter nenhum dado.
#5. Usar agentes de logs do CloudWatch
Se você não conseguir se conter e simplesmente se recusar a criar seu sistema de log personalizado, use pelo menos os agentes do CloudWatch Logs. Eles enviam automaticamente dados de log de seus recursos da AWS para o CloudWatch Logs. Isso torna mais fácil pesquisar e filtrar dados de log usando consultas do CloudWatch Insights.
Exemplos de consulta de insights mais complexos
A consulta do CloudWatch Insights pode ser mais complicada do que apenas uma instrução de duas linhas.
fields @timestamp, @message | filter @message like /ERROR/ | filter @message not like /404/ | parse @message /.*[(?<timestamp>[^]]+)].*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/ | stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status | sort count desc | limit 20
Esta consulta faz o seguinte:
Essa consulta identifica os erros mais comuns em seu aplicativo e rastreia o tempo médio de resposta para cada combinação de método HTTP, caminho e código de status. Você pode usar os resultados para criar métricas e visualizações personalizadas nos painéis do CloudWatch para monitorar o desempenho de seu aplicativo da Web e solucionar problemas.
Outro exemplo de consulta das mensagens do serviço Amazon S3:
fields @timestamp, @message | filter @message like /REST.API.REQUEST/ | parse @message /.*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/ | stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status | sort count desc | limit 20
- A consulta seleciona eventos de log que contêm a string “REST.API.REQUEST”.
- Em seguida, analisa a mensagem de log para extrair o método HTTP, caminho, código de status e tempo de resposta.
- Ele calcula o tempo médio de resposta e a contagem de eventos de log para cada combinação de método HTTP, caminho e código de status e classifica os resultados por contagem em ordem decrescente.
- Limita a saída aos 20 principais resultados.
Você pode usar a saída dessa consulta para criar um gráfico de linha em um painel do CloudWatch que mostre o tempo médio de resposta para cada combinação de método HTTP, caminho e código de status ao longo do tempo.
Construindo o Painel
Para preencher as métricas e visualizações nos painéis do CloudWatch a partir da saída das consultas de log do CloudWatch Insights, você pode navegar até o console do CloudWatch e seguir o assistente do painel para criar seu conteúdo.
Depois disso, é assim que o código de um painel do CloudWatch se parece e contém as métricas preenchidas pelos dados da consulta do CloudWatch Insights:
{
"widgets": [
{
"type": "metric",
"x": 0,
"y": 0,
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/EC2",
"CPUUtilization",
"InstanceId",
"i-0123456789abcdef0",
{
"label": "CPU Utilization",
"stat": "Average",
"period": 300
}
]
],
"view": "timeSeries",
"stacked": false,
"region": "us-east-1",
"title": "EC2 CPU Utilization"
}
},
{
"type": "log",
"x": 0,
"y": 6,
"width": 12,
"height": 6,
"properties": {
"query": "fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
",
"region": "us-east-1",
"title": "Application Errors"
}
}
]
}
Este painel do CloudWatch contém dois widgets:
É um arquivo no formato JSON com uma definição do painel e as métricas internas. Ele contém (como uma propriedade) também a própria consulta de insight.
Você pode pegar o código e implantá-lo em qualquer conta da AWS de que precisar. Supondo que os serviços e as mensagens de log sejam consistentes em todas as suas contas e estágios da AWS, o painel funcionará em todas as contas sem a necessidade de alterar o código-fonte do painel.
Palavras Finais
Construir uma sólida estrutura madeireira sempre foi um bom investimento no futuro da confiabilidade do sistema. Agora pode servir a um propósito ainda maior. Você pode ter painéis úteis com métricas e visualizações apenas como um efeito colateral disso.
Tendo a necessidade de ser feito apenas uma vez, com apenas um pouco de trabalho adicional, a equipe de desenvolvimento, a equipe de teste e os usuários de produção podem se beneficiar da mesma solução.
A seguir, confira as melhores ferramentas de monitoramento da AWS.