É possível configurar uma política de alertas para receber uma notificação sempre que uma mensagem específica aparecer nos registros incluídos. Por exemplo, se você quiser saber quando um registro de auditoria registrar uma mensagem de acesso a dados específica, poderá receber notificações quando a mensagem aparecer. Esses tipos de políticas de alertas são chamados de políticas de alertas com base em registros. Este documento descreve como fazer o seguinte: usando o console do Google Cloud e a API Cloud Monitoring:
- Criar e testar uma política de alertas baseada em registros.
- Editar uma política de alertas baseada em registros.
- Excluir uma política de alertas baseada em registros.
Antes de começar
Analise a comparação de alertas para determinar se as políticas de alertas com base em registros são adequadas aos dados nos seus registros. Exemplo:
As políticas de alertas com base em registros não operam em registros excluídos.
Não é possível usar políticas de 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 políticas de alertas com base em registros, sua função de Identity and Access Management precisa incluir as permissões descritas em Permissões para políticas de alertas com base em registros.
Criar uma política de alertas com base em registros usando a Análise de registros
É possível criar uma política de alertas com base em registros na página Explorador de registros no console do Google Cloud ou usando a API Monitoring. Esta seção descreve como criar políticas de alertas com base em registros usando o Explorador de registros. Para informações sobre a API Monitoring, consulte Criar uma política de alertas com base em registros usando a API Monitoring.
A interface do Explorador de registros orienta você nas seguintes etapas:
- Forneça um nome e uma descrição para a política de alertas.
- Escolha os registros para receber uma notificação.
- Definir o tempo entre as notificações.
- Defina o horário de encerramento 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 uma política de alertas 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 essa política de alertas, faça o seguinte:
-
No console do Google Cloud, acesse a página Análise de registros:
Acessar a Análise de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
Use o painel Consulta para criar uma consulta que corresponda à mensagem que você quer usar na política de alertas com base em registro.
Por exemplo, para encontrar entradas de registro com um nível de gravidade de
NOTICE
no registrosyslog
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}$"
Clique em Executar consulta para validar a consulta.
Na barra de ferramentas Resultados da consulta, expanda o menu Ações e selecione add_alert Criar alerta de registro.
No painel Detalhes do alerta, atribua um nome e uma descrição à política de alertas:
Insira um nome para a política de alertas no campo Nome da política de alertas. Por exemplo: "Endereço de rede: valor IPv4 inválido".
Selecione uma opção no menu Nível de gravidade da política. Os incidentes e as notificações mostram o nível de gravidade.
Insira uma descrição para a política de alertas. 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 da notificação:
Log-based alerting policy 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.
Para avançar para a próxima etapa, clique em Próxima.
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.
Clique em Próxima.
Selecione o tempo mínimo entre as notificações. Esse valor permite controlar o número de notificações recebidas do Monitoramento se essa condição for atendida várias vezes. Neste exemplo, selecione 5 minutos nas opções.
Opcional: selecione a duração do fechamento automático do incidente. Por padrão, a duração do fechamento automático de incidentes é definida como 7 dias.
Clique em Próxima.
Selecione um ou mais canais de notificação para sua política de alertas. 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 Criar e gerenciar canais de notificação.
Clique em Salvar.
Sua política de alertas baseada em registros está pronta para ser testada.
Testar o exemplo de política de alertas com base em registros
Para testar a política de alertas criada, grave manualmente uma entrada de registro que corresponda à consulta. Para gravar a entrada de registro, faça o seguinte:
Configure a entrada de registro a seguir mudando 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", }, }, }, ], }
Acesse a página de referência
logEntries.write
ou clique no botão a seguir:Copie a entrada de registro configurada anteriormente.
No painel Testar esta API, faça o seguinte:
Substitua o conteúdo do campo Corpo da solicitação no APIs Explorer pela entrada de registro que você copiou na etapa anterior.
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 HTTP200
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 a política de alertas das seguintes maneiras:
- O valor
logName
especifica o registrosyslog
que está 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. A entrada de registro atende à condição da política de alertas.
- Um incidente é aberto no Cloud Monitoring.
Você recebe uma notificação sobre o incidente. Se você tiver configurado um canal de notificação por e-mail, a notificação será semelhante à captura de tela abaixo:
Clique em Ver incidente no e-mail para ver o incidente no Cloud Monitoring. Para mais informações sobre incidentes, consulte Gerenciar incidentes para políticas de alertas com base em registros.
Outros cenários: alertas em registros de auditoria
O exemplo na seção intitulada Como criar uma política de alertas com base em registros é artificial. Normalmente, você não cria uma política de alertas e grava manualmente entradas de registro que atendam à condição da política de alertas. 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 políticas de alerta com base em registro, o que importa é a consulta usada para selecionar as entradas de registro.
As seções a seguir descrevem cenários realistas de políticas de alertas com base em registros com base no conteúdo dos registros de auditoria. Cada cenário ilustra como criar uma consulta que seleciona as entradas de registro de auditoria adequadas. Caso contrário, o procedimento para criar as políticas de alertas com base em registros é o mesmo mostrado em Como criar um alerta com base em registros.
Políticas de alerta que monitoram o acesso humano a 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, os usuários humanos nunca acessam esses segredos.
Se você ativou a geração de registros de auditoria para o Secret Manager, cada tentativa bem-sucedida de acessar um secret cria uma entrada de registro de auditoria. Cada entrada inclui o nome do secret e a identidade do autor da chamada.
É possível criar uma política de alertas com base em registros que notifique você quando um usuário humano acessar 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 de particular interesse:
@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étodoAccessSecretVersion
.authenticationInfo.principalEmail
: registra a conta que invocou o método no campomethodName
. O valor esperado nesse campo é uma conta de serviço que termina comgserviceaccount.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 uma política de alertas com base em registro para acesso humano a segredos, use esta consulta no painel Escolher registros a serem incluídos no alerta.
Políticas de alerta que monitoram eventos de descriptografia
A análise do exemplo anterior pode ser adaptada a outros serviços. Por exemplo, se você usar o Cloud Key Management Service para criptografar e descriptografar dados sensíveis, é possível usar os 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 uma política de alertas com base em registro para descriptografia realizada por um usuário humano, use esta consulta no painel Escolher registros a serem incluídos no alerta.
Gerenciar políticas de alertas com base em registros no Monitoring
É possível visualizar, editar e excluir políticas de alertas com base em registros usando o Console do Google Cloud para monitoramento ou a API Monitoring. Este documento descreve 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 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:
-
No console do Google Cloud, acesse a página Análise de registros:
Acessar a Análise de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
Na barra de ferramentas Resultados da consulta, expanda o menu Ações e selecione edit Gerenciar alertas de registro.
-
Para navegar no Monitoring:
-
No console do Google Cloud, acesse a página notifications Alertas:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.
Para conferir 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 para 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
.
A captura de tela a seguir lista as políticas de alerta ativadas e
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 more_vert Mais opções e selecione uma opção. Editar e copiar uma política é semelhante ao procedimento descrito em Criar uma política de alertas com base em registros. É 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 registro clicando no nome dela na lista de políticas.
Para excluir uma política, clique em Mais opções more_vert 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 uma política de alertas baseada em registros usando a API Monitoring
É possível criar políticas de alertas com base em registros usando a API Monitoring. Forneça as mesmas informações à API Monitoring que você fornece ao usar o Explorador de registros no Console do Google Cloud:
- Um nome e uma descrição para a política de alertas.
- Os registros para receber uma notificação.
- O tempo entre as notificações.
- O tempo para o 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 da política de alertas. 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 fechamento 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 políticas de 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 com base em métricas e em registros.
Gerenciar políticas de alertas por API descreve como criar, listar, editar e excluir política de alertas usando a API Monitoring.
Regras de notificação
Quando você cria uma política de alertas baseada em registros, a geração de registros cria
um objeto interno chamado regra de notificação. O registro
usa a regra de notificação para corresponder as entradas de registro
recebidas ao filtro da sua política de alertas e, em seguida, para criar uma notificação
quando uma entrada corresponde aos critérios do filtro. Você não interage diretamente
com a regra de notificação. No entanto, para criar uma política de alertas com base em registros,
é necessário ter a permissão logging.notificationRules.create
.
Projetar a política de alertas
A seção intitulada
Criar uma política de alertas com base em registros usando a Análise de registros
descreve uma maneira de criar uma política de alertas com base em registros.
Essa seção mostra como criar
uma política de alertas com base em registro que notifica você 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 a mesma política de alertas com base em registro usando a
API Monitoring, crie
um objeto AlertPolicy
semelhante a esta estrutura JSON:
{ "displayName": "Network address: invalid IPv4 value (API)", "documentation": { "content": "Log-based alerting policy 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" ] }
Esse código JSON especifica as mesmas informações que você especifica ao criar uma política de alertas com base em registros usando o Explorador 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. No Explorador 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 alerting policy 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 políticas de 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 políticas de 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 estruturaLogMatch
, e o valor do campofilter
é a consulta especificada no Explorador de registros. Como essa consulta é fornecida como o valor de um campo JSON, toda a consulta é exibida entre aspas, e as aspas na própria consulta precisam ter escape com o caractere\
(barra invertida).A estrutura
LogMatch
também inclui um campolabelExtractors
opcional. Você pode usar extratores de rótulos para criar rótulos personalizados com base nas entradas de registro e, em seguida, fazer referência a esses rótulos 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 chamadovm_identifier
, a condição anterior pode ser semelhante a esta:"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 aREGEXP_EXTRACT
para corresponder a substrings com base em expressões regulares. Essa é a mesma função usada para a extração de identificadores em métricas com base em registros. Consulte Criar um identificador para mais informações.Você pode usar esses rótulos extraídos na documentação da política de alertas para que eles sejam informados nas notificações. No campo
documentation
da política de alertas, você se refere aos rótulos extraídos usando uma variável do formulário${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 registrolabels."compute.googleapis.com/resource_id"
seja incluído nas notificações:"documentation": { "content": "Log-based alerting policy 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 nas políticas de alertas com base em registros
e é necessário especificar o campo combiner
com
o valor "OR"
. Não é possível criar políticas de alertas com base em registros
com várias condições.
Definir valores de notificação e fechamento automático
Uma política de alertas com base em registros especifica o tempo mínimo entre as notificações. No Explorador de registros, selecione um valor no menu Tempo entre as notificações.
Para representar esse valor em uma estrutura AlertPolicy
, especifique um
valor em segundos para o campo period
de uma estrutura
NotificationRateLimit
incorporada a uma estrutura
AlertStrategy
.
Da mesma forma, a política de alertas inclui o período para fechar incidentes automaticamente. O valor padrão é de 7 dias.
No Explorador 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 é de
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 autoclose
, 604800s
, é equivalente a 7 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 receber os IDs dos canais usando o Console do Google Cloud.
Enviar a 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
alertPolicies.create
usando a Google Cloud CLI,
chamando diretamente a API Monitoring.
Também é possível criar políticas de alerta 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:
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
.Transmita esse arquivo JSON para a CLI gcloud usando o seguinte comando:
gcloud alpha monitoring policies create --policy-from-file="alert-invalid-ip.json"
Se bem-sucedido, este comando retornará o nome do recurso da nova política. Por exemplo:
Created alerting 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:
Acesse a página de referência de
alertPolicies.create
.No painel Testar esta API, faça o seguinte:
No campo
name
, digite o seguinte valor:projects/PROJECT_ID
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.
Clique em Executar.
Se a chamada
alertPolicies.create
for bem-sucedida, você receberá um código de resposta HTTP200
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 desse 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: criar uma política de alertas quando uma entrada de registro contém uma string de texto
Este exemplo usa o console do Google Cloud para criar uma política de alertas, o Explorador de registros para conferir entradas de registro e a Google Cloud CLI para gravar uma entrada de registro:
-
No console do Google Cloud, acesse a página Análise de registros:
Acessar a Análise de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
No painel Consulta, insira a seguinte consulta depois de atualizar o valor do PROJECT_ID:
logName="projects/PROJECT_ID/logs/test-log" textPayload:"Oops"
A consulta procura no registro com o nome
test-log
entradas de registro que têm um campotextPayload
que contém a string "Ops".Na barra de ferramentas Resultados da consulta, expanda o menu Ações e selecione add_alert Criar alerta de registro. Em seguida, preencha a caixa de diálogo.
É necessário inserir 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 alerta.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 com o nome
test-log
. A entrada tem um nível de gravidade deERROR
e inclui um campotextPayload
.No Explorador de registros, clique em Executar consulta.
Depois que a tela for atualizada, você poderá conferir os detalhes da entrada de registro que você escreveu na etapa anterior.
-
No console do Google Cloud, acesse a página notifications Alertas:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.
O painel Incidents mostra o incidente e detalhes sobre a política de alertas.
Se um incidente não aparecer quando você abrir a página Alerts, aguarde alguns minutos e atualize a página.
Você não vai encontrar 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 conferir e mudar essas configurações editando a política.