Configurar alertas baseados em registros

É possível usar os alertas com base em registros para notificar você sempre que uma mensagem específica aparecer nos registros incluídos. Por exemplo, se você quiser saber quando um registro de auditoria registra uma determinada mensagem de acesso a dados, crie um alerta com base em registros que corresponda à mensagem e notifique você quando ela aparecer. Neste documento, descrevemos como usar o console do Google Cloud e a API Cloud Monitoring para:

  • Criar e testar um alerta com base em registro.
  • Editar um alerta com base em registro.
  • Excluir um alerta com base em registro.

Antes de começar

Analise a comparação de alertas para determinar se os alertas com base em registros são adequados aos dados nos seus registros. Exemplo:

  • Os alertas com base em registros não operam em registros excluídos.

  • Não é possível usar alertas com base em registros para derivar contagens dos seus registros. Para derivar contagens, é necessário usar métricas com base em registros.

Para criar e gerenciar alertas com base em registros, seu papel do Identity and Access Management precisa incluir as permissões descritas em Permissões para alertas com base em registros.

Criar um alerta com base em registros usando a Análise de registros

É possível criar alertas com base em registros na página Explorador de registros no Console do Google Cloud ou usando a API Cloud Monitoring. Nesta seção, descrevemos como criar alertas com base em registros usando a Análise de registros. Para criar alertas com base em registros usando a API Monitoring, consulte Criar um alerta com base em registros usando a API Monitoring.

A interface do Explorador de registros para criar e editar alertas com base em registros orienta você nas seguintes etapas:

  • Forneça um nome e uma descrição para o alerta.
  • Escolha os registros para receber uma notificação.
  • Definir o tempo entre as notificações.
  • Defina o horário do fechamento automático de incidentes.
  • Especifique quem você quer notificar.

Por exemplo, suponha que você tenha um aplicativo que grave uma entrada de registro syslog com gravidade NOTICE quando o aplicativo alterar um endereço de rede. As entradas de registro para alterações de endereço de rede incluem um payload JSON semelhante a este:

"jsonPayload": {
  "type": "Configuration change",
  "action": "Set network address",
  "result": "IP_ADDRESS",
}

Você quer criar um alerta com base em registro que notifique você quando um endereço IPv4 inválido aparecer no campo jsonPayload.result de entradas de registro em syslog com gravidade NOTICE.

Para criar o alerta com base em registro, faça o seguinte:

  1. No painel de navegação do console do Google Cloud, selecione Logging e clique em Análise de registros:

    Acessar a Análise de registros

  2. Use o painel Consulta para criar uma consulta que corresponda à mensagem que você quer usar no alerta com base em registro.

    Por exemplo, para encontrar entradas de registro com um nível de gravidade de NOTICE no registro syslog que têm endereços IP inválidos no payload JSON, use a seguinte consulta:

    log_id("syslog")
    severity = "NOTICE"
    jsonPayload.result !~ "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}$"
    

    Use Executar consulta no painel Resultados da consulta para validar a consulta.

  3. No cabeçalho do painel Resultados da consulta, clique em  Criar alerta. Quando a janela é estreita, a opção Create alert pode aparecer no menu Actions.

  4. No painel Detalhes do alerta, forneça um nome e uma descrição para o alerta:

    1. Digite um nome para o alerta no campo Nome da política de alertas. Por exemplo: "Endereço de rede: valor IPv4 inválido".

    2. Selecione uma opção no menu Nível de gravidade da política. Incidentes e notificações mostram o nível de gravidade.

    3. Digite uma descrição deste alerta. Você também pode incluir informações que possam ajudar o destinatário de uma notificação a diagnosticar o problema. A string a seguir resume o motivo do alerta:

      Log-based alert in project ${project} detected an invalid IPv4 value.
      

      Para informações sobre como formatar e adaptar o conteúdo desse campo, consulte Como usar o Markdown e variáveis em modelos de documentação.

  5. Para avançar para a próxima etapa, clique em Próxima.

  6. No painel Escolher registros a serem incluídos no alerta, verifique a consulta e os resultados clicando em Visualizar registros.

    Recomendamos criar a consulta no painel Consulta do Explorador de registros. A consulta que você criou no painel Consulta também é exibida nesse painel, por exemplo:

    log_id("syslog")
    severity = "NOTICE"
    jsonPayload.result !~ "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}$"
    

    É possível editar a consulta neste painel, se necessário. Se você editar a consulta, verifique os resultados clicando em Visualizar registros.

  7. Clique em Próxima.

  8. Selecione o tempo mínimo entre as notificações. Esse valor permite controlar o número de notificações recebidas desse alerta, se ele for acionado várias vezes. Neste exemplo, selecione 5 minutos nas opções.

  9. Opcional: selecione a duração do fechamento automático de incidentes. Por padrão, a duração do fechamento automático de incidentes é definida como 7 dias.

  10. Clique em Próxima.

  11. Selecione um ou mais canais de notificação para seu alerta. Neste exemplo, selecione um canal de notificação por e-mail.

    Se você já tiver um canal de notificação por e-mail configurado, selecione-o na lista. Caso contrário, clique em Gerenciar canais de notificação e adicione um canal de e-mail. Para saber mais sobre como criar canais de notificação, consulte Como gerenciar canais de notificação.

  12. Clique em Salvar.

