How intelligent health check works - Simple Log Service: Central de Documentação do Alibaba Cloud

O recurso de detecção inteligente de anomalias do Simple Log Service oferece capacidades de treinamento de modelos e verificação de integridade em tempo real. Ele suporta treinamento de modelos automatizado, inteligente e adaptativo, além de detecção de anomalias para dados como logs e métricas.

Informações básicas

Dados baseados em tempo, como logs e métricas, acumulam-se ao longo do tempo. Por exemplo, se um serviço gera 10 milhões de entradas de dados por dia, o total acumulado ao final de um ano chega a 3,6 bilhões de entradas. O uso de regras fixas para verificar esses dados pode ocasionar os seguintes problemas:

**Baixa eficiência:** é necessário configurar manualmente diversas regras para identificar e capturar anomalias.
**Pouca pontualidade:** a maioria dos dados de séries temporais é sensível ao tempo. Falhas e alterações afetam os padrões das métricas. Uma anomalia identificada por uma regra específica pode ser considerada normal em um momento posterior.
**Configuração complexa:** dados de séries temporais apresentam formatos variados, como picos, pontos de inflexão e variações periódicas. Os intervalos de limiar também diferem. Para padrões complexos, configurar regras costuma ser difícil.
**Desempenho insatisfatório:** fluxos de dados mudam dinamicamente e os modelos de negócios evoluem rapidamente, tornando as regras fixas ineficazes em novos cenários. Isso pode gerar muitos falsos positivos ou falsos negativos. A tolerância a anomalias varia conforme o cenário e o usuário. Ao investigar problemas, capturar mais pontos de anomalia válidos auxilia a investigação. Ao tratar alertas, um número menor de pontos de anomalia, porém mais relevantes, melhora a eficiência do processamento.

Para resolver esses problemas, o Simple Log Service oferece o recurso de verificação inteligente de integridade. Esse recurso utiliza algoritmos de IA proprietários para agregar, verificar e criar alertas para dados em streaming, como logs e métricas. Basta especifique os itens monitorados. O modelo de algoritmo detecta anomalias automaticamente, adapta-se às mudanças do negócio e refina os alertas sem necessidade de configuração manual de regras.

Como funciona

O Simple Log Service utiliza instruções SQL para construir e agregar métricas de monitoramento. Ele extrai dados para um modelo em intervalos regulares com base nas regras de agendamento, grava os resultados da verificação de integridade em um Logstore de destino (internal-ml-log) seguindo padrões de eventos e envia notificações de alerta para anomalias.

A verificação inteligente de integridade disponibiliza os seguintes recursos.

Recursos

**Recurso**

Descrição	Configure objetos monitorados
Use instruções SQL ou de consulta e análise para converter dados de log em métricas de monitoramento e iniciar tarefas.	Analise dados em intervalos regulares
Configure características dos dados, campos de entidade e campos de métrica conforme necessário. A instância de verificação de integridade descobre automaticamente novas entidades monitoradas, extrai dados em intervalos regulares e realiza modelagem automática com análise inteligente. O modelo suporta intervalos de extração tão curtos quanto um segundo.	Configurações de parâmetros e prévia do desempenho do modelo
Visualize os efeitos de diferentes parâmetros do modelo e a curva de séries temporais das métricas junto à curva de pontuação de anomalias. Isso auxilia na definição dos parâmetros do modelo mais adequados às características dos seus dados.	Saída de resultados em múltiplos canais
Os resultados da verificação de integridade são armazenados no Logstore de destino. As informações sobre anomalias são enviadas a você por meio de notificações de alerta.	A tabela a seguir descreve os principais termos utilizados na verificação inteligente de integridade.

Termos

**Termo**

