Alerta envía una notificación oportuna cuando su sistema tiene problemas. A veces hay notificaciones que sabes que no necesitas ver. Puedes usar muting rules para dejar de ser bombardeado con mensajes que no necesitan tu atención.

Una vez que haya identificado los elementos comunes en su notificación no deseada, puede definir reglas de silenciamiento que se dirijan específicamente a esos elementos, mientras deja pasar otras notificaciones. Incluso cuando una notificación está silenciada, alertassigue recopilando datos sobre esos incidentes. Las reglas de silenciamiento no interfieren con el proceso de alerta y se aplican justo antes de enviar una notificación.

Administrar reglas de silencio

Una condición de regla de silenciamiento es el conjunto de expresiones individuales compuestas por atributos, operadores y valores que definen qué incidente tiene como objetivo el silenciamiento.

Puede crear, habilitar, deshabilitar y administrar reglas de silenciamiento. Vaya a one.newrelic.com > All capabilities > Alerts & AI > Muting rules. Habilite o deshabilite las reglas de silencio en cualquier momento. Haga clic en el icono en la fila de cada regla para editar y eliminar reglas.

Las reglas pueden tener uno de los siguientes estados:

• Active

  : El silencio está habilitado y activo.

• Scheduled

  : El silencio está habilitado pero aún no está activo (hay un cronograma futuro).

• Ended

  : El silencio está habilitado, pero ya no está activo (no hay programación futura).

• Inactive

  : El silencio está desactivado.

Crear una regla de silenciamiento

Para crear una regla de silenciamiento, vaya a one.newrelic.com > All capabilities > Alerts & AI > Muting rules y haga clic en + Add a rule. Ingrese un nombre y una descripción (opcional) para la regla de silenciamiento y seleccione la cuenta a la que se aplicará la regla.

A continuación, cree el filtro de incidentes. Puedes utilizar un subconjunto de incidente evento atributo. Elija un atributo, un operador y un valor. Estos son los atributos: accountId, conditionId, conditionName, conditionType, entity.guid, nrqlEventType, nrqlQuery, policyId, policyName, product,runbookUrl (como conditionRunbookUrl), tags.<NAME> y targetName). Los valores se comparan con uno de los atributos de su incidente, como un ID de política de alertas o un nombre de condición. Haga clic en Add another condition si desea incluir más filtros.

Programar una regla de silenciamiento

Si es necesario, puede programar sus reglas de silenciamiento.

Para hacer esto, seleccione una hora de inicio y/o una hora de finalización. Opcionalmente, puede configurar la regla de silencio para que dure un día entero.

También puede optar por seleccionar una zona horaria para el programa de reglas de silenciamiento. El valor predeterminado es la zona horaria seleccionada en sus preferencias de usuario.

Puede programar sus reglas de silenciamiento para que se repitan diariamente, semanalmente o mensualmente. Una regla de silenciamiento programada para repetirse semanalmente incluye la opción de seleccionar los días de la semana que se repetirán. Si no se selecciona ningún día, la recurrencia semanal se repetirá de forma predeterminada el día de la semana en el que está programado que comience la regla de silenciamiento.

También puede especificar cuándo desea que finalice la recurrencia seleccionando una fecha específica o una cierta cantidad de ocurrencias.

Gestiona las reglas de silencio con NerdGraph

En NerdGraph, puede utilizar las siguientes consultas y mutaciones con sus reglas de silenciamiento. Puede ver el esquema con más detalle en API Explorer.

• actor.account.alerts.mutingRule: recupera una regla de silenciamiento por id.
• actor.account.alerts.mutingRules: obtiene una lista de reglas de silenciamiento para una cuenta.
• alertsMutingRuleCreate: cree una regla de silencio para una cuenta.
• alertsMutingRuleUpdate: Actualice una regla de silenciamiento por identificación e identificación de cuenta.
• alertsMutingRuleDelete: Elimine una regla de silenciamiento por identificación e identificación de cuenta.

Puede encontrar algunos ejemplos de consultas y mutaciones en esta página.

Una regla de silenciamiento tiene los siguientes campos y componentes:

Cómo funcionan las reglas de silenciamiento

Las reglas de silenciamiento se aplican al final del ciclo de vida de la alerta predeterminada para suprimir o silenciar la notificación. No desactivan las políticas o condiciones existentes. Por ejemplo, puede silenciar la notificación durante interrupciones conocidas del sistema, como ventanas de mantenimiento y despliegue. Los incidentes de interrupción del sistema aún se identificarán, aunque las notificaciones de esos incidentes estén silenciadas.

Una regla de silenciamiento utiliza un conjunto de condiciones que coinciden con el atributo en un evento de incidente. Las reglas de silenciamiento nos dicen cómo:

1. Identifique incidentes individuales después de su creación, pero antes de que se abra un problema.
2. Anule su condición predeterminada para indicar que deben "silenciarse".