Seu alerta com base em registros está pronto para ser testado.

Testar o exemplo de alerta com base em registro

Para testar o alerta criado, grave manualmente uma entrada de registro que corresponda à consulta. Para gravar a entrada de registro, faça o seguinte:

  1. Configure a entrada de registro a seguir alterando a variável PROJECT_ID para o ID do projeto:

    {
      "entries": [
      {
        "logName": "projects/PROJECT_ID/logs/syslog",
        "jsonPayload": {
          "type": "Configuration change",
          "action": "Set network address",
          "result": "999.027.405.1",
        },
        "severity": "NOTICE",
        "resource": {
          "type": "generic_task",
          "labels" : {
            "project_id": "PROJECT_ID",
            "location": "us-east1",
            "namespace": "fake-task-2",
            "job": "write-log-entry",
            "task_id": "11",
          },
        },
      },
      ],
    }
    
  2. Acesse a página de referência logEntries.write ou clique no botão a seguir:

    Acessar logEntries.write

  3. Copie a entrada de registro que você configurou anteriormente.

  4. No painel Testar esta API, faça o seguinte:

    1. Substitua o conteúdo do campo Corpo da solicitação no APIs Explorer pela entrada de registro que você copiou na etapa anterior.

    2. Clique em Executar. Se solicitado, siga o fluxo de autenticação.

      Se a chamada logEntries.write for bem-sucedida, você receberá um código de resposta HTTP 200 e um corpo de resposta vazio, {}. Para mais informações sobre o APIs Explorer, consulte Como usar o APIs Explorer na documentação do Monitoring. O APIs Explorer funciona da mesma maneira com a API Logging.

A entrada de registro corresponde ao filtro especificado para o alerta das seguintes maneiras:

  • O valor logName especifica o registro syslog no seu projeto do Google Cloud.
  • O valor severity dessa entrada de registro é NOTICE.
  • O valor jsonPayload.result não é um endereço IPv4 válido.

Depois que você grava a entrada de registro, ocorre a seguinte sequência:

  • A nova entrada de registro aparece no Explorador de registros e aciona o alerta.
  • Um incidente é aberto no Cloud Monitoring.
  • Você recebe uma notificação sobre o incidente. Se você configurou um canal de notificação por e-mail, a notificação vai ser parecida com a seguinte captura de tela:

    O exemplo de alerta com base em registro gera uma notificação por e-mail.

Clique em Ver incidente no e-mail para ver o incidente no Cloud Monitoring. Para saber mais sobre incidentes, consulte Como gerenciar incidentes para alertas com base em registros.

Outros cenários: alertas em registros de auditoria

O exemplo em Como criar um alerta baseado em registros é artificial. Normalmente, você não cria um alerta e grava manualmente as entradas de registro para acionar o alerta. As entradas de registro geralmente são gravadas por aplicativos ou outros serviços. Mas a origem das entradas de registro não importa. Para alertas com base em registros, o importante é a consulta usada para selecionar as entradas de registro.

