Une façon de gérer votre ingestion de données consiste à utiliser les règles cloud de Contrôle de pipeline. Pour créer des règles Pipeline cloud, vous devez utiliser la tarification basée sur l'utilisation de New Relic Compute.

Il existe deux catégories de règles que vous pouvez créer :

• Règle de suppression des données

  • Supprimez des types de données entiers ou un sous-ensemble de données (avec filtre facultatif), avec NRQL sous la forme de :

    DELETE FROM DATA_TYPE_1, DATA_TYPE_2 (WHERE OPTIONAL_FILTER)

    Copier

• Règle d'attribut de suppression

  • Supprimer l'attribut des types de données (avec filtre facultatif), avec NRQL sous la forme de :

    DELETE dropAttr1, dropAttr2 FROM DATA_TYPE (WHERE OPTIONAL_FILTER)

    Copier
  • Pour ce type de règle, vous devez transmettre une liste non vide de noms d'attributs bruts dans la clause SELECT .

Pour en savoir plus sur les données qui sont considérées comme facturables ou non, consultez Ingestion de données.

Portée des données des règles du cloud

Utilisez les règles cloud pour cibler les types de données suivants :

• É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 métriques générées par le service événement-to-métriques: les règles Cloud ne fonctionneront pas mais ces métriques peuvent être arrêtées ou élaguées par attribut en désactivant ou en 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 cloud . Pour plus d'informations sur les données d'intervalle de temps métrique APM, consultez ce document.

Restrictions NRQL

• La limite de longueur des requêtes NRQL est de 4096 caractères. Si la longueur est supérieure, l'erreur INVALID_NRQL_TOO_LONG se produit. Si vous devez supprimer des données en fonction d'une requête plus longue qui ne peut pas être divisée, contactez votre support New Relic.
• JOIN et les sous-requêtes ne sont pas prises en charge.
• Vous pouvez fournir une clause WHERE pour sélectionner des données avec un attribut spécifique.
• des 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. 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 utiliser SINCE pour supprimer des données historiques. Les règles cloud s'appliquent uniquement aux données signalées après la création de la règle. Si vous devez supprimer des données qui ont déjà été signalées, reportez-vous à Supprimer les données existantes ou contactez le support New Relic.

Historique des règles d'audit

Pour voir qui a créé et supprimé les règles cloud, 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

Les règles du cloud s'appliquent à chaque point de données indépendamment. Par exemple, examinons les trois règles de suppression de données suivantes :

1. DELETE FROM MyEvent WHERE myAttr not in ('staging')
2. DELETE FROM MyEvent WHERE myAttr not in ('production')
3. DELETE FROM MyEvent WHERE myAttr in ('development')

Ces trois règles s'appliquent indépendamment à chaque point de données ; en résumé, tous les événements MyEvent contenant myAttr avec n'importe quelle valeur seront supprimés :

• myAttr: 'staging' -> correspond à la règle 2
• myAttr: 'production' -> correspond à la règle 1
• myAttr: 'development' -> correspond aux règles 1, 2 et 3
• myAttr: 'uuid-random-string' -> correspond aux règles 1 et 2

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. Testez et retestez toujours votre requête et, une fois la règle de suppression créée, assurez-vous qu'elle fonctionne comme prévu.

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.

Gestion des règles du cloud

Pour créer et modifier des règles, vous pouvez utiliser l'interface utilisateur Contrôle de pipeline ou l'explorateur d'API NerdGraph (one.newrelic.com > Apps > NerdGraph API explorer).

Exemples de cas d'utilisation

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Event1 and Event2 are unimportant, see ticket DM-1234"
      name: "Drop all data for Event1 and Event2"
      nrql: "DELETE FROM Event1, Event2"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      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"
      name: "Drop MyCustomEvent from LoadGeneratingApp in dev"
      nrql: "DELETE FROM MyCustomEvent WHERE appName='LoadGeneratingApp' AND environment='development'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Removes the user name and email fields from MyCustomEvent"
      name: "Drop username and email from MyCustomEvent"
      nrql: "DELETE userName, userEmail FROM MyCustomEvent"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

Vérifiez que votre règle fonctionne

Après avoir créé une règle cloud, vous souhaiterez peut-être vérifier 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.

Remarque : les données de séries chronologiques sont rendues avec l'heure de l'événement (et non l'heure de traitement) comme axe des x. Étant donné que New Relic accepte les données avec un horodatage allant jusqu'à vingt-quatre heures dans le futur, vous pouvez voir certaines données qui ont été envoyées à New Relic avant la création de la règle, mais avec un horodatage d'événement antérieur à la création de la règle.

DELETE FROM MyEvent WHERE foo = bar

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

DELETE dropAttr1, dropAttr2 FROM MyEvent WHERE foo = bar

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

Exemples de NerdGraph

Créer des règles de cloud

Déposer des données :

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Since we only care about MyEvent in staging and production, let's drop all MyEvent data in the test environment"
      name: "Drop MyEvent in test environment"
      nrql: "DELETE FROM MyEvent where environment = 'test'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

Attribut de dépôt :

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "We don't care about jvmId and targetAttr in the test environment, let's drop those attributes"
      name: "Drop jvmId and targetAttr from MyEvent in test environment"
      nrql: "DELETE jvmId, targetAttr FROM MyEvent where environment = 'test'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

Supprimer une règle cloud

mutation {
  entityManagementDelete(
    id: "MTAyNTY1MHxOR0VQfFBJUEVMSU5FX0NMT1VEX1JVTEV8MDE5NWI0NDYtNjk5My03NGE5LWEyYjktMzBjMzQ1ODM0NTUz"
  ) {
    id
  }
}

Afficher les règles du cloud

Obtenez une règle de cloud unique :

{
  actor {
    entityManagement {
      entity(
        id: "MTAyNTY1MHxOR0VQfFBJUEVMSU5FX0NMT1VEX1JVTEV8MDE5NWI0M2UtYmFhNy03NDk3LWI0N2ItNjUyMmEzZDFmZTFi"
      ) {
        id
        ... on EntityManagementPipelineCloudRuleEntity {
          id
          name
          description
          nrql
          metadata {
            createdBy {
              id
            }
            createdAt
          }
        }
      }
    }
  }
}

Lister toutes les règles du cloud :

{
  actor {
    entityManagement {
      entitySearch(query: "type = 'PIPELINE_CLOUD_RULE'") {
        entities {
          id
          type
          ... on EntityManagementPipelineCloudRuleEntity {
            id
            name
            nrql
          }
          metadata {
            createdBy {
              id
            }
          }
        }
      }
    }
  }
}

Événement et attribut non droppables

Vous ne pouvez pas supprimer l'événement et l'attribut suivants à l'aide des règles cloud :

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 en option). Ceci utilise NRQL sous la forme :

DELETE dropAttr1, dropAttr2 FROM MetricAggregate (WHERE OPTIONAL_FILTER)

Voici un exemple de requête NerdGraph :

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "We don't care about targetAttr in the test environment in dimensional metric rolloups, let's drop those attributes"
      name: "Drop targetAttr from Metric aggregate rollups in test environment"
      nrql: "DELETE targetAttr FROM MetricAggregate where environment = 'test'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

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 contrôle pipeline cloud , exécutez la requête suivante :

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

La première requête récupère les cumuls de 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 type d'événement MetricRaw 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 aux règles de suppression d'attribut s'appliquent aux règles rollup de métrique dimensionnelle avec la restriction supplémentaire que vous ne pouvez cibler que le type de données MetricAggregate . 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 du cloud.
• 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.