Actualmente, silenciar un incidente significa que se mantendrá el ciclo de vida normal del incidente de alerta, excepto que un problema que solo contenga incidentes silenciados no enviará ninguna notificación.

Las reglas de silenciamiento están determinadas por el primer evento que desencadenó una notificación dentro de un problema. Es decir, si el primer evento de notificación se silenció debido a un estado de silenciamiento, el resto del problema también se silenciará.

Las reglas de silenciamiento anulan incidentes específicos. No desactivan las políticas o condiciones existentes. Esto le permite silenciar incidentes de entidades específicas que pueden estar cubiertas por una póliza o condición que cubre una gran cantidad de entidades. Esto también evita que tenga que silenciar demasiado su monitoreo cuando realiza mantenimiento en un subconjunto de su sistema.

Comportamiento de silencio

La siguiente tabla describe cómo el ciclo de vida del incidente de alerta se ve afectado por el incidente silenciado:

Comportamiento de silenciamiento con flujo de trabajo

Un incidente activado tiene una proporción de 1:1 con un problema, por lo que si se silencia un incidente, el problema correspondiente también se silenciará. El flujo de trabajo se desencadena por cuestiones que pueden tener uno o más incidentes, por lo que podría darse un escenario de incidentes silenciados y no silenciados combinados.

Cada problema tiene uno de los siguientes estados de silenciamiento:

• Fully muted (FULLY_MUTED)

  : un problema tiene todos sus incidentes abiertos silenciados (valor predeterminado).

• Partially muted (PARTIALLY_MUTED)

  : un problema que tiene al menos un incidente abierto silenciado y un incidente abierto que no está silenciado.

• Not muted (NOT_MUTED)

  : un tema que no tiene un incidente silenciado abierto.

Para obtener una guía paso a paso sobre cómo configurar su flujo de trabajo, consulte una demostración de ejemplo a continuación (aprox. 2:17 minutos):

Ver incidentes y problemas silenciados

Al visualizar un problema abierto o cerrado, el incidente y los problemas se marcan como Muted. Las siguientes secciones muestran algunos de estos incidentes y problemas silenciados, y dónde puede encontrarlos.

Un problema con un incidente crítico que ha sido silenciado

Una lista de incidentes, algunos de los cuales están silenciados.

incidentes y problemas están marcados con el icono en la columna Muted :

Silenciar resultados facetados usando tags.

Para silenciar los resultados de la consulta facetada, utilice el atributo tags.FACETED_ATTRIBUTE, donde FACETED_ATTRIBUTE representa el atributo en el que ejecutó una consulta NRQL FACET . Por ejemplo: si su condición de alerta NRQL incluye FACET host en su consulta, puede apuntar a ese FACET atributo usando tags.host.

La consulta de condición NRQL puede aceptar atributos de múltiples facetas. Si desea poder filtrar por atributo en su evento o serie de tiempo métrica que se han agregado, debe agregar esos atributos a su cláusula FACET de consulta NRQL; por ejemplo: FACET host, region, cluster.

Para ver un ejemplo del uso de tags., consulte Crear regla de silenciamiento.

Operadores de subcondiciones

Estos son los operadores lógicos que puede utilizar para comparar atributos cuando agrega reglas de silenciamiento. Si eres nuevo en el mundo de las reglas de silenciamiento, consulta estos ejemplos.

• EQUALS: Donde el valor proporcionado es igual al valor del atributo del incidente.

• DOES_NOT_EQUALS: donde el valor proporcionado no es igual al valor del atributo del incidente.

• IN: donde el valor del atributo del incidente está presente en una lista de valores proporcionados (hasta 500).

• NOT_IN: donde el valor del atributo del incidente no está presente en una lista de valores proporcionados (hasta 500).

• CONTAINS: donde la cadena de valor proporcionada está presente en el valor del atributo del incidente.

• DOES_NOT_CONTAINS: donde la cadena de valor proporcionada no está presente en el valor del atributo del incidente.

• ENDS_WITH: donde el valor del atributo del incidente termina con la cadena de valor proporcionada.

• NOT_ENDS_WITH: donde el valor del atributo del incidente no termina con la cadena de valor proporcionada.

• STARTS_WITH: donde el valor del atributo del incidente comienza con la cadena de valor proporcionada.

• DOES_NOT_STARTS_WITH: donde el valor del atributo del incidente no comienza con la cadena de valor proporcionada.

• IS_BLANK: donde el valor del atributo del incidente está en blanco. Cadena nula, vacía, etc.

• IS_NOT_BLANK: Donde el valor del atributo del incidente no está en blanco. Cadena nula, vacía, etc.

• IS_ANY:

  Caution:

  Una condición con este operador silenciará

  all

  incidente en la cuenta.

Ejemplos de silenciamiento

Para obtener más información sobre cómo realizar solicitudes a NerdGraph, consulte la documentación de NerdGraph, incluidos los tutoriales de 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
  }
}