Supprimer des données à l'aide de NerdGraph

Une façon de gérer votre ingestion de données consiste à mettre en place des règles de suppression des données. Avec la suppression des données, vous pouvez :

• Filtrer les données sans importance et de faible valeur
• Filtrer les données potentiellement sensibles

Présentation

Avec les règles de suppression des données, vous pouvez spécifier les types de données que vous ne souhaitez pas enregistrer dans votre organisation New Relic.

Les données supprimées ne sont pas comptabilisées dans votre ingestion de données et ne sont donc pas facturables. Pour en savoir plus sur les données considérées comme facturables ou non, consultez Ingestion de données.

Les règles de suppression s'appliquent uniquement aux données qui arrivent à partir du moment où vous créez la règle. Ils ne suppriment pas les données qui ont déjà été ingérées.

Apprenez-en plus sur la suppression de données dans cette vidéo (7:09 minutes) :

Outre la création de règles de suppression de données, d'autres moyens de minimiser les données indésirables incluent :

• Si vous souhaitez supprimer les données d'intervalle de temps métrique APM, vous pouvez utiliser les règles de normalisation métrique. Cependant, vous ne pouvez pas supprimer les données d'intervalle de temps métrique avec les règles de suppression. Pour plus d'informations sur la différence entre les données d'intervalle de temps métrique et les mesures dimensionnelles, consultez la documentation sur les types de données New Relic.
• Si vous créez un rapport de log, vous pouvez supprimer les données log via l'UI.
• Si vous utilisez l'écriture à distance Prometheus, consultez Supprimer les données d'écriture à distance Prometheus.

Exigences

La possibilité de créer et de modifier des règles de filtrage de dépôt est liée à la capacitéNRQL drop rules .

Les types de données suivants peuvent être ciblés par la suppression de données :

• Événement signalé par l'APM

• Événement signalé par Browser

• Événement signalé par téléphone portable

• Événement rapporté par les synthétiques