Nas seções a seguir, descrevemos cenários realistas para alertas baseados em registros a partir do conteúdo dos registros de auditoria. Cada cenário ilustra como criar uma consulta que isola as entradas de registro de auditoria desejadas. Caso contrário, o procedimento para criar os alertas com base em registros será o mesmo mostrado em Como criar alertas com base em registros.

Alertas sobre acesso humano de secrets

Suponha que seu projeto armazene secrets no Secret Manager, e alguns deles foram criados apenas para contas de serviço. Exceto em circunstâncias incomuns, usuários humanos nunca acessam esses secrets.

Se você tiver ativado o registro de auditoria do Secret Manager, cada tentativa bem-sucedida de acessar um secret criará uma entrada de registro de auditoria. Cada entrada inclui o nome do secret e a identidade do autor da chamada.

É possível criar um alerta baseado em registros que notifica quando um usuário humano acessa um secret.

Veja a seguir o trecho de uma entrada de registro de auditoria escrita pelo Secret Manager. O trecho mostra os campos úteis para criar a consulta de um alerta com base em registro:

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "serviceName": "secretmanager.googleapis.com",
    "methodName": "google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion",
    "authenticationInfo": {
      "principalEmail": "my-svc-account@PROJECT_ID.iam.gserviceaccount.com",
      "serviceAccountDelegationInfo": [],
      "principalSubject": "serviceAccount:my-svc-account@PROJECT_ID.iam.gserviceaccount.com"
    },
    ...
  },
  ...
}

Os seguintes subcampos protoPayload são interessantes:

  • @type: indica que esta entrada de registro é uma entrada de registro de auditoria.
  • serviceName: registra o serviço que gravou a entrada de registro de auditoria. Use este campo para identificar entradas gravadas pelo Secret Manager.
  • methodName: identifica o método em que a entrada de registro de auditoria foi gravada. Use esse campo para identificar a ação que causou a criação dessa entrada. Neste exemplo, é o método AccessSecretVersion.
  • authenticationInfo.principalEmail: registra a conta que invocou o método no campo methodName. O valor esperado nesse campo é uma conta de serviço que termina com gserviceaccount.com.

Para encontrar entradas de registro para acesso secreto por um usuário humano, procure entradas de registro de auditoria gravadas pelo Secret Manager. Você quer encontrar as entradas de registro em que o método AccessSecretVersion foi invocado por um principal que não termina com gserviceaccount.com. A consulta a seguir isola essas entradas de registro:

protoPayload.@type = "type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.serviceName = "secretmanager.googleapis.com"
protoPayload.methodName =~ "AccessSecretVersion$"
protoPayload.authenticationInfo.principalEmail !~ "gserviceaccount.com$"

Para criar um alerta com base em registro para acesso humano aos secrets, use esta consulta no painel Escolher registros a serem incluídos no alerta.

Alertas sobre eventos de descriptografia

A análise do exemplo anterior pode ser adaptada a outros serviços. Por exemplo, se você usa o Cloud Key Management Service para criptografar e descriptografar dados confidenciais, é possível usar registros de auditoria gerados pelo Cloud KMS para detectar quando um usuário humano descriptografa um valor.

Para encontrar entradas de registro para descriptografia feita por um usuário humano, procure entradas de registro de auditoria gravadas pelo Cloud KMS. Você quer encontrar as entradas de registro em que o método Decrypt foi invocado por um principal que não termina com gserviceaccount.com, que indica uma conta de serviço. A consulta a seguir isola essas entradas de registro:

protoPayload.@type = "type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.serviceName = "cloudkms.googleapis.com"
protoPayload.methodName = "Decrypt"
protoPayload.authenticationInfo.principalEmail !~ "gserviceaccount.com$"

Para criar um alerta com base em registro para descriptografia realizado por um usuário humano, use essa consulta no painel Escolher registros a serem incluídos no alerta.

Gerenciar alertas com base em registros no Monitoring

