Monitorize os resultados das consultas SQL com uma política de alertas

Este documento explica como criar uma política de alerta para monitorizar os resultados de uma consulta que executa no Log Analytics. Estas consultas são escritas em SQL e têm de consultar uma visualização de registos. A política de alertas envia-lhe uma notificação quando o resultado da consulta satisfaz as condições que especificar. Por exemplo, pode configurar uma política de alertas para receber uma notificação quando, pelo menos, 25% das entradas de registo num determinado período tiverem uma gravidade de ERROR.

As políticas de alerta que cria na página Log Analytics são executadas num motor do BigQuery. Por conseguinte, os dados consultados têm de estar acessíveis através de um conjunto de dados do BigQuery associado. Por este motivo, estas consultas SQL só podem consultar vistas de registos. Não podem consultar visualizações de propriedade do Analytics.

Para obter informações gerais sobre o Log Analytics, consulte o artigo Consultar e analisar registos com o Log Analytics.

Como funcionam as políticas de alerta

Uma política de alertas descreve as circunstâncias em que quer receber alertas e como quer receber notificações sobre um incidente. Existem três abordagens diferentes que pode usar para receber notificações quando o conteúdo ou os padrões aparecem nos seus dados de registo:

  • Para analisar entradas de registo individuais de uma frase específica, crie uma política de alertas baseada em registos. Use estas políticas de alerta quando quiser receber notificações sobre aspetos como eventos relacionados com a segurança.

  • Para monitorizar eventos nos dados de entradas do registo, pode criar uma métrica baseada em registos e, em seguida, criar uma política de alertas para monitorizar a métrica. Estes tipos de políticas de alerta são eficazes quando quer monitorizar tendências nos dados de entradas de registo ao longo do tempo. No entanto, não são tão eficazes se esperar apenas alguns eventos.

  • Para monitorizar a análise agregada dos dados de entradas de registo, combine o Log Analytics com políticas de alerta. Neste cenário, atualiza um contentor de registos para usar o Log Analytics e cria um conjunto de dados do BigQuery associado para esse contentor de registos. Em seguida, usa o Log Analytics, que suporta consultas SQL, para consultar uma visualização de registos no contentor de registos. Por último, crie a política de alerta para monitorizar os resultados da consulta SQL. Este tipo de política de alerta é denominado política de alerta baseada em SQL.

As políticas de alerta baseadas em SQL são mais eficazes para avaliar valores exatos em várias entradas de registo. Se quiser avaliar entradas de registo individuais, crie uma política de alertas baseada em registos.

O resto deste documento descreve como usar políticas de alerta baseadas em SQL.

Componentes da política de alerta

Uma política de alerta baseada em SQL contém uma condição e um agendamento:

  • A condição contém a consulta, que é uma consulta SQL que consulta uma vista de registo. A condição também define as circunstâncias em que o resultado da consulta faz com que o Monitoring crie um incidente.

  • O agendamento define a frequência com que a política de alerta executa a respetiva consulta. A programação também define o tamanho do período de análise, que é um filtro que seleciona apenas as entradas do registo que foram recebidas desde a avaliação anterior da consulta. Por exemplo, se definir a agenda para 60 minutos, a consulta é executada a cada 60 minutos com um período de análise que seleciona os 60 minutos mais recentes de entradas do registo.

As políticas de alerta também contêm uma lista de canais de notificação. Quando a condição da política de alertas é cumprida, o Cloud Monitoring cria um incidente e, em seguida, envia notificações sobre o incidente através destes canais. Um incidente é um registo dos dados que fizeram com que a condição fosse cumprida, juntamente com outras informações relevantes. Estas informações podem ajudar a resolver os problemas que causaram o incidente. Pode ver o incidente através da Google Cloud consola.

Tipos de avaliação para políticas de alerta baseadas em SQL

As condições que monitorizam um resultado de consulta SQL suportam dois tipos de avaliação:

  • Limite de contagem de linhas: a condição é cumprida quando o número de linhas no resultado da consulta é superior, igual ou inferior a um valor limite.

    Por exemplo, suponhamos que quer receber uma notificação quando mais de 50 entradas de registo no período de análise tiverem uma gravidade superior a 200. Cria uma consulta que comunica entradas de registo cuja gravidade seja superior a 200. Em seguida, configura uma condição, seleciona o Limite de contagem de linhas e define o limite como 50.

  • Booleano: a condição é cumprida quando uma coluna booleana específica na tabela de resultados da consulta contém qualquer linha com um valor de true.

    Por exemplo, suponhamos que quer receber uma notificação quando mais de 25% das entradas de registo no período de análise tiverem uma gravidade de ERROR. Cria uma consulta que calcula a percentagem de entradas de registo cujo nível de gravidade é ERROR. Os resultados da consulta escrevem true na coluna notify quando essa percentagem excede 25%. Em seguida, cria uma condição, define o tipo como Booleano e configura a condição para monitorizar a coluna notify.

