Neste documento, descrevemos como gerenciar notificações e incidentes adicionando rótulos definidos pelo usuário a uma política de alertas. Como os rótulos definidos pelo usuário são incluídos nas notificações, se você adicionar rótulos que indiquem a gravidade de um incidente, a notificação vai conter informações que podem ajudar você a priorizar os alertas para investigação.
Sobre os rótulos
Rótulos são pares de chave-valor associados a série temporal, políticas de alertas e incidentes. Há rótulos de métricas, de recursos e definidos pelo usuário. Os rótulos de métricas e recursos contêm informações específicas sobre a métrica que está sendo coletada ou o recurso em que a métrica é gravada. Em contrapartida, os rótulos definidos pelo usuário são aqueles criados por você e que registram informações específicas para suas necessidades.
Quando os dados de séries temporais são gravados, rótulos são anexados aos dados para registrar informações sobre esses dados. Por exemplo, os rótulos em uma série temporal podem identificar uma máquina virtual (VM), uma zona, um projeto do Google Cloud e um tipo de dispositivo.
É possível adicionar rótulos de usuários a políticas de alertas e incidentes:
Um rótulo em uma política de alertas tem um valor estático. É possível adicionar esses rótulos a uma política de alertas ao usar o console do Google Cloud ou a API Cloud Monitoring. Para mais informações, consulte os seguintes documentos:
As chaves de rótulos precisam começar com letra minúscula. As chaves e os valores de rótulos podem conter apenas letras minúsculas, dígitos, sublinhados e traços.
Um rótulo em um incidente pode ter seu valor definido dinamicamente. Ou seja, o valor dos dados da série temporal pode determinar o valor do rótulo. Por exemplo, acesse Criar níveis de gravidade dinâmicos usando a linguagem de consulta do Monitoring (MQL, na sigla em inglês).
É possível definir esses rótulos ao especificar a condição de uma política de alertas com o MQL.
Ver marcadores nas notificações
É possível visualizar os rótulos de uma política de alertas ou de um incidente na página de detalhes de um incidente, na página de detalhes de uma política de alertas e em algumas notificações:
Nas notificações por e-mail, os rótulos adicionados à política são listados na seção Rótulos de política. Já os rótulos adicionados a um incidente são listados na seção Rótulos de métrica.
Nas notificações do PagerDuty, Webhooks e Pub/Sub, os rótulos adicionados a uma política de alertas ou incidente são incluídos nos dados JSON. Os rótulos da política de alertas são listados no campo
policy_user_labels
da estrutura JSON:"policy_user_labels": { "severity": "critical", }
Os rótulos de incidentes são incluídos no campo
metric
da estrutura JSON:"metric": { "type" : "compute.googleapis.com/instance/cpu/utilization" "displayName": "CPU Utilization", "labels": { "instance_name": "some_instance_name", "severity": "critical" }, }
Como mostrado anteriormente, o campo
metric
lista um tipo de métrica, o nome de exibição da métrica, os rótulos de métrica e todos os rótulos definidos pelo usuário adicionados ao incidente.
Exemplo: criar níveis dinâmicos de gravidade usando rótulos e MQL
É possível usar o MQL para configurar um rótulo para que o valor dele
mude dinamicamente com base em dados de séries temporais. Por exemplo, você quer que os incidentes tenham um rótulo Criticality
cujo valor muda dependendo do valor da métrica de utilização da CPU monitorada:
fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
add[
Criticality:
if(val() >= 90 '%', 'CRITICAL',
if(val() >= 80 '%', 'WARNING',
if(val() >= 70 '%', 'INFO', 'GOOD')))
]
| condition val() >= 70 '%'
A figura a seguir ilustra como as políticas de alertas que usam consultas MQL processam os dados de série temporal que monitoram:
O gerenciador de políticas processa os dados de utilização da CPU e gera uma série temporal que indica quando a condição é acionada. No exemplo anterior, a condição é acionada quando a utilização da CPU é de pelo menos 70%. Para cada série temporal de entrada, o gerenciador de políticas pode gerar uma das quatro séries temporais:
Nome da série temporal de saída | Condição acionada | Descrição |
---|---|---|
"BOM" | Não | Essa série temporal tem os mesmos rótulos que a série temporal de entrada. Ela não tem um rótulo de gravidade. |
"CRÍTICO" | Sim | O uso da CPU é de pelo menos 90%. A série temporal de saída tem os mesmos rótulos que a série temporal "BOM", além de um rótulo de gravidade com o valor "CRÍTICO". |
"AVISO" | Sim | O uso da CPU está entre 80% e 90%. A série temporal de saída tem os mesmos rótulos que a série temporal "GOOD", além de um rótulo de gravidade com o valor "WARNING". |
"INFO" | Sim | O uso da CPU está entre 70% e 80%. A série temporal de saída tem os mesmos rótulos que a série temporal "GOOD", além de um rótulo de gravidade com o valor "INFO". |
Os dados da série temporal gerados pelo gerenciador de políticas são a entrada para o gerenciador de incidentes, que determina quando os incidentes são criados e encerrados.
Para determinar quando fechar um incidente, o gerenciador usa os valores dos campos duration
, evaluationMissingData
e autoClose
.
Práticas recomendadas
Para garantir que no máximo um incidente seja aberto por vez, ao criar rótulos com valores definidos dinamicamente, faça o seguinte:
No objeto
MetricThreshold
, substitua os valores padrão destes campos:- Campo
duration
: defina como um valor diferente de zero. - Campo
evaluationMissingData
: definido para que os incidentes sejam fechados quando os dados pararem de chegar. Ao usar a API Cloud Monitoring, defina esse campo comoEVALUATION_MISSING_DATA_INACTIVE
. Ao usar o console do Google Cloud, defina o campo como "Pontos de dados ausentes tratados como valores que não violam a condição da política".
- Campo
No objeto
AlertStrategy
, defina o campoautoClose
como o valor mínimo de 30 minutos. Ao usar a API Cloud Monitoring, defina esse campo como30m
.
Para mais informações, consulte Dados de métricas parciais.
Fluxo de incidentes
Suponha que as medições de utilização da CPU sejam inferiores a 70% quando a política de alerta for criada. A sequência a seguir ilustra como os incidentes são abertos e fechados:
Como as medições de utilização da CPU são inferiores a 70%, o gerenciador de políticas gera a série temporal "BOA" e nenhum incidente é aberto.
Em seguida, suponha que a utilização da CPU aumente para 93%. O gerenciador de políticas interrompe a geração de dados de série temporal "BOM" e começa a gerar dados para a série temporal "Crítica".
O gerenciador de incidentes vê uma nova série temporal que está acionando a condição, a série temporal "CRÍTICA", e cria um incidente. A notificação inclui o rótulo de gravidade com um valor
CRITICAL
.Suponha que o uso da CPU caia para 75%. O gerenciador de políticas interrompe a geração da série temporal "CRITICAL" e começa a gerar a série temporal "INFO".
O gerenciador de incidentes vê uma nova série temporal que está acionando a condição, a série temporal "INFO", e abre um incidente. A notificação inclui o rótulo de gravidade com um valor
INFO
.O gerenciador de incidentes vê que nenhum dado está chegando para a série temporal "CRITICAL" e que um incidente está aberto para essa série temporal. Como a política está configurada para fechar incidentes quando os dados param de chegar, o gerenciador de incidentes fecha o incidente associado à série temporal "CRÍTICO". Portanto, apenas o incidente cujo rótulo de gravidade tem um valor de
INFO
permanece aberto.Por fim, suponha que a utilização da CPU caia para 45%. Esse valor é menor que todos os limites. Por isso, o gerenciador de políticas para de gerar a série temporal "INFO" e começa a gerar a série temporal "GOOD".
O gerenciador de incidentes percebe que nenhum dado está chegando para a série temporal "INFO" e que um incidente está aberto para essa série temporal. Como a política está usando as configurações recomendadas, o incidente é encerrado.
Se você não usar o valor recomendado para o campo evaluationMissingData
,
quando os dados pararem de chegar, os incidentes abertos não serão fechados imediatamente.
O resultado é que podem aparecer vários incidentes abertos para a mesma série temporal de entrada. Para mais informações, consulte Dados de métricas parciais.
A seguir
- Criar políticas de alertas usando a API Monitoring
- Políticas de alertas com MQL
- Como processar dados de métricas parciais