Tutoriel NerdGraph : perte de signal et remplissage d'espace

Vous pouvez personnaliser la détection de perte de signal d'alerte New Relic et le remplissage des espaces à l'aide de notre API NerdGraph. Par exemple, vous pouvez configurer le temps d'attente avant de considérer le signal comme perdu, ou la valeur à utiliser pour combler les lacunes dans la série temporelle.

La perte de signal se produit lorsque New Relic cesse de recevoir des données pendant un certain temps ; techniquement, nous détectons la perte de signal après qu'un laps de temps important s'est écoulé depuis la dernière réception des données dans une série chronologique. La perte de signal peut être utilisée pour déclencher ou résoudre un incident, que vous pouvez utiliser pour configurer des alertes.

Le remplissage des lacunes peut vous aider à résoudre les problèmes causés par la perte de points de données. Lorsque des écarts sont détectés entre des points de données valides, nous comblons automatiquement ces écarts avec des valeurs de remplacement, telles que les dernières valeurs connues ou une valeur statique. Le comblement des lacunes peut empêcher les alertes de se déclencher ou de se résoudre alors qu'elles ne devraient pas.

Dans ce guide, nous abordons les points suivants :

• Personnaliser la détection de perte de signal
• Personnaliser le remplissage des espaces

Personnalisez votre détection de perte de signal

La détection de perte de signal ouvre ou ferme l'incident si aucune donnée n'est reçue après un certain temps. Par exemple, si vous définissez la durée de la période d'expiration sur 60 secondes et qu'une intégration ne semble pas envoyer de données pendant plus d'une minute, un seuil de perte de signal serait déclenché.

Vous pouvez configurer la durée de la perte de signal et décider d'ouvrir un incident ou de le fermer en utilisant ces trois champs dans NerdGraph :

• expiration.expirationDuration:Combien de temps attendre, en secondes, après la réception du dernier point de données par notre plateforme avant de considérer le signal comme perdu. Ceci est basé sur le moment où les données arrivent sur notre plateforme et non sur l'horodatage des données. La valeur par défaut est de laisser cette valeur nulle, ce qui n'activera pas la détection de perte de signal.
• expiration.openViolationOnExpiration: Si true, un nouvel incident est ouvert lorsqu'un signal est perdu. La valeur par défaut est false. Pour utiliser ce champ, une durée doit être spécifiée.
• expiration.closeViolationsOnExpiration: Si true, les incidents ouverts liés au signal sont fermés à l'expiration. La valeur par défaut est false. Pour utiliser ce champ, une durée doit être spécifiée.

Vous avez également la possibilité d'ignorer l'ouverture d'un incident lorsque le signal est susceptible d'être perdu. Pour ce faire, utilisez ce champ dans NerdGraph :

• expiration.ignoreOnExpectedTermination: Si true, un incident ne sera pas ouvert lorsque le signal est censé être perdu. Pour indiquer qu'un signal est susceptible d'être perdu, la tag termination: expected doit être présente sur l'entité. La valeur par défaut est false. Pour l'entité hôte infrastructure , la tag hostStatus: shutdown indiquera également que le signal est censé s'arrêter et empêcher l'ouverture d'un incident .

Afficher les paramètres de perte de signal pour une condition existante

Les conditions NRQL existantes peuvent avoir leurs paramètres de perte de signal déjà configurés. Pour afficher les paramètres de condition existants, sélectionnez les champs sous nrqlCondition > expiration:

{
  actor {
    account(id: YOUR_ACCOUNT_ID) {
      alerts {
        nrqlCondition(id: NRQL_CONDITION_ID) {
          ... on AlertsNrqlStaticCondition {
            id
            name
            nrql {
              query
            }
            expiration {
              closeViolationsOnExpiration
              expirationDuration
              openViolationOnExpiration
              ignoreOnExpectedTermination
            }
          }
        }
      }
    }
  }
}

Vous devriez voir un résultat comme celui-ci :