As políticas de alerta que monitorizam o resultado de uma consulta SQL têm de ter apenas uma condição.

Políticas de alerta e BigQuery

Quando uma política de alerta executa uma consulta SQL, essa consulta é executada através de slots do BigQuery reservados no projeto onde a política de alerta está definida. Google Cloud Para mais informações, consulte o artigo Trabalhe com reservas de horários.

Para que uma política de alertas use as ranhuras reservadas do BigQuery para consultar uma visualização de registos, o contentor de registos que aloja a visualização de registos tem de estar configurado para ter um conjunto de dados do BigQuery associado. Os conjuntos de dados associados permitem que o BigQuery leia os dados no contentor de registos e permitem-lhe executar funções do BigQuery nos dados devolvidos pela sua consulta SQL.

Entradas do registo avaliadas

Para que uma entrada de registo seja avaliada pela consulta SQL de uma política de alerta, têm de se verificar ambas as condições seguintes:

  • A data/hora de receção da entrada do registo, que regista quando a entrada do registo foi recebida pelo Cloud Logging, tem de estar dentro do período de análise da política de alertas.
  • A data/hora da entrada do registo, que regista quando a entrada do registo foi gerada, tem de estar dentro de 15 minutos do período de análise.

Por exemplo, a sua política de alertas baseada em SQL tem um período de análise de 60 minutos. O Log Analytics executa a consulta SQL da política de alerta às 13:30. Para ser incluída na consulta, uma entrada de registo tem de corresponder aos seguintes critérios:

  • A data/hora de receção tem de ser entre as 12:30 e as 13:30.
  • A data/hora tem de estar entre as 12:15 e as 13:45.

Quando executa uma consulta a partir da interface do Log Analytics, todas as entradas de registo no intervalo de tempo selecionado são avaliadas com base na data/hora da entrada de registo.

Período de análise e tempo de propagação de incidentes

Quando uma política de alertas está agendada para avaliar a respetiva condição, o Log Analytics atrasa a execução da consulta SQL em cinco minutos para dar tempo ao Cloud Logging de indexar as entradas de registo recebidas durante o período de análise. Por exemplo, se a política de alerta usar um período de análise que termina às 14:00, o Log Analytics não executa a consulta SQL até às 14:05.

Se a condição de alerta for cumprida após a execução da consulta, a propagação do incidente no sistema pode demorar até dois minutos adicionais.

Falhas de consultas

As consultas emitidas por políticas de alerta baseadas em SQL podem falhar por vários motivos, incluindo os seguintes:

  • A conta de serviço de monitorização já não existe ou já não tem as autorizações necessárias para ler os dados de registo que estão a ser consultados.

  • O tempo de execução da consulta excede os cinco minutos.

  • Ocorre um erro interno.

Uma consulta com falha gera uma entrada de registo que contém o ID da política de alerta e o estado de erro. Pode usar uma política de alertas baseada em registos para criar um alerta quando um erro é registado.

Antes de começar

Esta secção pressupõe que atualizou o contentor de registos para usar o Log Analytics e que pode consultar e ver os dados de registo através da página Log Analytics. Também pressupõe que já criou um conjunto de dados do BigQuery associado para o seu contentor de registos.

Antes de criar uma política de alertas baseada em SQL, conclua os seguintes passos:

  1. Para receber as autorizações de que precisa para criar e gerir políticas de alerta baseadas em SQL, peça ao seu administrador para lhe conceder as seguintes funções do IAM:

  2. Verifique se a conta de serviço de monitorização existe e se tem as seguintes funções:

    1. Agente do serviço de monitorização (roles/monitoring.notificationServiceAgent) no seu projeto.
    2. Visualizador de dados do BigQuery (roles/bigquery.dataViewer) no conjunto de dados associado.

    Se a conta de serviço de monitorização não existir, consulte o artigo Resolução de problemas: não existe conta de serviço de monitorização.

  3. Para permitir que as suas políticas de alerta baseadas em SQL sejam executadas em slots do BigQuery reservados, faça o seguinte:
    1. Configure slots do BigQuery reservados.
    2. Atribua espaços reservados ao seu Google Cloud projeto.
  4. Configure os canais de notificação que quer usar para receber notificações de incidentes. Para fins de redundância, recomendamos que crie vários tipos de canais de notificação. Para mais informações, consulte o artigo Crie e faça a gestão de canais de notificação.