Descrição	Tarefa
Uma tarefa de verificação de integridade inclui informações como características dos dados, parâmetros do modelo e políticas de alerta.	Instância
Uma tarefa de verificação de integridade gera uma instância de execução com base na configuração da tarefa. Cada instância extrai dados, execute o modelo de algoritmo e distribui os resultados da verificação em intervalos regulares conforme a configuração da tarefa. - Uma tarefa gera apenas uma instância. Múltiplas instâncias não podem ser executadas simultaneamente, mesmo que a instância seja agendada normalmente ou reexecutada devido a uma anomalia. - Atualizações em execução dos parâmetros não são suportadas. Ao modifique a configuração da tarefa, a verificação de integridade cria uma nova instância para execute o modelo de algoritmo. A nova instância é independente da anterior. - Para obter mais informações sobre como diferentes operações afetam o agendamento e a execução de instâncias, consulte Cenários de agendamento e execução.	ID da instância O identificador exclusivo de uma instância de execução. Hora de criação O momento em que a instância é criada. Normalmente, uma instância é criada com base nas regras da tarefa configuradas. Para execuções de preenchimento retroativo ou para recuperar atrasos, a instância é criada imediatamente.
Tempo de execução	O momento em que a instância começa a ser executada. Em caso de reexecução da tarefa, corresponde ao início da última execução.
Hora de término	O momento em que a instância conclui a execução. Em caso de reexecução da tarefa, corresponde ao término da última execução.
Status de execução	O status de execução da instância. Valores válidos: - Em execução (RUNNING) - Reexecutando (STARTING) - Concluída com êxito (SUCCEEDED) - Com falha (FAILED)
Características dos dados	As características dos dados incluem as seguintes configurações: - Intervalo de observação: o intervalo de tempo para observação e coleta de dados, que também é o intervalo para análise do algoritmo. Ele é gerado pelas regras da tarefa e não é afetado por timeouts, atrasos ou execuções de preenchimento retroativo da instância anterior. Na maioria dos cenários, o intervalo de observação de um fluxo de dados é estável e pode ser tão curto quanto um segundo. - Campo de tempo: o campo nos dados que indica o momento de um valor observado. Apenas um campo de tempo pode ser especifique. - Campos de entidade: os campos nos dados que identificam uma entidade observada específica. - Campos de feature: os campos nos dados que indicam valores observados específicos. É possível configurar múltiplos campos de feature, bem como definir um intervalo de valores para cada feature a fim de orientar o modelo para uma detecção de anomalias mais precisa.
Configuração do algoritmo	Algoritmos diferentes possuem itens de configuração distintos. Para obter mais informações sobre os itens de configuração de cada algoritmo, consulte Usar SQL para agregar dados de métricas para detecção em tempo real. Evento de inspeção Um evento de verificação de integridade inclui as seguintes informações: - Informações da entidade: identifica a fonte dos dados do resultado atual da verificação de integridade. - Informações de configuração: identifica a configuração da tarefa do resultado atual da verificação de integridade. - Pontuação de anomalia: o resultado quantitativo do modelo para a gravidade de uma anomalia. O valor varia de 0 a 1. Uma notificação de alerta é enviada quando a pontuação de anomalia é superior a 0,75. - Tipo de anomalia: o tipo inicial de anomalia determinado pelo modelo. Os cinco tipos são: pico (spike), desvio (shift), instabilidade (jitter), ausência (missing) e acima do limiar (over-threshold). A tabela a seguir descreve os cenários comuns de agendamento e execução de tarefas de verificação de integridade. Cenário
Descrição	Iniciar uma tarefa de verificação de integridade a partir de um ponto histórico no tempo Após criar uma tarefa de verificação de integridade, ela processa dados históricos com base nas regras da tarefa. O modelo de algoritmo consome os dados históricos rapidamente, realiza o treinamento do modelo e gradualmente alcança o momento atual. Após atingir o horário de criação da tarefa ou o horário de término do aprendizado do modelo, os eventos de verificação de integridade são gerados. Modificar a configuração de agendamento Após modifique a configuração de agendamento, a próxima instância é gerada com base na nova configuração. O modelo de algoritmo retém o tempo de consumo atual e continua verificando os novos dados. Reexecutar uma instância com falha
Se uma instância falhar devido a problemas como permissões insuficientes, banco de dados de source ou destino inexistente ou configuração inválida, o sistema reexecuta automaticamente. Caso o status permaneça como Starting, a configuração pode estar incorreta. O log de erros é gravado no Logstore internal-etl-log. Verifique a configuração e reinicie a tarefa. Após o agendamento e a execução bem-sucedidos, o sistema atualiza o status da instância para Succeeded ou Failed com base no resultado.	Para aproveitar ao máximo a verificação inteligente de integridade, siga estas recomendações:
Antes de configurar uma tarefa de verificação de integridade, compreenda o formato dos dados no Logstore, esclareça o significado dos campos e determine o intervalo de observação.	Para configurar os parâmetros do algoritmo com eficácia, entenda as variações dos dados de séries temporais dos objetos monitorados, incluindo estabilidade e periodicidade, e tenha uma expectativa preliminar sobre os padrões de anomalia. Alinhe a janela de tempo da tarefa de verificação de integridade a unidades de tempo completas, como segundos, minutos ou horas inteiros. Isso garante a pontualidade dos alertas de eventos de anomalia e a precisão da correlação de múltiplos eventos. O treinamento de modelos aprimora o aprendizado de anomalias e melhora a precisão dos alertas futuros. Ele oferece as seguintes vantagens: Quando a precisão da detecção de anomalias não atende às suas expectativas apenas com o recurso de verificação de integridade em tempo real, utilize tarefas de treinamento de modelos para aprimorá-la. Quando as anomalias detectadas por uma tarefa de verificação de integridade em tempo real diferem do que você considera anômalo, execute primeiro uma tarefa de treinamento de modelos para detectar adaptativamente os tipos de anomalia necessários.