• événement personnalisé (comme ceux générés par l' APM API d'agent ou l' événement API)

• enregistrer les données (vous pouvez également utiliser l'UI pour supprimer des données)

• Tracing distribué des span

• monitoring des défauts d'événement infrastructure et événement d'intégrationinfrastructure . Quelques mises en garde :

  • Lorsque vous supprimez ces données, les données brutes sont supprimées, mais les événements agrégés SystemSample, ProcessSample, NetworkSample et StorageSample sont toujours disponibles (pour plus d'informations, voir rétention des données). Bien que toujours disponibles, ces données ne sont pas comptabilisées dans l'ingestion et ne sont pas facturables.
  • Les données d'infrastructure brutes sont utilisées pour les alertes. Par conséquent, si vous supprimez ces données, vous ne pouvez pas générer d'alerte à leur sujet. Étant donné que les données agrégées sont toujours disponibles, vous pouvez toujours voir ces données dans des graphiques avec des plages de temps supérieures à 59 minutes.

• Métriques dimensionnelles. Quelques mises en garde :

  • Pour les organisations sur notre modèle de tarification d'origine: la facturation est basée sur l'abonnement produit, ce qui signifie que les métriques dimensionnelles abandonnées restent facturables.
  • Pour les métriques générées par le service événement-to-métriques: les règles de suppression ne fonctionneront pas mais ces métriques peuvent être arrêtées ou élaguées par attribut en désactivant ou reconfigurant la règle événement-to-métrique.
  • Les données d'intervalle de temps métrique ne peuvent pas être supprimées avec les règles de suppression. Pour plus d'informations sur les données d'intervalle de temps métrique APM, consultez ce document.

Créer une règle de suppression de données

Pour supprimer des données, créez une règle de suppression au format NerdGraphqui inclut :

• Une chaîne NRQL qui spécifie les types de données à supprimer
• Un type action spécifiant comment appliquer la chaîne NRQL

Vous pouvez former et effectuer l'appel dans l'explorateur d'API NerdGraph : one.newrelic.com > Apps > NerdGraph API explorer.

La limite de longueur de requête NRQL est de 4096 caractères. Si la longueur est supérieure, le nerdGraph renverra une erreur INVALID_NRQL_TOO_LONG.

Il existe deux façons de supprimer des données :

• Drop entire data types or a data subset (avec filtre optionnel). Ceci utilise le type DROP_DATA action et utilise NRQL sous la forme :

  SELECT * FROM DATA_TYPE_1, DATA_TYPE_2 (WHERE OPTIONAL_FILTER)

  Copier

  Pour ce type de règle de suppression, vous ne pouvez pas utiliser autre chose que * dans la clause SELECT .

• Drop attributes from data types (avec filtre optionnel). Ceci utilise le type DROP_ATTRIBUTES action et utilise NRQL sous la forme :

  SELECT dropAttr1, dropAttr2 FROM DATA_TYPE (WHERE OPTIONAL_FILTER)

  Copier

  Pour ce type de règle de suppression, vous devez transmettre une liste non vide de noms d’attributs bruts.

Restrictions NRQL

Toutes les clauses NRQL n’ont pas de sens pour générer des règles de suppression. Vous pouvez fournir une clause WHERE pour sélectionner des données avec un attribut spécifique. D'autres fonctionnalités telles que LIMIT, TIMESERIES, COMPARE WITH, FACET et d'autres clauses ne peuvent pas être utilisées.

SINCE et UNTIL ne sont pas pris en charge dans les règles de suppression. Si vous avez des règles spécifiques au temps (par exemple, tout abandonner jusqu'à un moment dans le futur), utilisez WHERE timestamp < (epoch milliseconds in the future). Vous ne pouvez pas non plus utiliser SINCE pour supprimer des données historiques : les règles de suppression NRQL s'appliquent uniquement aux données signalées après la création de la règle de suppression. Si vous devez supprimer des données qui ont déjà été signalées, contactez votre représentant New Relic.

JOIN et les sous-requêtes ne sont pas non plus prises en charge. Les règles de suppression sont appliquées à chaque point de données indépendamment et les autres données ne peuvent pas être interrogées pour déterminer si une règle de suppression doit être appliquée.

Les deux types d'actions ont les restrictions suivantes :

• DROP_DATA ne peut utiliser que SELECT *.
• DROP_ATTRIBUTES nécessite l'utilisation de SELECT avec l'attribut « raw » (attributs sans fonction d'agrégateur appliqués). Cela signifie également que vous ne pouvez pas utiliser SELECT *. De plus, certains attributs sont essentiels à leur type de données et à cannot be dropped (comme timestamp sur les données d'événement). Si vous les incluez, l'inscription échouera.

Exemple de règles de dépôt

Voici quelques exemples de règles de dépôt :

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM Event1, Event2"
        description: "Drops all data for Event1 and Event2."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM MyCustomEvent WHERE appName='LoadGeneratingApp' AND environment='development'"
        description: "Drops all data for MyCustomEvent that comes from the LoadGeneratingApp in the dev environment, because there is too much and we don’t look at it."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT userEmail, userName FROM MyCustomEvent"
        description: "Removes the user name and email fields from MyCustomEvent"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Vérifiez que votre règle de suppression fonctionne

Après avoir créé une règle de suppression, vérifiez qu’elle fonctionne comme prévu. La règle devrait prendre effet rapidement après une inscription réussie, essayez donc d'exécuter une version TIMESERIES de la requête que vous avez enregistrée pour voir que les données diminuent.

SELECT * FROM MyEvent WHERE foo = bar

SELECT count(*) FROM MyEvent WHERE foo = bar TIMESERIES

SELECT dropAttr1, dropAttr2 FROM MyEvent WHERE foo = bar

SELECT count(dropAttr1), count(dropAttr2) FROM MyEvent WHERE foo = bar TIMESERIES

Voir les règles

Voici un exemple d'appel NerdGraph qui renvoie les règles de suppression définies sur un compte :

{
  actor {
    account(id: YOUR_ACCOUNT_ID) {
      nrqlDropRules {
        list {
          rules {
            id
            nrql
            accountId
            action
            createdBy
            createdAt
            description
          }
          error {
            reason
            description
          }
        }
      }
    }
  }
}

Supprimer les règles de dépôt

Voici un exemple d’appel NerdGraph supprimant deux règles de suppression spécifiques :

mutation {
  nrqlDropRulesDelete(accountId: YOUR_ACCOUNT_ID, ruleIds: ["48", "98"]) {
    successes {
      id
      nrql
      accountId
      action
      description
    }
    failures {
      error {
        reason
        description
      }
      submitted {
        ruleId
        accountId
      }
    }
  }
}

Historique des règles de suppression d'audit

Pour voir qui a créé et supprimé des règles de dépôt, interrogez le log d'audit de votre compte. Le point de terminaison de la liste inclut également l’ID utilisateur de la personne qui a créé la règle.

Précautions à prendre lors de la suppression de données

Lors de la création de règles de suppression, vous êtes responsable de vous assurer que les règles identifient et suppriment avec précision les données qui répondent aux conditions que vous avez établies. Vous êtes également responsable du monitoring de la règle, ainsi que des données que vous divulguez à New Relic.

New Relic ne peut pas garantir que cette fonctionnalité résoudra complètement les problèmes de divulgation de données que vous pourriez avoir. New Relic ne révise pas et ne monitore pas l'efficacité des règles que vous développez.

La création de règles sur les données sensibles peut entraîner une fuite d'informations sur les types de données que vous conservez, y compris le format de vos données ou de votre système (par exemple, en référençant des adresses e-mail ou des numéros de carte de crédit spécifiques). Les règles que vous créez, y compris toutes les informations qu'elles contiennent, peuvent être consultées et modifiées par tout utilisateur disposant des autorisations de contrôle d'accès basées sur les rôles appropriées.

Seules les nouvelles données seront supprimées. Les données existantes ne peuvent pas être modifiées ou supprimées.

Supprimer l'attribut sur les cumuls métriques dimensionnels

Dimensions métriques agrégées en rollups pour le stockage à long terme et comme moyen d'optimiser les requêtes à plus long terme. Des limites de cardinalité métrique sont appliquées à ces données.

Vous pouvez utiliser cette fonctionnalité pour décider quel attribut vous n'avez pas besoin pour le stockage à long terme et la requête, mais que vous souhaitez conserver pour la requête à temps réel.

Par exemple, l'ajout de containerId comme attribut peut être utile pour le dépannage en direct ou l'analyse récente, mais peut ne pas être nécessaire lors d'interrogations sur des périodes plus longues pour des tendances plus importantes. En raison du caractère unique d'un élément comme containerId, il peut rapidement vous conduire vers vos limites de cardinalité métrique qui, lorsqu'elles sont atteintes, arrêtent la synthèse des cumuls pour le reste de cette journée UTC.

Cette fonctionnalité vous permet également de conserver l'attribut forte cardinalité sur les données brutes et de le supprimer des cumuls, ce qui vous donne plus de contrôle sur la rapidité avec laquelle vous approchez vos limites de cardinalité.

Usage

Drop attributes from dimensional metrics rollups (avec filtre optionnel). Ceci utilise le type DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES action et utilise NRQL sous la forme :

SELECT dropAttr1, dropAttr2 FROM Metric (WHERE OPTIONAL_FILTER)

Voici un exemple de requête NerdGraph :

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES
        nrql: "SELECT containerId FROM Metric WHERE metricName = 'some.metric'"
        description: "Removes the containerId from long term querys."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Pour vérifier que cela fonctionne, attendez 3 à 5 minutes pour que la règle soit récupérée et que les données agrégées soient générées. Ensuite, en supposant que l’exemple NRQL ci-dessus soit votre règle de suppression, exécutez la requête suivante :

SELECT count(containerId) FROM Metric WHERE metricName = 'some.metric' TIMESERIES SINCE 2 hours ago
SELECT count(containerId) FROM Metric WHERE metricName = 'some.metric' TIMESERIES SINCE 2 hours ago RAW

La première requête récupère les cumuls métriques et doit tomber à 0 puisque containerId a été supprimé conformément à la nouvelle règle de suppression. La deuxième requête récupère les données brutes métriques à l'aide du mot-clé RAW et devrait rester stable puisque les données brutes ne sont pas affectées par la nouvelle règle de suppression. Pour plus d'informations sur la façon de voir l'impact que cela aura sur votre cardinalité, consultez Comprendre et requête forte cardinalité métriques.

Restrictions

Toutes les restrictions qui s'appliquent à DROP_ATTRIBUTES s'appliquent à DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES avec la restriction supplémentaire que vous ne pouvez cibler que le type de données Metric . Ils ne fonctionnent pas non plus sur Metric requêtes ciblant les données créées par une règle événement à métriques ou sur les Metric requêtes ciblant les données d'intervalle de temps.

En savoir plus

Recommandations pour en savoir plus :

• Notions de base et terminologie de NerdGraph
• Notions de base sur NRQL
• Parcourez le forum d'assistance pour les discussions communautaires sur les règles de suppression NRQL.
• Pour une analyse approfondie de la gestion de l’ingestion de données pour une organisation complexe, consultez Gouvernance de l’ingestion de données.