Crie uma política de alerta baseada em SQL

Para criar uma política de alerta baseada em SQL, faça o seguinte:

Google Cloud consola

  1. Na Google Cloud consola, aceda à página Log Analytics:

    Aceda ao Log Analytics

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

  2. Na página Log Analytics, no editor de consultas, introduza uma consulta SQL para uma vista de registo.

    Para mais informações sobre como escrever consultas SQL para visualizações de registos, consulte o artigo Consultar uma visualização de registos.

  3. Na barra de ferramentas, clique em Executar no BigQuery.

    O Log Analytics executa a consulta no motor do BigQuery e apresenta os resultados na tabela Resultados.

    Se a opção Executar no BigQuery não for apresentada, clique em Selecionar motor de consulta e, de seguida, clique em BigQuery. O botão Executar consulta muda para Executar no BigQuery.

  4. Na tabela Resultados da página Log Analytics, clique em  Criar alerta.

    A página Log Analytics mostra a janela Criar política de alerta SQL, que mostra a sua consulta na secção Consulta SQL.

  5. Na secção Condição do alerta, configure a condição e o agendamento da sua política de alertas.

  6. Configure os detalhes do alerta da sua política de alertas.

    1. Adicione canais de notificação e configure o conteúdo das notificações, como uma linha de assunto personalizada.

    2. Opcional: adicione etiquetas de políticas de alertas e documentação.

    3. Clicar em Seguinte.

  7. Reveja a política de alertas e, de seguida, clique em Guardar para a criar.

Cloud Monitoring API

Use o método alertPolicies.create para criar políticas de alerta de forma programática. O Condition tipo da sua política de alertas tem de ser conditionSql, que é uma instância de SqlCondition. Este tipo de condição permite que as condições da sua política de alerta sejam definidas com SQL.

Para definir o horário, defina um valor periodicity para um dos campos minutes, hours ou days. Por exemplo, se quiser que a consulta seja executada a cada 12 horas, defina a periodicidade do campo hours como 12.

Para definir a condição, use os seguintes campos:

  • boolean_test: configura a política de alerta para que a respetiva condição seja cumprida quando uma linha de uma coluna booleana na tabela de resultados da consulta contém um valor verdadeiro.
  • row_count_test: configura a política de alertas para que a respetiva condição seja cumprida quando o número de linhas na tabela de resultados da consulta atinge um determinado limite.

Para ver uma lista completa de campos e definições, consulte SqlCondition na documentação da API Cloud Monitoring.

Para mais informações sobre a API Monitoring para políticas de alerta, consulte o artigo Gerir políticas de alerta por API.

Terraform

  1. Instale e configure o Terraform para o seu projeto. Para configurações do App Hub, selecione o projeto anfitrião ou o projeto de gestão do App Hub.

  2. No Cloud Shell, aceda ao diretório que contém a configuração do Terraform.

  3. Na configuração do Terraform, configure uma instância do recurso google_monitoring_alert_policy, incluindo condition_sql.

  4. No Cloud Shell, introduza terraform apply.

Para modificar a política de alertas, faça as edições e, de seguida, volte a aplicar a configuração do Terraform. Para mais informações, consulte o artigo Faça a gestão de políticas de alerta com o Terraform.

Para informações gerais sobre a utilização do Google Cloud com o Terraform, consulte Terraform com Google Cloud.

Limitações

  • Pode ter uma condição por política de alerta baseada em SQL.

  • As políticas de alerta baseadas em SQL não podem consultar uma vista de análise.

  • As consultas emitidas por políticas de alerta baseadas em SQL falham quando o respetivo tempo de execução excede cinco minutos.

  • Existe um atraso de até sete minutos, mais o tempo de execução da consulta, entre o momento em que uma consulta é agendada e o momento em que um incidente é criado.

Para ver uma lista completa dos limites associados às políticas de alerta, consulte os Limites de monitorização.

Preços

Para informações sobre preços, consulte os seguintes documentos:

O que se segue?