É possível visualizar, editar e excluir alertas com base em registros usando o console do Google Cloud para o Monitoring ou a API Monitoring. Neste documento, descrevemos como gerenciar políticas de alertas usando o console do Google Cloud. Para informações sobre como usar a API Monitoring para gerenciar políticas de alertas, consulte Como gerenciar políticas de alertas por API.

Para ver uma lista de todas as políticas de alertas no seu projeto do Google Cloud, siga um dos procedimentos a seguir:

  • Para navegar no Logging:

    1. No painel de navegação do console do Google Cloud, selecione Logging e clique em Análise de registros:

      Acessar a Análise de registros

    2. No cabeçalho do painel Resultados da consulta, no menu Ações e selecione Gerenciar alertas.

  • Para navegar no Monitoring:

    1. No painel de navegação do console do Google Cloud, selecione Monitoramento e  Alertas:

      Acessar Alertas

    2. Para ver todas as políticas e ativar a filtragem, no painel Políticas, clique em Ver todas as políticas.

Essas duas ações levam você à página Políticas do Monitoring, que lista todas as políticas de alertas no seu projeto do Google Cloud.

Para restringir as políticas de alerta listadas, adicione filtros. Cada filtro é composto por um nome e um valor. Por exemplo, é possível definir o valor como uma correspondência exata de um nome de política ou uma correspondência parcial. As correspondências não diferenciam maiúsculas de minúsculas. Se você especificar vários filtros, eles serão unidos implicitamente por um AND lógico, a menos que você insira um filtro OR. Veja na captura de tela a seguir as políticas de alertas ativadas no momento criadas após 1º de janeiro de 2021:

Lista de políticas de alertas ativadas criadas após 1º de janeiro de 2021.

Na página Políticas, é possível editar, excluir, copiar, ativar ou desativar uma política de alertas:

  • Para editar ou copiar uma política, clique em Mais opções, e selecione a opção desejada. Editar e copiar uma política é semelhante ao procedimento descrito em Como criar um alerta com base em registro . É possível mudar e, em alguns casos, excluir os valores nos campos. Quando terminar, clique em Salvar.

    Também é possível editar uma política de alertas com base em registros clicando no nome dela na lista de políticas.

  • Para excluir uma política, clique em Mais opções e selecione Excluir. Na caixa de diálogo de confirmação, selecione Excluir.

  • Para ativar ou desativar a política de alertas, clique no botão localizado abaixo do título Ativado.

Criar um alerta com base em registros usando a API Monitoring

É possível criar alertas com base em registros usando a API Monitoring. Você fornece à API Monitoring as mesmas informações fornecidas ao usar a Análise de registros no console do Google Cloud:

  • Um nome e uma descrição para o alerta.
  • Os registros para receber uma notificação.
  • O tempo entre as notificações.
  • A hora do fechamento automático de incidentes.
  • Quem deve ser notificado.

Para criar políticas de alertas usando a API Monitoring, crie um objeto AlertPolicy e envie-o para o método alertPolicies.create.

Antes de usar a API Monitoring, é necessário ativar a API e ter autorização para usá-la. Para mais informações, consulte a seguinte documentação:

Estrutura de políticas de alertas

A API Monitoring representa uma política de alertas usando a estrutura AlertPolicy. A estrutura AlertPolicy tem várias estruturas incorporadas, incluindo uma descrição da condição que aciona o alerta. As políticas de alertas com base em registros diferem das políticas de alertas com base em métricas das seguintes maneiras:

  • Para descrever a condição, use o tipo de condição LogMatch. As políticas de alertas com base em métricas usam diferentes tipos de condição.
  • Uma política de alertas com base em registros pode ter apenas uma condição.
  • Especifique o tempo entre as notificações e o período de encerramento automático de incidentes incluindo uma estrutura AlertStrategy. As políticas de alertas com base em métricas não incluem um tempo entre as notificações.

