Alerts envia notificações oportunas quando seu sistema está com problemas. Às vezes você não quer ver algumas notificações conhecidas. Você pode usar muting rules para parar de ser bombardeado por mensagens que não precisam da sua atenção.
Depois de identificar os elementos comuns em sua notificação indesejada, você pode definir regras de silenciamento que destinam especificamente esses elementos, enquanto permitem a passagem de outras notificações. Mesmo quando uma notificação é silenciada, ainda coleta dados sobre esses incidentes. As regras de silenciamento não interferem no processo de alerta e são aplicadas logo antes de uma notificação ser enviada.
Gerenciar regras de silenciamento
Uma condição de regra de muting é o conjunto de expressões individuais composto por atributos, operadores e valores que definem qual incidente será destinado ao muting.
Você pode criar, habilitar, desabilitar e gerenciar regras de silenciamento. Vá para one.newrelic.com > All capabilities > Alerts > Muting rules. Habilite ou desabilite regras de silenciamento a qualquer momento. Clique no ícone na linha de cada regra para editar e remover regras.
As regras podem ter um dos seguintes status:
- Active: O silenciamento está habilitado e ativo.
- Scheduled: o silenciamento está ativado, mas ainda não está ativo (há uma programação futura).
- Ended: o silenciamento está ativado, mas não está mais ativo (não há programação futura).
- Inactive: O silenciamento está desativado.
one.newrelic.com > All capabilities > Alerts > Muting rules: Você pode criar regras de muting complexas para destinar um conjunto pequeno ou grande de notificações indesejadas.
Crie uma regra de silenciamento
Dica
Antes de criar regras de silenciamento, você precisará criar políticas e condições que gerem notificação.
Para criar uma regra de silenciamento, vá para one.newrelic.com > All capabilities > Alerts > Muting rules e clique em + Add a rule. Insira um nome e uma descrição (opcional) para a regra de silenciamento e selecione a conta à qual a regra será aplicada.
A seguir, construa o filtro de incidentes. Você pode usar um subconjunto de atributo de evento de incidente. Escolha um atributo, um operador e um valor. Estes são os atributos: accountId
, conditionId
, conditionName
, conditionType
, entity.guid
, nrqlEventType
, nrqlQuery
, policyId
, policyName
, product
,runbookUrl
(como conditionRunbookUrl
), tags.<NAME>
e targetName
). Os valores são comparados com um dos seus atributos de incidente, como um ID de política de alertas ou um nome de condição. Clique em Add another condition se quiser incluir mais filtros.
one.newrelic.com > All capabilities > Alerts > Muting rules: Você pode criar regras de muting complexas para destinar um conjunto pequeno ou grande de notificações indesejadas.
Agende uma regra de silenciamento
Se necessário, você pode agendar suas regras de silenciamento.
Para fazer isso, selecione um horário de início e/ou término. Opcionalmente, você pode definir a regra de silenciamento para durar um dia inteiro.
Você também pode optar por selecionar um fuso horário para a programação da regra de silenciamento. O padrão é o fuso horário selecionado nas preferências do usuário.
one.newrelic.com > All capabilities > Alerts > Muting rules: opções flexíveis e poderosas para programar suas regras de silenciamento.
Você pode programar suas regras de silenciamento para ocorrerem diariamente, semanalmente ou mensalmente. Uma regra de silenciamento programada para repetição semanal inclui a opção de selecionar os dias da semana para recorrência. Se nenhum dia for selecionado, a recorrência semanal será repetida por padrão no dia da semana em que a regra de silenciamento está programada para iniciar.
Importante
As caixas de seleção do Repeat dia da semana substituem os campos de data Starts e Ends . Se você definir uma data de início e também escolher um dia da semana, suas regras de silenciamento serão aplicadas no primeiro dia após a data de início.
Você também pode especificar quando deseja que a recorrência termine selecionando uma data específica ou um determinado número de ocorrências.
Gerencie regras de silenciamento com NerdGraph
No NerdGraph, você pode usar as seguintes consultas e mutações com suas regras de silenciamento. Você pode ver o esquema com mais detalhes no API Explorer.
actor.account.alerts.mutingRule
: busque uma regra de silenciamento por id.actor.account.alerts.mutingRules
: busque uma lista de regras de silenciamento para uma conta.alertsMutingRuleCreate
: crie uma regra de silenciamento para uma conta.alertsMutingRuleUpdate:
Atualize uma regra de silenciamento por ID e ID da conta.alertsMutingRuleDelete:
Exclua uma regra de silenciamento por ID e ID da conta.
Você pode encontrar alguns exemplos de consultas e mutações nesta página.
Uma regra de silenciamento possui os seguintes campos e componentes:
Regra de silenciamento | Campos e componentes |
---|---|
| O identificador exclusivo da regra de silenciamento. |
| Um campo de texto para o nome amigável da regra de silenciamento. Isso é usado ao listar ou fazer referência a uma regra. Não exigimos que o nome seja exclusivo, mas é recomendado. |
| Este é um campo de texto opcional que descreve a regra de silenciamento. É uma maneira útil de fornecer mais contexto para sua regra de silenciamento. Esses dados são usados apenas para fins de exibição de gerenciamento. |
| O ID da conta da regra de silenciamento. Uma regra de silenciamento afetará apenas incidentes que ocorram em uma única conta. Para silenciar incidentes em várias contas, você precisará criar uma regra de silenciamento para cada conta separadamente. |
| O timestamp em que a regra de silenciamento foi criada (UTC). |
| O ID do usuário da pessoa que criou a regra de silenciamento. |
| O timestamp em que a regra de silenciamento foi modificada pela última vez (UTC). |
| O ID do usuário da pessoa que modificou a regra de silenciamento pela última vez. |
| Habilite ou desabilite a regra de silenciamento (Booleano). Ative e desative suas regras de silenciamento manualmente. |
| O conjunto de expressões individuais que definem qual incidente será o destino. Uma condição de regra de silenciamento inclui:
|
| O intervalo de tempo em que o
|
Como funcionam as regras de silenciamento
As regras de silenciamento são aplicadas no final do ciclo de vida do alerta padrão para suprimir ou silenciar a notificação. Eles não desativam as políticas ou condições existentes. Por exemplo, você pode silenciar a notificação durante interrupções conhecidas do sistema, como janelas de manutenção e implantação. Os incidentes de interrupção do sistema ainda serão identificados, mesmo que a notificação desses incidentes esteja silenciada.
Uma regra de silenciamento usa um conjunto de condições que correspondem ao atributo em um evento de incidente. As regras de silenciamento nos dizem como:
- Identifique incidentes individuais após serem criados, mas antes que um problema seja aberto.
- Substitua a condição padrão para indicar que eles devem ser "silenciados".
Atualmente, silenciar um incidente significa que o ciclo de vida normal do incidente de alerta será mantido, exceto que um problema que contenha apenas incidentes silenciados não enviará nenhuma notificação.
As regras de silenciamento são determinadas pelo primeiro evento que acionou uma notificação dentro de um problema. Ou seja, se o primeiro evento de notificação foi silenciado devido a um estado de silenciamento, o restante do problema também será silenciado.
As regras de silenciamento substituem incidentes específicos. Eles não desativam as políticas ou condições existentes. Isto permite silenciar incidentes de entidades específicas que possam estar cobertas por uma apólice ou condição que cubra um grande número de entidades. Isso também evita que você tenha que silenciar demais o monitoramento ao realizar manutenção em um subconjunto do sistema.
Comportamento de silenciamento
A tabela a seguir descreve como o ciclo de vida do incidente de alerta é afetado por incidentes silenciados:
SE | ENTÃO | |
---|---|---|
Event: O problema está ativado | ||
Um problema foi ativado devido a um incidente que não está silenciado | Será enviada uma notificação sobre este assunto. | |
Um problema foi ativado devido a um incidente que is desativou o som | A notificação deste problema não será enviada (silenciada). |
Comportamento de silenciamento com fluxo de trabalho
Um incidente acionado tem uma proporção de 1:1 com um problema, portanto, se um incidente for silenciado, o problema correspondente também será silenciado. fluxo de trabalho são desencadeados por problemas que podem ter um ou mais incidentes, portanto pode haver um cenário de incidentes silenciados e não silenciados combinados.
Cada problema tem um dos seguintes estados de silenciamento:
- Fully muted (
FULLY_MUTED
): um problema tem todos os seus incidentes abertos silenciados (valor padrão). - Partially muted (
PARTIALLY_MUTED
): um problema que tem pelo menos um incidente aberto que está silenciado e um incidente aberto que não está silenciado. - Not muted (
NOT_MUTED
): um problema que não tem nenhum incidente aberto e silenciado.
Para obter um guia passo a passo sobre como configurar seu fluxo de trabalho, confira um exemplo de demonstração abaixo (aprox. 2:17 minutos):
Ver incidentes e problemas silenciados
Ao visualizar um problema aberto ou fechado, o incidente e os problemas são marcados como Muted
. As seções a seguir mostram alguns desses incidentes e problemas silenciados e onde você pode encontrá-los.
Silenciar resultados facetados usando tags.
Para silenciar os resultados da consulta facetada, use o atributo tags.FACETED_ATTRIBUTE
, onde FACETED_ATTRIBUTE
representa o atributo que você executou uma consulta NRQL FACET
. Por exemplo: se sua condição do alerta NRQL inclui FACET host
em sua consulta, você pode destino esse atributo FACET
usando tags.host
.
A consulta de condição NRQL pode aceitar atributos de múltiplas facetas. Se você deseja filtrar atributo em seu evento ou série temporal métrica que foi agregada, você deve adicionar esses atributo à sua cláusula de consulta NRQL FACET
; por exemplo: FACET host, region, cluster
.
Para obter um exemplo de uso de tags.
, consulte Criar regra de silenciamento.
Operadores de subcondição
Esses são os operadores lógicos que você pode usar para comparar atributo ao adicionar regras de silenciamento. Se você é novo nas regras de silenciamento, veja estes exemplos.
Dica
Todos os valores do operador de subcondição diferenciam maiúsculas de minúsculas. Por exemplo, se você usar policyName STARTS_WITH 'PROD'
um nome de política que comece com 'Prod' não será selecionado.
EQUALS
: onde o valor fornecido é igual ao valor do atributo do incidente.DOES_NOT_EQUALS
: onde o valor fornecido não é igual ao valor do atributo do incidente.IN
: onde o valor do atributo do incidente está presente em uma lista de valores fornecidos (até 500).NOT_IN
: onde o valor do atributo do incidente não está presente em uma lista de valores fornecidos (até 500).CONTAINS
: onde a sequência de valores fornecida está presente no valor do atributo do incidente.DOES_NOT_CONTAINS
: onde a cadeia de valor fornecida não está presente no valor do atributo do incidente.ENDS_WITH
: onde o valor do atributo do incidente termina com a sequência de valores fornecida.NOT_ENDS_WITH
: onde o valor do atributo do incidente não termina com a sequência de valores fornecida.STARTS_WITH
: onde o valor do atributo do incidente começa com a sequência de valores fornecida.DOES_NOT_STARTS_WITH
: onde o valor do atributo do incidente não começa com a sequência de valores fornecida.IS_BLANK
: onde o valor do atributo do incidente está em branco. Nulo, string vazia, etc.IS_NOT_BLANK
: onde o valor do atributo do incidente não está em branco. Nulo, string vazia, etc.IS_ANY
: Caution: Uma condição com este operador silenciará all incidente na conta.
Exemplos de silenciamento
Para obter mais informações sobre como fazer solicitações ao NerdGraph, consulte a documentação do NerdGraph, incluindo tutoriais do GraphQL.