Alerta envia notificações oportunas quando seu sistema está com problemas. Às vezes há notificações que você sabe que não precisa ver. Você pode usar muting rules para evitar ser bombardeado por mensagens que não precisam de 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, alertasainda 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, ativar, desativar e gerenciar regras de silenciamento. Vá para one.newrelic.com > All capabilities > Alerts & AI > Muting rules. Ative ou desative 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.

Crie uma regra de silenciamento

Para criar uma regra de silenciamento, vá para one.newrelic.com > All capabilities > Alerts & AI > 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.

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.

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.

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:

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:

1. Identifique incidentes individuais após serem criados, mas antes que um problema seja aberto.
2. 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:

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.

Um problema com um incidente crítico que foi silenciado

Uma lista de incidentes, alguns dos quais estão silenciados

Incidente e os problemas são marcados com o ícone na coluna Muted :

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.

• 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.

{
  actor {
    account(id: YOUR_ACCOUNT_ID) {
      alerts {
        mutingRules {
          name
          condition {
            operator
            conditions {
              attribute
              operator
              values
            }
          }
        }
      }
    }
  }
}

mutation {
  alertsMutingRuleCreate(
    accountId: YOUR_ACCOUNT_ID
    rule: {
      name: "host-1 mute rule"
      description: "Mute host-1 incidents"
      enabled: true
      condition: {
        operator: AND
        conditions: [
          { attribute: "tags.host", operator: EQUALS, values: ["host-1"] }
        ]
      }
    }
  ) {
    id
  }
}

mutation {
  alertsMutingRuleCreate(
    accountId: YOUR_ACCOUNT_ID
    rule: {
      name: "host-1 and synthetics/mobile mute rule"
      description: "Mute host-1 and synthetics/mobile incidents"
      enabled: true
      condition: {
        operator: OR
        conditions: [
          { attribute: "targetName", operator: EQUALS, values: ["host-1"] }
          {
            attribute: "product"
            operator: IN
            values: ["SYNTHETICS", "MOBILE"]
          }
        ]
      }
    }
  ) {
    id
  }
}

mutation {
  alertsMutingRuleUpdate(
    accountId: YOUR_ACCOUNT_ID
    id: MUTING_RULE_ID
    rule: { name: "updated name", enabled: false }
  ) {
    name
  }
}

mutation {
  alertsMutingRuleDelete(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID) {
    id
  }
}