As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Detecção de anomalias de log
Você pode criar um detector de anomalias de log para cada grupo de logs. O detector de anomalias de log varre os eventos de log ingeridos no grupo de logs e encontra anomalias nos dados do log. A detecção de anomalias usa machine learning e reconhecimento de padrões para estabelecer linhas de base de conteúdo típico dos logs.
Depois que você cria um detector de anomalias para um grupo de logs, ele é treinado usando as últimas duas semanas de eventos de log do grupo de logs para treinamento. O período de treinamento pode levar até 15 minutos. Depois que o treinamento é concluído, ele começa a analisar os registros recebidos para identificar anomalias, e as anomalias são exibidas no console de CloudWatch registros para você examinar.
CloudWatch O reconhecimento de padrões de registros extrai padrões de registros identificando conteúdo estático e dinâmico em seus registros. Os padrões são úteis para analisar grandes conjuntos de logs porque um grande número de eventos de log geralmente pode ser resumido a apenas alguns padrões.
Por exemplo, veja o exemplo de três eventos de log a seguir.
2023-01-01 19:00:01 [INFO] Calling DynamoDB to store for ResourceID: 12342342k124-12345 2023-01-01 19:00:02 [INFO] Calling DynamoDB to store for ResourceID: 324892398123-1234R 2023-01-01 19:00:03 [INFO] Calling DynamoDB to store for ResourceID: 3ff231242342-12345
No exemplo anterior, todos os três eventos de log seguem um único padrão:
<Date-1> <Time-2> [INFO] Calling DynamoDB to store for resource id <ResourceID-3>
Os campos dentro de um padrão são chamados de tokens. Os campos que variam dentro de um padrão, como um ID de solicitação ou um timestamp, são chamados de tokens dinâmicos. Cada valor diferente encontrado para um token dinâmico é chamado de valor de token.
Se o CloudWatch Logs puder inferir o tipo de dados que um token dinâmico representa, ele exibirá o token como<. string-number>stringÉ uma descrição do tipo de dados que o token representa. numberMostra onde esse token aparece no padrão, em comparação com os outros tokens dinâmicos.
CloudWatch O Logs atribui a parte da string do nome com base na análise do conteúdo dos eventos de log que a contêm.
Se o CloudWatch Logs não conseguir inferir o tipo de dados que um token dinâmico representa, ele exibe o token como <Token- number > e number indica onde esse token aparece no padrão, em comparação com os outros tokens dinâmicos.
Exemplos comuns de tokens dinâmicos incluem códigos de erro, endereços IP, registros de data e hora e solicitações. IDs
A detecção de anomalias de log usa esses padrões para encontrar anomalias. Após o período de treinamento de modelo do detector de anomalias, os logs são avaliados em relação às tendências conhecidas. O detector de anomalias sinaliza flutuações significativas como anomalias.
Este capítulo descreve como habilitar a detecção de anomalias, visualizar anomalias, criar alarmes para detectores de anomalias de log e as métricas que os detectores de anomalias de log publicam. Também descreve como criptografar o detector de anomalias e seus resultados com. AWS Key Management Service
A criação de detectores de anomalias de log não é cobrada.
Gravidade e prioridade de anomalias e padrões
A cada anomalia encontrada por um detector de anomalias de log é atribuída uma prioridade. A cada padrão encontrado é atribuída uma gravidade.
A prioridade é calculada automaticamente com base no nível de gravidade do padrão e na quantidade de desvio dos valores esperados. Por exemplo, se um determinado valor de token aumentar repentinamente em 500%, essa anomalia pode ser designada como tendo prioridade
HIGH, mesmo que sua gravidade sejaNONE.A gravidade é baseada apenas nas palavras-chave encontradas nos padrões, como
FATAL,ERROReWARN. Se nenhuma dessas palavras-chave for encontrada, a gravidade de um padrão será marcada comoNONE.
Tempo de visibilidade das anomalias
Ao criar um detector de anomalias, você especifica o período máximo de visibilidade das anomalias para ele. Esse é o número de dias em que a anomalia é exibida no console e é retornada pela operação da ListAnomaliesAPI. Depois de decorrido esse tempo para uma anomalia, se ela continuar ocorrendo, será automaticamente aceita como um comportamento normal e o modelo do detector de anomalias não a sinalizará mais como uma anomalia.
Se você não ajustar o tempo de visibilidade quando criar um detector de anomalias, o padrão de 21 dias será usado.
Supressão de uma anomalia
Depois que uma anomalia é encontrada, você pode optar por suprimi-la temporária ou permanentemente. A supressão de uma anomalia faz com que o detector de anomalias pare de sinalizar essa ocorrência como uma anomalia durante o tempo que você especificar. Ao suprimir uma anomalia, você pode optar por suprimir apenas essa anomalia específica ou todas as anomalias relacionadas ao padrão no qual a anomalia foi encontrada.
Você continua podendo visualizar as anomalias suprimidas no console. Você também pode escolher deixar de suprimi-las.
Perguntas frequentes
AWS Usa meus dados para treinar algoritmos de aprendizado de máquina para AWS uso ou para outros clientes?
Não. O modelo de detecção de anomalias criado pelo treinamento é baseado nos eventos de log de um grupo de logs e só é usado nesse grupo de logs e nessa conta da AWS .
Que tipos de eventos de log funcionam bem com a detecção de anomalias?
A detecção de anomalias de log é adequada para: logs de aplicações e outros tipos de log em que a maioria das entradas de log se enquadra nos padrões típicos. Grupos de logs com eventos que contêm um nível de log ou palavras-chave de gravidade, como INFO, ERROR e DEBUG, são especialmente adequados para a detecção de anomalias de log.
A detecção de anomalias de log não é adequada para: Registrar eventos com estruturas JSON extremamente longas, como CloudTrail Logs. A análise de padrões só analisa os primeiros 1.500 caracteres de uma linha de log, portanto, todos os caracteres além desse limite são ignorados.
Logs de auditoria ou acesso, como logs de fluxo de VPC, também terão menos sucesso com a detecção de anomalias. A detecção de anomalias serve para encontrar problemas de aplicações, assim sendo, pode não ser adequada para anomalias de rede ou acesso.
Para ajudá-lo a determinar se um detector de anomalias é adequado para um determinado grupo de CloudWatch registros, use a análise de padrões de registros para encontrar o número de padrões nos eventos de registro no grupo. Se a quantidade de padrões não passar de cerca de 300, a detecção de anomalias poderá funcionar bem. Para obter mais informações sobre análise de padrões, consulte Análise de padrões.
O que é sinalizado como anomalia?
As seguintes ocorrências podem fazer um evento de log ser sinalizado como uma anomalia:
Um evento de log com um padrão nunca visto antes no grupo de logs.
Uma variação significativa de um padrão conhecido.
Um novo valor para um token dinâmico que tem um conjunto discreto de valores usuais.
Uma grande alteração no número de ocorrências de um valor para um token dinâmico.
Embora todos os itens anteriores possam estar sinalizados como anomalias, nem todos significam que a aplicação está funcionando mal. Por exemplo, higher-than-usual vários valores de 200 sucesso podem ser sinalizados como uma anomalia. Em casos como esse, você pode considerar suprimir essas anomalias que não indicam problemas.
O que acontece com os dados confidenciais que estão sendo mascarados?
Todas as partes de eventos de log que são mascaradas como dados confidenciais não são varridas para detectar anomalias. Para obter mais informações, consulte Help protect sensitive log data with masking.