Nesta seção, descrevemos como criar uma política de alertas com base em registros. Essas políticas são diferentes das políticas de alertas com base em métricas no tipo de condição usada. Para alertas com base em registros, o tipo de condição é LogMatch. Quando você usa a API Monitoring para gerenciar políticas de alertas, não há diferenças na forma como você lista, edita ou exclui políticas de métricas e com base em registros. O artigo Como gerenciar políticas de alertas por API descreve como criar, listar, editar e excluir política de alertas usando a API Monitoring.

Projetar a política de alertas

Na seção Criar um alerta com base em registros usando a Análise de registros, descrevemos uma maneira de criar esse tipo de alerta. Nesta seção, mostramos como criar um alerta baseado em registros que notifica quando uma entrada de registro syslog tem um nível de gravidade de NOTICE e um endereço IPv4 inválido no campo jsonPayload.result.

Para criar o mesmo alerta com base em registro usando a API Monitoring, crie um objeto AlertPolicy como esta estrutura JSON:

{
  "displayName": "Network address: invalid IPv4 value (API)",
  "documentation": {
    "content": "Log-based alert in project ${project} detected an invalid IPv4 value.",
    "mimeType": "text/markdown"
  },

  "conditions": [
    {
      "displayName": "Log match condition: invalid IP addr (API)",
      "conditionMatchedLog": {
        "filter": "log_id(\"syslog\") severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
      },
    }
  ],
  "combiner": "OR",

  "alertStrategy": {
    "notificationRateLimit": {
      "period": "300s"
    },
    "autoClose": "604800s",
  },

  "notificationChannels": [
    "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
  ]
}

Este código JSON especifica as mesmas informações definidas ao criar um alerta com base em registros usando a Análise de registros. As seções a seguir mapeiam o conteúdo dessa estrutura AlertPolicy para as etapas a serem seguidas ao usar o Explorador de registros para criar um alerta com base em registro. O valor do campo conditionMatchedLog é uma estrutura LogMatch.

Fornecer um nome e uma descrição

Uma política de alertas tem um nome de exibição e uma documentação associada fornecida com notificações para ajudar os participantes. Na Análise de registros, esses campos são chamados de Nome do alerta e Descrição do alerta. Esses valores são representados em uma estrutura AlertPolicy da seguinte maneira:

{
  "displayName": "Network address: invalid IPv4 value (API)",
  "documentation": {
    "content": "Log-based alert in project ${project} detected an invalid IPv4 value.",
    "mimeType": "text/markdown"
  },
  ...
}

Neste exemplo, o valor de displayName inclui "(API)" para que você possa distinguir entre as duas políticas de exemplo ao visualizar a lista de políticas no console do Google Cloud. A página Políticas do Monitoring lista políticas por nome de exibição e indica se a política é baseada em métricas ou registros. Para mais informações, consulte Gerenciar alertas com base em registros no Monitoring.

O campo documentation inclui, no subcampo content, a descrição que você pode fornecer ao usar o Explorador de registros. O segundo subcampo, mimeType, é obrigatório quando você especifica um valor para o campo documentation. O único valor válido é "text/markdown".

Escolher os registros para receber uma notificação

Uma política de alertas com base em registros tem uma única condição. No Explorador de registros, especifique a condição ao fornecer uma consulta no campo Definir entradas de registro para alertar. Esses valores são representados em uma estrutura AlertPolicy da seguinte maneira:

{ ...
  "conditions": [
    {
      "displayName": "Log match condition: invalid IP addr (API)",
      "conditionMatchedLog": {
        "filter": "log_id(\"syslog\" severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
      },
    }
  ],
  "combiner": "OR",
  ...
}