Cenários de agendamento e execução

**Entrada de dados:** forneça os dados necessários para o serviço de treinamento de modelos, incluindo dados de métricas rotulados e não rotulados. Esses dados são armazenados no Simple Log Service e devem ser recuperados por meio de consultas SQL. Dados de métricas rotulados podem ser enviados diretamente ao serviço de algoritmo. Dados de métricas não rotulados precisam ser rotulados por simulação de injeção de anomalias antes de serem enviados ao serviço de algoritmo.

Serviço de algoritmo: este serviço é composto por duas partes principais — engenharia de features e um modelo supervisionado. No serviço de algoritmo, um modelo é treinado para cada entidade, e o ID da entidade é utilizado para identificar o modelo correspondente.	Armazenamento e visualização de resultados: após a conclusão de uma tarefa de treinamento de modelos, o sistema armazena o modelo treinado na nuvem. O sistema também salva os resultados de validação do conjunto de dados e os eventos da execução da tarefa como logs em um Logstore chamado internal-ml-log. Os resultados de visualização também podem ser consultados nos detalhes da tarefa.
Criar uma tarefa de predição: após a conclusão de uma tarefa de treinamento de modelos, você obtém o modelo treinado para cada entidade na tarefa. Em seguida, crie uma tarefa de predição para realizar detecção de anomalias em tempo real sobre dados de métricas futuros. Utilize a ferramenta de rotulagem do Simple Log Service para rotular os resultados, obter mais dados rotulados e treinar o modelo repetidamente para melhorar sua precisão.	O serviço de algoritmo é composto pelas três partes principais a seguir.
Conjunto de dados: um conjunto de dados é construído com base em um intervalo de tempo especificado e dividido em conjunto de treinamento e conjunto de validação.	O conjunto de treinamento deve cobrir um período superior a 12 dias, pois a tarefa de treinamento de modelos requer uma semana de dados históricos como pré-requisito para a engenharia de features. O conjunto de validação deve cobrir um período superior a 3 dias, pois são necessários três dias de dados para gerar um relatório de validação que explique melhor a adequação, a robustez e o desempenho do modelo.
Engenharia de features: inclui features de comparação periódica, features de desvio, features de tendência, features de janela e features temporais.	Modelo ensemble: um modelo ensemble é construído pela integração de múltiplos modelos baseados em árvore.

Recomendações de uso

The algorithm service consists of the following three main parts.

