Este documento descreve como os períodos de alinhamento e os intervalos de novo teste determinam quando uma condição é cumprida, como as políticas de alerta combinam várias condições e como as políticas de alerta substituem os pontos de dados em falta. Também descreve o número máximo de incidentes abertos para uma política, o número de notificações por incidente e o que causa atrasos nas notificações.
Este conteúdo não se aplica a políticas de alerta baseadas em registos. Para obter informações sobre as políticas de alerta baseadas em registos, consulte o artigo Monitorizar os seus registos.
Períodos de alinhamento e janelas de novo teste
O Cloud Monitoring avalia o período de alinhamento e a janela de novo teste quando determina se a condição de uma política de alertas foi cumprida.
Período de alinhamento
Antes de os dados de séries cronológicas serem monitorizados por uma política de alertas, têm de ser regularizados para que a política de alertas tenha dados com espaçamento regular para avaliar. O processo de regularização é denominado alinhamento.
O alinhamento envolve dois passos:
Dividir a série cronológica em intervalos de tempo regulares, também denominado agrupamento dos dados. O intervalo é o período de alinhamento.
Calcular um único valor para os pontos no período de alinhamento. Escolhe como esse único ponto é calculado. Pode somar todos os valores, calcular a média ou usar o máximo. A função que combina os pontos de dados é denominada alinhador. O resultado da combinação é o que se chama valor alinhado.
Para mais informações sobre o alinhamento, consulte o artigo Alinhamento: regularização dentro da série.
Por exemplo, quando o período de alinhamento é de cinco minutos, às 13:00, o período de alinhamento contém os exemplos recebidos entre as 12:55 e as 13:00. Às 13:01, o período de alinhamento desliza um minuto e contém os exemplos recebidos entre as 12:56 e as 13:01.
A monitorização configura um período de alinhamento da seguinte forma:
Google Cloud consola
Configura o período de alinhamento escolhendo um valor para os seguintes campos na página Condições de alerta:
- Janela dinâmica: especifica o intervalo de tempo a avaliar.
- Função de intervalo móvel: especifica a função matemática a executar no intervalo de pontos de dados.
Para mais informações sobre as funções disponíveis,
consulte Aligner na referência da API. Algumas das funções de alinhamento alinham os dados e convertem-nos de um tipo ou género de métrica para outro. Para uma explicação detalhada, consulte o artigo Tipos, tipos e conversões.
API
Configura o período de alinhamento definindo os campos aggregations.alignmentPeriod e aggregations.perSeriesAligner nas estruturas MetricThreshold e MetricAbsence.
Para mais informações sobre as funções disponíveis,
consulte Aligner na referência da API. Algumas das funções de alinhamento alinham os dados e convertem-nos de um tipo ou género de métrica para outro. Para uma explicação detalhada, consulte o artigo Tipos, tipos e conversões.
Para ilustrar o efeito do período de alinhamento numa condição numa política de alertas, considere uma condição de limite de métricas que está a monitorizar uma métrica com um período de amostragem de um minuto. Suponha que o período de alinhamento está definido para cinco minutos e que o alinhador está definido para sum. Além disso, suponha que a condição é cumprida quando o valor alinhado da série cronológica é superior a dois durante, pelo menos, três minutos e que a condição é avaliada a cada minuto.
Neste exemplo, a janela de novo teste, que é descrita na secção seguinte, é de
três minutos. A figura seguinte ilustra várias avaliações sequenciais da condição:
Cada linha na figura ilustra uma única avaliação da condição. São apresentados os dados de intervalos temporais. Os pontos no período de alinhamento são apresentados com pontos azuis. Os pontos mais antigos são pretos. Cada linha apresenta o valor alinhado e se este valor é superior ao limite de dois. Para a linha etiquetada como
start, o valor alinhado é calculado como um, que é inferior ao limite.
Na avaliação seguinte, a soma das amostras no período de alinhamento é dois.
Na terceira avaliação, a soma é três e, como este valor é superior ao limite, é iniciado um temporizador para o período de novo teste.
Períodos de novo teste
A condição de uma política de alerta tem uma janela de novo teste, o que impede que a condição seja cumprida devido a uma única medição ou previsão. Por exemplo, suponha que o período de novo teste de uma condição está definido como 15 minutos. A seguir, é descrito o comportamento da condição com base no respetivo tipo:
- As condições de limite de métricas são cumpridas quando, para uma única série cronológica, todas as medições alinhadas num intervalo de 15 minutos violam o limite.
- As condições de ausência de métricas são cumpridas quando não chegam dados para uma série cronológica num intervalo de 15 minutos.
- As condições de previsão são cumpridas quando todas as previsões produzidas durante um período de 15 minutos preveem que a série cronológica vai violar o limite no período de previsão.
Para políticas com uma condição, é aberto um incidente e são enviadas notificações quando a condição é cumprida. Estes incidentes permanecem abertos enquanto a condição continuar a ser cumprida.
Google Cloud consola
Configura o período de novo teste através do campo Período de novo teste no passo Configurar acionador de alerta.
API
Configura o período de novo teste definindo o campo denominado
duration nas estruturas MetricThreshold e
MetricAbsence.
A figura anterior ilustrou três avaliações de uma condição de limite de métrica. Às start + 2 minutes, o valor alinhado é superior ao limite;
no entanto, a condição não é cumprida porque o período de novo teste está definido para
três minutos. A figura seguinte ilustra os resultados das avaliações seguintes da condição:
Embora o valor alinhado seja superior ao limite no momento start + 2 minutes, a condição não é cumprida até que o valor alinhado seja superior ao limite durante três minutos. Esse evento ocorre às start + 5 minutes.
Uma condição repõe o respetivo período de novo teste sempre que uma medição ou uma previsão não satisfaz a condição. Este comportamento é ilustrado no exemplo seguinte:
Exemplo: esta política de alertas contém uma condição de limite de métricas que especifica um período de novo teste de cinco minutos.
Se a latência da resposta HTTP for superior a dois segundos
e se a latência for superior ao limite durante cinco minutos,
abra um incidente e envie um email à sua equipa de apoio técnico.A sequência seguinte ilustra como o período de novo teste afeta a avaliação da condição:
- A latência HTTP é inferior a dois segundos.
- Durante os próximos três minutos consecutivos, a latência HTTP é superior a dois segundos.
- Na medição seguinte, a latência é inferior a dois segundos, pelo que a condição repõe a janela de novo teste.
Durante os 5 minutos consecutivos seguintes, a latência HTTP é superior a 2 segundos, pelo que a condição é cumprida.
Uma vez que a política de alertas tem uma condição, o Monitoring envia notificações quando a condição é cumprida.
Defina a janela de novo teste de forma a ser suficientemente longa para minimizar os falsos positivos, mas suficientemente curta para verificar se os incidentes são abertos atempadamente.
Práticas recomendadas para definir o período de alinhamento e o período de novo teste
O período de alinhamento determina quantas amostras são combinadas com o alinhador:
O valor mínimo do período de alinhamento para um tipo de métrica é o período de amostragem desse tipo de métrica. Por exemplo, se o tipo de métrica for amostrado a cada 300 segundos, o período de alinhamento deve ser, pelo menos, de 300 segundos. No entanto, se quiser combinar 5 exemplos, defina o período de alinhamento como 5 * 300 segundos ou 1500 segundos.
O valor máximo do período de alinhamento é de 24 horas menos o atraso de carregamento do tipo de métrica. Por exemplo, se o atraso na carregamento de uma métrica for de 6 horas, o valor máximo do período de alinhamento é de 18 horas.
Use a janela de novo teste para especificar a capacidade de resposta do alerta. Por exemplo, se definir o período de novo teste como 20 minutos para uma condição de ausência de métricas, não pode haver dados durante 20 minutos antes de a condição ser cumprida. Para uma política de alertas mais reativa, defina o período de novo teste para um valor mais pequeno. Para condições de limite de métricas, para ter uma política de alertas mais reativa, defina o período de novo teste como zero. Um único valor alinhado faz com que estes tipos de condições sejam cumpridos.
As condições da política de alerta são avaliadas com uma frequência fixa. As escolhas que fizer para o período de alinhamento e a janela de novo teste não determinam a frequência com que a condição é avaliada.
Políticas com várias condições
Uma política de alerta pode conter até 6 condições.
Se estiver a usar a API Cloud Monitoring ou se a sua política de alertas tiver várias condições, tem de especificar quando é aberto um incidente. Para configurar como várias condições são combinadas, faça uma das seguintes ações:
Google Cloud consola
Configura as opções do combinador no passo Acionador de várias condições.
API
Configura as opções do combinador com o campo combiner da estrutura AlertPolicy.
Esta tabela lista as definições na Google Cloud consola, o valor equivalente na API Cloud Monitoring e uma descrição de cada definição:
| Valor dos acionadores de políticas daGoogle Cloud consola |
Cloud Monitoring API combiner value |
Significado |
|---|---|---|
| Qualquer condição é cumprida | OR |
É aberto um incidente se qualquer recurso fizer com que qualquer uma das condições seja cumprida. |
| Todas as condições são cumpridas , mesmo para diferentes recursos para cada condição (predefinição) |
AND |
É aberto um incidente para cada condição que é cumprida quando todas as condições são cumpridas, mesmo que um recurso diferente faça com que essas condições sejam cumpridas. |
| Todas as condições são cumpridas | AND_WITH_MATCHING_RESOURCE |
É aberto um incidente para cada condição que é cumprida quando todas as condições são cumpridas, apenas se o mesmo recurso fizer com que cada condição seja cumprida. Esta definição é a combinação de escolha mais rigorosa. |
Neste contexto, o termo cumprido
significa que a configuração da condição é avaliada como verdadeira. Por exemplo, se a configuração for Any time series is greater than 10 for 5 minutes, quando esta declaração for avaliada como true, a condição é cumprida.
Exemplo
Considere um Google Cloud projeto que contém duas instâncias de VM, vm1 e vm2. Suponha também que cria uma política de alerta com 2 condições:
- A condição denominada
CPU usage is too highmonitoriza a utilização da CPU das instâncias. Esta condição é cumprida quando a utilização da CPU de qualquer instância é superior a 100 ms/s durante 1 minuto. - A condição denominada
Excessive utilizationmonitoriza a utilização da CPU das instâncias. Esta condição é cumprida quando a utilização da CPU de qualquer instância é superior a 60% durante 1 minuto.
Inicialmente, suponha que ambas as condições são avaliadas como falsas.
Em seguida, suponha que a utilização da CPU da vm1 excede 100 ms/s durante 1 minuto. Uma vez que a utilização da CPU é superior ao limite durante um minuto, a condição CPU usage is too high é cumprida. Se as condições forem combinadas com Qualquer condição é cumprida, é criado um incidente porque uma condição é cumprida. Se as condições forem combinadas com
Todas as condições são cumpridas ou
Todas as condições são cumpridas, mesmo para recursos diferentes para cada condição,
não é criado nenhum incidente. Estas opções de combinação requerem que ambas as condições sejam cumpridas.
Em seguida, suponha que a utilização da CPU da vm1 permanece superior a 100 ms/s e que a utilização da CPU da vm2 excede 60% durante 1 minuto. O resultado é que ambas as condições são cumpridas. A seguinte descrição indica o que ocorre com base na forma como as condições são combinadas:
Qualquer condição é cumprida: é criado um incidente quando um recurso faz com que uma condição seja cumprida. Neste exemplo, vm2 faz com que a condição
Excessive utilizationseja cumprida.Se vm2 fizer com que a condição
CPU usage is too highseja cumprida, isso também resulta na criação de um incidente. É criado um incidente porque vm1 e vm2 que fazem com que a condiçãoCPU usage is too highseja cumprida são eventos distintos.Todas as condições são cumpridas, mesmo para recursos diferentes para cada condição: É criado um incidente porque ambas as condições são cumpridas.
Todas as condições são cumpridas: não é criado nenhum incidente porque este combinador requer que o mesmo recurso faça com que todas as condições sejam cumpridas. Neste exemplo, não é criado nenhum incidente porque vm1 faz com que a condição
CPU usage is too highseja cumprida, enquanto vm2 faz com que a condiçãoExcessive utilizationseja cumprida.
Dados de métricas parciais
Quando os dados de séries cronológicas deixam de chegar ou quando os dados estão atrasados, o Monitoring classifica os dados como em falta. Os dados em falta podem impedir o encerramento de incidentes. Os atrasos na receção de dados de fornecedores de nuvem de terceiros podem atingir os 30 minutos, sendo os atrasos de 5 a 15 minutos os mais comuns. Um atraso prolongado, superior ao período de novo teste, pode fazer com que as condições entrem num estado "desconhecido". Quando os dados chegam finalmente, o Monitoring pode ter perdido parte do histórico recente das condições. A inspeção posterior dos dados de séries cronológicas pode não revelar este problema porque não existem provas de atrasos assim que os dados chegam.
Google Cloud consola
Pode configurar a forma como a monitorização avalia uma condição de limite de métricas quando os dados deixam de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, quer que a monitorização deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados deixam de chegar e não existe nenhum incidente aberto, quer que seja aberto um incidente? Por último, durante quanto tempo deve um incidente permanecer aberto depois de os dados deixarem de ser recebidos?
Existem dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métricas quando os dados deixam de chegar:
Para configurar a forma como a monitorização determina o valor de substituição para os dados em falta, use o campo Avaliação de dados em falta, que define no passo Acionador de condição. Este campo está desativado quando a janela de novo teste está definida como Sem novo teste.
A janela de novo teste é o campo denominado duração na API Cloud Monitoring.
Para configurar o tempo que a monitorização aguarda antes de fechar um incidente aberto após a interrupção da receção de dados, use o campo Duração do encerramento automático de incidentes. Define a duração do fecho automático no passo Notificação. A duração do encerramento automático predefinida é de sete dias.
Segue-se uma descrição das diferentes opções para o campo de dados em falta:
| Google Cloud console Campo "Avaliação de dados em falta" |
Resumo | Detalhes |
|---|---|---|
| Dados em falta vazios | Os incidentes abertos permanecem abertos. Não são abertos novos incidentes. |
Para as condições que são cumpridas, a condição continua a ser cumprida quando os dados deixam de chegar. Se existir um incidente aberto para esta condição, o incidente permanece aberto. Quando um incidente está aberto e não chegam dados, o temporizador de encerramento automático começa após um atraso de, pelo menos, 15 minutos. Se o temporizador expirar, o incidente é encerrado. Para as condições que não são cumpridas, a condição continua a não ser cumprida quando os dados deixam de chegar. |
| Os pontos de dados em falta são tratados como valores que violam a condição da política | Os incidentes abertos permanecem abertos. Podem ser abertos novos incidentes. |
Para as condições que são cumpridas, a condição continua a ser cumprida quando os dados deixam de chegar. Se existir um incidente aberto para esta condição, o incidente permanece aberto. Quando um incidente está aberto e não chegam dados durante o período de encerramento automático mais 24 horas, o incidente é encerrado. Para as condições que não são cumpridas, esta definição faz com que a condição de limite métrico se comporte como um |
| Os pontos de dados em falta são tratados como valores que não violam a condição da política | Os incidentes abertos são fechados. Não são abertos novos incidentes. |
Para as condições que são satisfeitas, a condição deixa de ser satisfeita quando os dados deixam de chegar. Se existir um incidente aberto para esta condição, o incidente é fechado. Para as condições que não são cumpridas, a condição continua a não ser cumprida quando os dados deixam de chegar. |
API
Pode configurar a forma como a monitorização avalia uma condição de limite de métricas quando os dados deixam de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, quer que a monitorização deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados deixam de chegar e não existe nenhum incidente aberto, quer que seja aberto um incidente? Por último, durante quanto tempo deve um incidente permanecer aberto depois de os dados deixarem de ser recebidos?
Existem dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métricas quando os dados deixam de chegar:
Para configurar a forma como a monitorização determina o valor de substituição dos dados em falta, use o campo
evaluationMissingDatada estruturaMetricThreshold. Este campo é ignorado quando o campodurationé zero.Para configurar o tempo que a monitorização espera antes de fechar um incidente aberto após a interrupção da receção de dados, use o campo
autoClosena estruturaAlertStrategy.
Segue-se uma descrição das diferentes opções para o campo de dados em falta:
| API Campo evaluationMissingData |
Resumo | Detalhes |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Os incidentes abertos permanecem abertos. Não são abertos novos incidentes. |
Para as condições que são cumpridas, a condição continua a ser cumprida quando os dados deixam de chegar. Se um incidente estiver aberto para esta condição, o incidente permanece aberto. Quando um incidente está aberto e não chegam dados, o temporizador de encerramento automático começa após um atraso de, pelo menos, 15 minutos. Se o temporizador expirar, o incidente é encerrado. Para as condições que não são cumpridas, a condição continua a não ser cumprida quando os dados deixam de chegar. |
EVALUATION_MISSING_DATA_ACTIVE |
Os incidentes abertos permanecem abertos. Podem ser abertos novos incidentes. |
Para as condições que são cumpridas, a condição continua a ser cumprida quando os dados deixam de chegar. Se um incidente estiver aberto para esta condição, o incidente permanece aberto. Quando um incidente está aberto e não chegam dados durante o período de encerramento automático mais 24 horas, o incidente é encerrado. Para as condições que não são cumpridas, esta definição faz com que a condição de limite métrico se comporte como um |
EVALUATION_MISSING_DATA_INACTIVE |
Os incidentes abertos são fechados. Não são abertos novos incidentes. |
Para as condições que são satisfeitas, a condição deixa de ser satisfeita quando os dados deixam de chegar. Se existir um incidente aberto para esta condição, o incidente é fechado. Para as condições que não são cumpridas, a condição continua a não ser cumprida quando os dados deixam de chegar. |
Pode minimizar os problemas devido a dados em falta através de qualquer uma das seguintes ações:
- Contacte o seu fornecedor de nuvem externo para identificar formas de reduzir a latência da recolha de métricas.
- Use períodos de novo teste mais longos nas suas condições. A utilização de um período de novo teste mais longo tem a desvantagem de tornar as suas políticas de alerta menos reativas.
Escolha métricas com um atraso de recolha inferior:
- Monitorizar métricas do agente de monitorização, especialmente quando o agente está a ser executado em instâncias de VM em clouds de terceiros.
- Métricas personalizadas, quando escreve os respetivos dados diretamente no Monitoring.
- Métricas baseadas em registos, se a recolha de entradas de registo não estiver atrasada.
Para mais informações, consulte os artigos Vista geral do agente de monitorização, Vista geral das métricas definidas pelo utilizador e Métricas baseadas em registos.
Quando a monitorização envia notificações e cria incidentes
O Cloud Monitoring envia uma notificação quando uma série cronológica faz com que uma condição seja cumprida. A notificação é enviada para todos os canais de notificação. Não pode restringir uma notificação a um canal específico ou a um subconjunto dos canais da sua política.
Se configurar notificações repetidas, a mesma notificação é reenviada para canais de notificação específicos para a sua política de alertas.
Pode receber várias notificações únicas relacionadas com uma política de alertas quando qualquer uma das seguintes afirmações for verdadeira:
Uma condição está a monitorizar várias séries cronológicas.
Uma política contém várias condições. Neste caso, as notificações que recebe dependem do valor do acionador de várias condições da política de alertas:
Todas as condições são cumpridas: quando todas as condições são cumpridas, para cada série cronológica que resulta no cumprimento de uma condição, a política de alertas envia uma notificação e cria um incidente.
Não pode configurar o Cloud Monitoring para criar apenas um incidente e enviar apenas uma notificação quando a política de alerta contém várias condições.
Qualquer condição é cumprida: a política de alerta envia uma notificação quando um intervalo temporal faz com que a condição seja cumprida.
Para mais informações, consulte o artigo Políticas com várias condições.
As políticas de alerta criadas através da API Cloud Monitoring também enviam uma notificação quando a condição é cumprida e quando deixa de ser cumprida. As políticas de alerta criadas através da consola Google Cloud não enviam uma notificação quando a condição deixa de ser cumprida, a menos que tenha ativado esse comportamento.
Quando a monitorização não envia notificações nem cria incidentes
Nas seguintes situações, a monitorização não cria incidentes nem envia notificações quando as condições de uma política de alerta são cumpridas:
- A política de alertas está desativada.
- A política de alerta está suspensa.
- A monitorização atingiu o limite máximo de incidentes abertos.
Políticas de alerta desativadas
A monitorização não envia incidentes de criação nem notificações para políticas de alerta desativadas. No entanto, o Monitoring continua a avaliar as condições de uma política de alerta desativada.
Quando ativa uma política desativada, a monitorização avalia os valores de todas as condições no período de novo teste mais recente. O período de novo teste mais recente pode incluir dados recolhidos antes, durante e depois de a política ter sido ativada. As condições de uma política desativada podem ser cumpridas imediatamente após a retoma da política, mesmo com grandes janelas de novo teste.
Por exemplo, suponhamos que tem uma política de alertas que monitoriza um processo específico e que desativa esta política. Na semana seguinte, o processo é interrompido e, como a política de alertas está desativada, não recebe nenhuma notificação. Se reiniciar o processo e ativar a política de alerta imediatamente, o Monitoring reconhece que o processo não está em funcionamento nos últimos cinco minutos e abre um incidente.
Os incidentes relacionados com uma política de alertas desativada permanecem abertos até a duração de encerramento automático da política expirar.
Políticas de alerta suspensas
A monitorização não envia notificações nem cria incidentes para uma política de alerta que esteja adiada. Recomendamos que adie as políticas de alerta quando quiser impedir que uma política de alerta envie notificações apenas durante intervalos curtos. Por exemplo, antes de realizar a manutenção numa máquina virtual (VM), pode criar uma suspensão temporária e adicioná-la aos critérios de suspensão temporária das políticas de alerta que monitorizam a instância.
Quando adia uma política de alerta, o Monitoring fecha todos os incidentes abertos relacionados com a política. A monitorização pode abrir novos incidentes após o adiamento expirar. Para mais informações, consulte o artigo Adie notificações e incidentes.
Limites de notificações e incidentes abertos
Uma política de alerta pode aplicar-se a muitos recursos e um problema que afete todos os recursos pode fazer com que a política de alerta abra incidentes para cada recurso. É aberto um incidente para cada série cronológica que resulte no cumprimento de uma condição.
Para evitar a sobrecarga do sistema, o número de incidentes que uma única política pode abrir em simultâneo está limitado a 1000.
Por exemplo, considere uma política que se aplica a 2000 instâncias do Compute Engine e cada instância faz com que as condições de alerta sejam cumpridas. A monitorização limita o número de incidentes abertos a 1000. Quaisquer condições restantes que sejam cumpridas são ignoradas até que alguns dos incidentes abertos para essa política sejam resolvidos.
Como resultado deste limite, um único canal de notificação pode receber até 1000 notificações em simultâneo. Se a sua política de alertas tiver vários canais de notificação, este limite aplica-se a cada canal de notificação de forma independente.
Latência
Latência refere-se ao atraso entre o momento em que a monitorização faz uma amostragem de uma métrica e o momento em que o ponto de dados da métrica fica visível como dados de intervalos temporais. A latência afeta o momento em que as notificações são enviadas. Por exemplo, se uma métrica monitorizada tiver uma latência de até 180 segundos, a monitorização não cria um incidente durante um período de até 180 segundos após a condição da política de alerta ser avaliada como verdadeira. Para mais informações, consulte o artigo Latência dos dados de métricas.
Os seguintes eventos e definições contribuem para a latência:
Atraso na recolha de métricas: o tempo que a monitorização precisa para recolher valores de métricas. Para os Google Cloud valores, a maioria das métricas não fica visível durante 60 segundos após a recolha. No entanto, o atraso depende da métrica. Os cálculos da política de alertas têm um atraso adicional de até 5 minutos e 30 segundos. Para as métricas do AWS CloudWatch, o atraso de visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, este pode ser uma média de dois minutos (a partir do final do período de novo teste).
Período de novo teste: o período configurado para a condição. As condições só são cumpridas quando uma condição é verdadeira durante todo o período de novo teste. Por exemplo, uma definição de período de novo teste de cinco minutos provoca atrasos na notificação de, pelo menos, cinco minutos a partir do momento em que o evento ocorre pela primeira vez.
Tempo para a notificação chegar: os canais de notificação, como o email e o SMS, podem sofrer latências de rede ou outras (não relacionadas com o que está a ser entregue), por vezes, aproximando-se de minutos. Em alguns canais, como SMS e Slack, não existe garantia de que as mensagens sejam entregues.
O que se segue?
Para informações sobre como criar uma política de alertas, consulte os seguintes documentos:
Para ver uma variedade de políticas de alerta, consulte as políticas de exemplo.