O campo conditions utiliza uma lista de estruturas Condition, mas uma política de alertas com base em registros precisa ter apenas uma condição. Cada Condition tem um nome de exibição e uma descrição da condição.

  • O valor do campo displayName é uma breve descrição da condição. Quando você usa o Explorador de registros para criar alertas com base em registros, o nome de exibição é sempre "Condição de correspondência de registro". Quando você usa a API Monitoring, é possível fornecer um nome de exibição mais preciso. É necessário informar um valor.

  • O valor do campo conditionMatchedLog é uma estrutura LogMatch, e o valor do campo filter é a consulta especificada na Análise de registros. Como essa consulta é fornecida como o valor de um campo JSON, toda a consulta aparece entre aspas, e todas as aspas na própria consulta precisam ser escapadas com o caractere \ (barra invertida).

  • A estrutura LogMatch também inclui um campo labelExtractors opcional. Use extratores de rótulos para compor rótulos personalizados das entradas de registro e, em seguida, referenciá-los nas notificações.

    Por exemplo, para extrair o valor do rótulo labels."compute.googleapis.com/resource_id" da entrada de registro em um rótulo chamado vm_identifier, a condição anterior pode ser assim:

    "conditions": [
      {
        "displayName": "Log match condition: invalid IP addr (API)",
        "conditionMatchedLog": {
          "filter": "log_id(\"syslog\" severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
          "labelExtractors": {
            "vm_identifier": "EXTRACT(labels.\"compute.googleapis.com/resource_id\")"
          }
        },
      }
    ],
    

    Use a função EXTRACT para corresponder ao valor inteiro ou use REGEXP_EXTRACT para corresponder substrings com base em expressões regulares. Essas são a mesma função usada para extração de rótulos em métricas com base em registros. Consulte Criar um rótulo para mais informações.

    É possível usar esses rótulos extraídos na documentação do alerta para que eles sejam informados nas notificações. No campo documentation da política de alertas, faça referência aos rótulos extraídos usando uma variável no formato ${log.extracted_label.KEY}, em que KEY é o nome que você deu ao rótulo extraído.

    O exemplo a seguir mostra como se referir à chave do rótulo extraído vm_identifier, para que o valor do rótulo de registro labels."compute.googleapis.com/resource_id" seja incluído nas notificações de alerta:

    "documentation": {
      "content": "Log-based alert in project ${project} detected an
       invalid IPv4 value on VM with ID ${log.extracted_label.vm_identifier}.",
      "mimeType": "text/markdown"
    },
    

O valor do campo combiner especifica como combinar os resultados de várias condições em políticas de alertas com base em métricas. Só é possível usar uma condição nos alertas com base em registros e é necessário especificar o campo combiner com o valor "OR". Não é possível criar alertas com base em registros com várias condições.

Definir valores de notificação e fechamento automático

Uma política de alertas para um alerta com base em registro especifica o tempo mínimo entre as notificações. No Explorador de registros, selecione um valor no menu Tempo entre as notificações. Você representa esse valor em uma estrutura AlertPolicy especificando um valor, em segundos, para o campo period de uma estrutura NotificationRateLimit incorporada em uma estrutura AlertStrategy.

Da mesma forma, a política de alertas inclui o período para encerramento automático de incidentes. O valor padrão é sete dias. Na Análise de registros, é possível selecionar um valor diferente no menu Duração do fechamento automático de incidentes. A opção corresponde ao campo autoclose na estrutura da API AlertStrategy. Ao usar esse campo, especifique o valor em segundos. O valor mínimo é 1.800 segundos ou 30 minutos.

{ ...
  "alertStrategy": {
    "notificationRateLimit": {
      "period": "300s"
    },
    "autoClose": "604800s",
  },
  ...
}

O valor do campo period neste exemplo, 300s, é equivalente a cinco minutos. O valor de autoclose, 604800s, equivale a sete dias.

Especificar quem você quer notificar

Uma política de alertas pode incluir uma lista de canais de notificação. No Explorador de registros, você seleciona canais em um menu. Esses valores são representados em uma estrutura AlertPolicy fornecendo uma lista de um ou mais nomes de recursos para objetos NotificationChannel configurados:

{ ...
  "notificationChannels": [
    "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
  ]
}

Quando você cria um canal de notificação, um nome de recurso é atribuído a ele. Para informações sobre como recuperar a lista de canais de notificação disponíveis, incluindo os nomes dos recursos, consulte Como recuperar canais na documentação do Monitoring. Não é possível conseguir os IDs do canal usando o console do Google Cloud.

Envie sua política de alertas para a API Monitoring