Dataset: A dataset is constructed based on a specified time range and is divided into a training set and a validation set.
The training set must cover a period of more than 12 days because the model training task requires one week of historical data as a prerequisite for feature engineering. The validation set must cover a period of more than 3 days because three days of data are required to generate a validation report that better explains the model's fit, robustness, and performance.
Feature engineering: This includes periodic comparison features, shift features, trend features, window features, and time features.

Treinamento de modelos

You can use model training to enhance anomaly learning and improve the accuracy of future anomaly alerts. Model training provides the following advantages.

If anomaly detection accuracy does not meet your expectations with the real-time health check feature alone, use model training tasks to improve it.
If the anomalies detected by a real-time health check task differ from what you consider anomalous, run a model training task first to adaptively detect the required anomaly types.

Processo básico

Data input: Provide the data required for the model training service. This includes labeled and unlabeled metric data. This data is stored in Simple Log Service and must be retrieved using SQL queries. Labeled metric data can be sent directly to the algorithm service. Unlabeled metric data must be labeled using anomaly injection simulation before it can be sent to the algorithm service.
Algorithm service: This service consists of two main parts: feature engineering and a supervised model. In the algorithm service, a model is trained for each entity. The entity ID is used to identify the corresponding model.
Result storage and visualization: After a model training task is complete, the system stores the trained model on the cloud. The system also saves the validation results of the dataset and events from the task run as logs in a Logstore named internal-ml-log. You can also view the visualization results in the task details.
Create a prediction task: After a model training task is complete, you obtain the model trained for each entity in the task. You can then create a prediction task to perform real-time anomaly detection on future metric data. Use the Simple Log Service labeling tool to label the results, obtain more labeled data, and repeatedly train the model to improve its accuracy.

Visão geral do serviço de algoritmo

The algorithm service consists of the following three main parts.

Dataset: A dataset is constructed based on a specified time range and is divided into a training set and a validation set.

The training set must cover a period of more than 12 days because the model training task requires one week of historical data as a prerequisite for feature engineering. The validation set must cover a period of more than 3 days because three days of data are required to generate a validation report that better explains the model's fit, robustness, and performance.
Feature engineering: This includes periodic comparison features, shift features, trend features, window features, and time features.
Ensemble model: An ensemble model is built by integrating multiple tree-based models.

Serviço de algoritmo: este serviço é composto por duas partes principais — engenharia de features e um modelo supervisionado. No serviço de algoritmo, um modelo é treinado para cada entidade, e o ID da entidade é utilizado para identificar o modelo correspondente.	Armazenamento e visualização de resultados: após a conclusão de uma tarefa de treinamento de modelos, o sistema armazena o modelo treinado na nuvem. O sistema também salva os resultados de validação do conjunto de dados e os eventos da execução da tarefa como logs em um Logstore chamado internal-ml-log. Os resultados de visualização também podem ser consultados nos detalhes da tarefa.
Criar uma tarefa de predição: após a conclusão de uma tarefa de treinamento de modelos, você obtém o modelo treinado para cada entidade na tarefa. Em seguida, crie uma tarefa de predição para realizar detecção de anomalias em tempo real sobre dados de métricas futuros. Utilize a ferramenta de rotulagem do Simple Log Service para rotular os resultados, obter mais dados rotulados e treinar o modelo repetidamente para melhorar sua precisão.	O serviço de algoritmo é composto pelas três partes principais a seguir.
Conjunto de dados: um conjunto de dados é construído com base em um intervalo de tempo especificado e dividido em conjunto de treinamento e conjunto de validação.	O conjunto de treinamento deve cobrir um período superior a 12 dias, pois a tarefa de treinamento de modelos requer uma semana de dados históricos como pré-requisito para a engenharia de features. O conjunto de validação deve cobrir um período superior a 3 dias, pois são necessários três dias de dados para gerar um relatório de validação que explique melhor a adequação, a robustez e o desempenho do modelo.
Engenharia de features: inclui features de comparação periódica, features de desvio, features de tendência, features de janela e features temporais.	Modelo ensemble: um modelo ensemble é construído pela integração de múltiplos modelos baseados em árvore.