{
  "data": {
    "actor": {
      "account": {
        "alerts": {
          "nrqlCondition": {
            "expiration": {
              "closeViolationsOnExpiration": false,
              "expirationDuration": 300,
              "openViolationOnExpiration": true,
              "ignoreOnExpectedTermination": false
            },
            "id": "YOUR_ACCOUNT_ID",
            "name": "Any less than - Extrapolation",
            "nrql": {
              "query": "SELECT average(value) FROM AlertsSmokeTestSignals WHERE wave_type IN ('min-max', 'single-gap') FACET wave_type"
            }
          }
        }
      }
    }
  },
  ...

Créer une nouvelle condition avec perte des paramètres de signal

Disons que vous souhaitez créer une nouvelle condition statique NRQL qui déclenche un seuil de perte de signal après qu'aucune donnée n'a été reçue pendant deux minutes. Vous définiriez expirationDuration sur 120 secondes et openViolationOnExpiration sur true, comme dans l'exemple ci-dessous.

mutation {
  alertsNrqlConditionStaticCreate(
    accountId: YOUR_ACCOUNT_ID
    policyId: YOUR_POLICY_ID
    condition: {
      name: "Low Host Count - Catastrophic"
      enabled: true
      nrql: {
        query: "SELECT uniqueCount(host) FROM Transaction WHERE appName='my-app-name'"
      }
      signal {
        aggregationWindow: 60
        aggregationMethod: EVENT_FLOW
        aggregationDelay: 120
      }
      terms: [{
        threshold: 2
        thresholdOccurrences: AT_LEAST_ONCE
        thresholdDuration: 600
        operator: BELOW
        priority: CRITICAL
      }]
      valueFunction: SINGLE_VALUE
      violationTimeLimitSeconds: 86400
      expiration: {
        expirationDuration: 120
        openViolationOnExpiration: true
      }
    }
  ) {
    id
    name
  }
}

Mettre à jour les paramètres de perte de signal d'une condition

Que faire si vous souhaitez mettre à jour le paramètre de perte de signal pour une condition d'alerte ? La mutation suivante vous permet de mettre à jour une condition statique NRQL avec de nouvelles valeurs expiration .

mutation {
  alertsNrqlConditionStaticUpdate(
    accountId: YOUR_ACCOUNT_ID
    id: YOUR_STATIC_CONDITION_ID
    condition: {
      expiration: {
        closeViolationsOnExpiration: true
        expirationDuration: 300
        openViolationOnExpiration: false
        ignoreOnExpectedTermination: true
      }
    }
  ) {
    id
    expiration {
      closeViolationsOnExpiration
      expirationDuration
      openViolationOnExpiration
      ignoreOneExpectedTermination
    }
  }
}

Personnaliser le remplissage des espaces

Le remplissage des lacunes remplace les valeurs des lacunes dans une série chronologique par la dernière valeur trouvée ou par une valeur statique et arbitraire de votre choix. Nous comblons les lacunes uniquement après qu'un autre point de données a été reçu après les lacunes du signal (après que la réception des données a été rétablie).

Vous pouvez configurer à la fois le type de remplissage et la valeur, si le type est défini sur statique :

• signal.fillOption: Type de valeur de remplacement pour les points de données perdus. Les valeurs peuvent être :

  • NONE: Le remplissage des espaces est désactivé.
  • LAST_VALUE:La dernière valeur observée dans la série chronologique.
  • STATIC:Une valeur arbitraire, définie dans fillValue.

• signal.fillValue: Valeur à utiliser pour remplacer les points de données perdus lorsque fillOption est défini sur STATIC.

Par exemple, voici comment créer une condition NRQL statique avec le remplissage des espaces configuré :

mutation {
  alertsNrqlConditionStaticCreate(
    accountId: YOUR_ACCOUNT_ID
    policyId: YOUR_POLICY_ID
    condition: {
      enabled: true
      name: "Example Gap Filling Condition"
      nrql: { query: "SELECT count(*) FROM Transaction" }
      terms: {
        operator: ABOVE
        priority: CRITICAL
        threshold: 1000
        thresholdDuration: 300
        thresholdOccurrences: ALL
      }
      valueFunction: SINGLE_VALUE
      violationTimeLimitSeconds: 28800
      signal: {
        aggregationWindow: 60
        aggregationMethod: EVENT_FLOW
        aggregationDelay: 120
        fillOption: STATIC
        fillValue: 1
      }
    }
  ) {
    id
  }
}