Para criar uma política de alertas usando a API Monitoring, crie um objeto AlertPolicy e envie-o para o método alertPolicies.create. É possível invocar o alertPolicies.create usando a Google Cloud CLI, chamando a API Monitoring diretamente.

Também é possível criar alertas com base em registros usando as bibliotecas de cliente para C#, Go, Java, Python e Ruby. Você também pode usar outras bibliotecas de cliente. A biblioteca da sua linguagem precisa incluir o tipo de condição LogMatch.

Para criar uma política de alertas usando a CLI gcloud, faça o seguinte:

  1. Coloque a representação JSON da sua política de alertas em um arquivo de texto. Por exemplo, em um arquivo chamado alert-invalid-ip.json.

  2. Transmita esse arquivo JSON para a CLI gcloud usando o seguinte comando:

    gcloud alpha monitoring policies create --policy-from-file="alert-invalid-ip.json"
    
  3. Se bem-sucedido, este comando retornará o nome do recurso da nova política. Por exemplo:

    Created alert policy [projects/PROJECT_ID/alertPolicies/POLICY_ID].
    

Para criar uma política de alertas chamando alertPolicies.create diretamente, use a ferramenta APIs Explorer da seguinte maneira:

  1. Acesse a página de referência de alertPolicies.create.

  2. No painel Testar esta API, faça o seguinte:

    1. No campo name, digite o seguinte valor:

      projects/PROJECT_ID
      
    2. Copie a representação JSON da política de alertas e substitua o conteúdo do campo Corpo da solicitação no APIs Explorer pela política de alertas copiada.

    3. Clique em Executar.

      Se a chamada alertPolicies.create for bem-sucedida, você receberá um código de resposta HTTP 200 e um corpo de resposta vazio, {}. Para mais informações sobre o APIs Explorer, consulte Como usar o APIs Explorer na documentação do Monitoring.

Para mais informações sobre como criar políticas de alertas usando a API Monitoring, consulte Como criar políticas. Os exemplos neste documento usam tipos de condição para políticas de alertas com base em métricas, mas os princípios são os mesmos.

Teste a política de alertas

Para testar sua nova política de alertas, use o mesmo procedimento descrito em Testar o alerta com base em registro de exemplo.

Exemplo: crie um alerta quando uma entrada de registro tiver uma string de texto

Este exemplo usa o console do Google Cloud para criar uma política de alertas, a Análise de registros para exibir entradas de registro e a Google Cloud CLI para gravar uma entrada de registro:

  1. No painel de navegação do console do Google Cloud, selecione Logging e clique em Análise de registros:

    Acessar a Análise de registros

  2. No painel Consulta, insira a seguinte consulta depois de atualizar o valor de PROJECT_ID:

    logName="projects/PROJECT_ID/logs/test-log"
    textPayload:"Oops"
    

    A consulta pesquisa o registro com o nome test-log em busca de entradas que tenham um campo textPayload que contenha a string "Ops".

  3. Clique em Criar alerta e preencha a caixa de diálogo. Insira um nome para a política, como Alert on Oops. A consulta que você inseriu na etapa anterior é incluída automaticamente na política de alertas.

  4. Para testar a política de alertas, abra o Cloud Shell e execute o seguinte comando:

    gcloud logging write test-log --severity=ERROR --payload-type=text 'This log entry contains Oops'
    

    O comando anterior grava uma entrada no registro chamada test-log. A entrada tem um nível de gravidade de ERROR e inclui um campo textPayload.

  5. Na Análise de registros, clique em Executar consulta.

    Após a atualização da tela, é possível visualizar os detalhes da entrada de registro que você escreveu na etapa anterior.

  6. Para ver o alerta, no painel de navegação, selecione Monitoramento e Alertas. O painel Incidentes exibe o incidente e os detalhes sobre a política de alertas.

    Se você não vir um incidente ao abrir a página Alertas, aguarde alguns minutos e atualize a página.

Você não verá outro incidente nem receberá outra notificação se repetir imediatamente o comando da Google Cloud CLI. As configurações da política de alertas especificam o período mínimo entre os incidentes. É possível visualizar e alterar essas configurações editando a política.