Detecção de anomalias de log

Você pode criar um detector de anomalias de log para cada grupo de log. O detector de anomalias examina os eventos de registro ingeridos no grupo de registros e encontra anomalias nos dados de registro. A detecção de anomalias usa aprendizado de máquina e reconhecimento de padrões para estabelecer linhas de base do conteúdo típico de registros.

Depois de criar um detector de anomalias para um grupo de registros, ele treina usando as últimas duas semanas de eventos de registro no grupo de registros 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 registros porque um grande número de eventos de registro geralmente pode ser compactado em alguns padrões.

Por exemplo, veja o exemplo a seguir de três eventos de log.

2023-01-01 19:00:01 [INFO] Calling DynamoDB to store for resource id 12342342k124-12345
2023-01-01 19:00:02 [INFO] Calling DynamoDB to store for resource id 324892398123-12345
2023-01-01 19:00:03 [INFO] Calling DynamoDB to store for resource id 3ff231242342-12345

No exemplo anterior, todos os três eventos de log seguem um padrão:

<*> <*> [INFO] Calling DynamoDB to store for resource id <*>

Os campos dentro de um padrão são chamados de tokens. Os campos que variam dentro de um padrão, como ID de solicitação ou carimbo de data/hora, são chamados de tokens dinâmicos. Os tokens dinâmicos são representados por <*> quando o CloudWatch Logs exibe o padrão. Cada valor diferente encontrado para um token dinâmico é chamado de valor de token.

Exemplos comuns de tokens dinâmicos incluem códigos de erro, carimbos de data/hora e IDs de solicitação.

A detecção de anomalias de registros usa esses padrões para encontrar anomalias. Após o período de treinamento do modelo do detector de anomalias, os registros são avaliados em relação às tendências conhecidas. O detector de anomalias sinaliza flutuações significativas como anomalias.

A criação de detectores de anomalias de log não incorre em cobranças.

Gravidade e prioridade de anomalias e padrões

Cada anomalia encontrada por um detector de anomalias logarítmicas recebe uma prioridade. Cada padrão encontrado recebe uma severidade.

• A prioridade é calculada automaticamente e se baseia no nível de severidade 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 HIGH prioritária, mesmo que sua gravidade seja. NONE

• A severidade é baseada apenas em palavras-chave encontradas nos padrõesFATAL, comoERROR, WARN e. Se nenhuma dessas palavras-chave for encontrada, a gravidade de um padrão será marcada comoNONE.

Tempo de visibilidade da anomalia

Ao criar um detector de anomalias, você especifica o período máximo de visibilidade de 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 período de tempo para uma anomalia, se ela continuar ocorrendo, ela é automaticamente aceita como um comportamento normal e o modelo do detector de anomalias para de sinalizá-la como uma anomalia.

Se você não ajustar o tempo de visibilidade ao criar um detector de anomalias, 21 dias serão usados como padrão.

Suprimindo uma anomalia

Depois que uma anomalia for 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 pelo período de tempo especificado. Ao suprimir uma anomalia, você pode optar por suprimir somente aquela anomalia específica ou suprimir todas as anomalias relacionadas ao padrão em que a anomalia foi encontrada.

Você ainda pode ver anomalias suprimidas no console. Você também pode optar por parar de suprimi-los.

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 registro em um grupo de registros e é usado somente nesse grupo de registros e nessa AWS conta.

Que tipos de eventos de log funcionam bem com a detecção de anomalias?

A detecção de anomalias de log é adequada para: registros de aplicativos e outros tipos de registros em que a maioria das entradas de registro se encaixa nos padrões típicos. Grupos de registros com eventos que contêm palavras-chave de nível de registro ou gravidade, como INFO, ERROR e DEBUG, são especialmente adequados para registrar a detecção de anomalias.

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 analisa somente até os primeiros 1500 caracteres de uma linha de registro, portanto, todos os caracteres além desse limite são ignorados.

Registros de auditoria ou acesso, como registros 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 aplicativos, portanto, pode não ser adequada para anomalias de rede ou de 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 o número de padrões não for maior do que cerca de 300, a detecção de anomalias pode funcionar bem. Para obter mais informações sobre análise de padrões, consulteAnálise de padrões.

O que é sinalizado como uma anomalia?

As seguintes ocorrências podem fazer com que um evento de log seja sinalizado como uma anomalia:

• Um evento de registro com um padrão nunca visto antes no grupo de registros.

• 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 mudança no número de ocorrências de um valor para um token dinâmico.

Embora todos os itens anteriores possam estar marcados como anomalias, nem todos significam que o aplicativo 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 a supressão dessas anomalias que não indicam problemas.

O que acontece com dados confidenciais que estão sendo mascarados?

Todas as partes dos eventos de registro que são mascaradas como dados confidenciais não são examinadas em busca de anomalias. Para obter mais informações sobre como mascarar dados confidenciais, consulte Ajudar a proteger dados de log confidenciais com mascaramento.