Optimisez vos données d'ingestion

Le volume de données généré par l'agent APM sera déterminé par plusieurs facteurs :

• La quantité de trafic organique générée par l'application (par exemple, toutes choses étant égales par ailleurs, une application appelée un million de fois par jour générera plus de données qu'une application appelée mille fois par jour)

• Certaines des caractéristiques des données de transaction sous-jacentes elles-mêmes (longueur et complexité des URL)

• Si l'application rapporte une requête de base de données

• Si l'application a des transactions avec de nombreux (ou aucun) attribut personnalisé

• Le volume d'erreur pour l'application

• Si l'agent d'application est configuré pour le tracing distribué

  Gestion du volume

  Bien que vous puissiez supposer que tous les appels à une application sont nécessaires, il est possible de rendre votre architecture globale plus efficace. Vous pouvez avoir un microservices de profil utilisateur appelé toutes les 10 secondes par ses clients. Cela permet de réduire la latence si certaines informations utilisateur sont mises à jour par d’autres clients. Vous avez toutefois la possibilité de réduire la fréquence des appels vers ce service à chaque minute, par exemple.

  Les attributs personnalisés

  Tout attribut personnalisé ajouté à l’aide d’un appel à une API APM addCustomParameter ajoutera un attribut supplémentaire aux frais de transaction. Ces données sont souvent utiles, mais à mesure que les choses changent, elles peuvent devenir moins précieuses, voire obsolètes.

  L'agent Java capture les éléments request.headers suivants par défaut :

• request.headers.referer

• request.headers.accept

• request.headers.contentLength

• request.headers.host

• request.headers.userAgent

  Les développeurs peuvent également utiliser addCustomParameter pour capturer plus d’informations à l’aide d’en-têtes plus détaillés.

  Pour un exemple de la riche configuration disponible par rapport à APM, consultez notre documentation sur l'agent Java

  Événement d'erreur

  Il est possible de réduire le volume de données en trouvant comment APM gérera les erreurs. Par exemple, il peut y avoir une erreur inoffensive mais à volume élevé que vous ne pouvez pas supprimer pour le moment.

  Pour ce faire, vous pouvez utiliser collect, ignore ou mark as expected pour les erreurs. Pour plus d'informations, voir Gérer les erreurs APM.

  requête de base de données

  Un aspect très variable de l'instance APM est le nombre d'appels de base de données et la configuration de l'ensemble. Pour vous aider, vous pouvez contrôler le degré de détail monitoring des requêtes de base de données. Ces requêtes apparaîtront sur la page Transaction traces .

  Les modifications courantes des paramètres de requête de base de données incluent :

• Collecte de données de requête brutes au lieu de les obscurcir ou de désactiver la collecte de requêtes.

• Modification du seuil de trace d'appels.

• Activation de la requête expliquant la collection de plans.

  Pour plus de détails, voir la page trace de transaction requête de base de données.

  Définition des limites d'événements

  Nos agents APM et mobiles ont des limites quant au nombre d'événements qu'ils peuvent signaler par cycle de collecte. S'il n'y avait pas de limite, un nombre suffisamment important d'événements envoyés pourrait impacter les performances de votre application ou de New Relic. Une fois la limite atteinte, les agents commencent à échantillonner l'événement pour donner une représentation de l'événement à travers le cycle de collecte. Différents agents ont des limites différentes.

  événement qui, avec des limites et sous réserve d'échantillonnage, comprend :

• événement personnalisé signalé via l'API d'agent (par exemple, le RecordCustomEvent de l'agent .NET)

• Mobile

• MobileCrash

• MobileHandledException

• MobileRequest

• Span (voir l'échantillonnage de tracing distribué)

• Transaction

• TransactionError

  La plupart des agents disposent d'options configuration permettant de modifier la limite d'événements sur les transactions échantillonnées. Par exemple, l'agent Java utilise max_samples_stored. La valeur par défaut pour max_samples_stored est 2000 et la valeur maximale est 10000. Cette valeur régit le nombre d'événements échantillonnés pouvant être signalés toutes les 60 secondes à partir d'une instance d'agent. Pour une explication complète des limites d'échantillonnage d'événement, voir limites d'événement.

  Vous pouvez compenser l'événement échantillonné via NRQL EXTRAPOLATE l'opérateur.

  Avant de tenter de modifier la manière dont l’échantillonnage se déroule, gardez à l’esprit les points suivants :

• Plus vous signalez d'événements, plus votre agent utilisera de mémoire.

• Vous pouvez généralement obtenir les données dont vous avez besoin sans augmenter la limite de rapport d'événements d'un agent.

• La limite de taille de charge est de 1 Mo (10^6 octets) (compressé), donc le nombre d'événements peut toujours être affecté par cette limite. Pour savoir si des événements sont supprimés, consultez le log de l'agent pour un message d'état 413 HTTP.

  taux d'échantillonnage logarithmique

  Les versions plus récentes des agents de langage New Relic APM peuvent transférer les logs directement vers New Relic. Parfois, vous souhaiterez peut-être définir certaines limites quant à l'ampleur des pics de logging de chaque instance d'agent APM.

  Pour plus de détails sur l'échantillonnage log de l'agent APM, voir redirecteur de logs.

  Trace de transaction

  Les moteurs de la croissance

  • Nombre de services connectés
  • Nombre d'appels de méthode monitorés par services connectés

  Dans APM, tracez les enregistrements de transactions en détail sur les transactions de votre application et les appels de base de données. Vous pouvez modifier les paramètres par défaut pour le suivi de transaction.

  Ceci est également hautement configurable via la trace de transaction configuration. Le niveau et le mode de configurabilité seront spécifiques à la langue.

  Les paramètres trace de transaction disponibles à l'aide de configuration côté serveur diffèrent en fonction de l'agent New Relic que vous utilisez. L'interface utilisateur comprend des descriptions de chacun. Les paramètres de l'interface utilisateur peuvent inclure :

• Traçage des transactions et seuil

• Enregistrement SQL, y compris le niveau d'enregistrement et les champs de saisie

• Seuil de Log SQL et trace d'appels

• Plans et seuils de requêtes SQL

• Collecte d'erreurs, y compris le code HTTP et la classe d'erreur

• requête de traçage de lentille

• Profileur de filetage

  Tracing distribué

  Configuration du tracing distribuée présente certaines différences spécifiques à chaque langue. Vous pouvez désactiver le tracing distribué selon vos besoins. Ceci est un exemple pour l'agent Java newrelic.yml:

  distributed_tracing:
      enabled: false

  Copier

  Ceci est un exemple de node.js pour newrelic.js

  distributed_tracing: {
    enabled: false
  }

  Copier

  Le volume de données varie également selon que vous utilisez ou non Infinite Tracing. Le tracing distribué standard pour les agents APM (ci-dessus) capture jusqu'à 10 % de votre trace, mais si vous souhaitez analyser toutes vos données et trouver la trace la plus pertinente, vous pouvez configurer l'Infinite Tracing. Cette alternative au tracing distribué standard est disponible pour tous les agents de langage APM. Les principaux paramètres qui pourraient entraîner une légère augmentation de l'ingestion mensuelle sont :

• Configurer le monitoring de l'observateur de trace

• Configurer le filtre de trace d’attribut span

• Configurer un filtre de trace aléatoire

Pour la version 1211 ou supérieure de l'agent de navigateur , toutes requests réseau effectuées par une page sont enregistrées comme événement AjaxRequest. Vous pouvez utiliser les options configuration de la liste de refus dans la page d'interface utilisateur des paramètres de l'application pour filtrer requests qui enregistrent l'événement. Quel que soit ce filtre, toutes requests réseau sont capturées sous forme de métriques et disponibles dans la page AJAX.

Utilisation de la liste de refus

Vous pouvez bloquer requests de trois manières :

• Pour bloquer l'enregistrement de tous AjaxRequest événements, ajoutez un astérisque * comme caractère générique.

• Pour bloquer l'enregistrement de AjaxRequest événement sur un domaine, entrez simplement le nom du domaine. Exemple: example.com

• Pour bloquer l'enregistrement de l'événement AjaxRequest dans un domaine et un chemin spécifiques, entrez le domaine et le chemin. Exemple: example.com/path

• Le protocole, le port, la recherche et le hachage d'une URL sont ignorés par la liste de refus.

  Pour valider si les filtres que vous avez ajoutés fonctionnent comme prévu, exécutez une requête NRQL pour AjaxRequest événement correspondant à votre filtre.

  Accéder à la liste de refus

  Pour mettre à jour la liste de refus des URL que votre application filtrera pour empêcher la création d'événements, accédez à la page d'interface utilisateur des paramètres de l'application :

1. Allez à one.newrelic.com et cliquez sur Browser.

2. Sélectionnez une application.

3. Dans la navigation de gauche, cliquez sur App settings.

4. Sous Ajax request deny list, ajoutez les filtres que vous souhaitez appliquer.

5. Sélectionnez Save application settings pour mettre à jour la configuration de l'agent.

6. Redéployez l'agent du navigateur en redémarrant l'agent APM associé ou en mettant à jour l'installation du navigateur par copier/coller.

   Validation

   FROM AjaxRequest SELECT * WHERE requestUrl LIKE `%example.com%`

   Copier

Android

Tous les paramètres, y compris l'appel pour invoquer l'agent, sont appelés dans la méthode onCreate de la classe MainActivity . Pour modifier les paramètres, appelez le paramètre de l'une des deux manières suivantes (si le paramètre le prend en charge) :

NewRelic.disableFeature(FeatureFlag.DefaultInteractions);
NewRelic.enableFeature(FeatureFlag.CrashReporting);
NewRelic.withApplicationToken(NEW_RELIC_TOKEN).start(this.getApplication());

Les paramètres d'analyse activent ou désactivent la collecte de données d'événement. Ces événements sont signalés et utilisés dans la page Crash analysis .

Il est également possible de configurer le logging de l'agent pour qu'il soit plus ou moins détaillé.

iOS

Comme avec Android, configuration iOS de New Relic permet d'activer et de désactiver les indicateurs de fonctionnalité.

Vous pouvez configurer les indicateurs de fonctionnalité suivants :

Rapports de plantage et d'erreurs

• NRFeatureFlag_CrashReporting
• NRFeatureFlag_HandleExceptionEvents
• NRFeatureFlag_CrashReporting

Tracing distribué

• NRFeatureFlag_DistributedTracing

interaction

• NRFeatureFlag_DefaultInteractions
• NRFeatureFlag_InteractionTracing
• NRFeatureFlag_SwiftInteractionTracing

Drapeaux de fonctionnalité du réseau

• NRFeatureFlag_ExperimentalNetworkInstrumentation
• NRFeatureFlag_NSURLSessionInstrumentation
• NRFeatureFlag_NetworkRequestEvents
• NRFeatureFlag_RequestErrorEvents
• NRFeatureFlag_HttpResponseBodyCapture

Pour plus de détails, voir les indicateurs de fonctionnalité.

Le fichier de configuration de l'agent d'infrastructure contient deux manières de contrôler le volume d'ingestion. Le contrôle d’ingestion le plus important est la configuration des taux d’échantillonnage. Il existe plusieurs configurations de fréquence d'échantillonnage distinctes que vous pouvez ajuster. Il est également possible de créer des expressions régulières pour contrôler ce qui est collecté à partir de certains collecteurs, tels que ProcessSample et NetworkSample.

Taux d'échantillonnage configurables

Il existe un certain nombre de taux d'échantillonnage que vous pouvez configurer dans l'infrastructure, mais ceux-ci sont les plus couramment utilisés.

Échantillons de processus

Les échantillons de processus constituent souvent la source de données la plus volumineuse provenant de l’agent d’infrastructure, car ils envoient des informations sur tout processus en cours d’exécution sur un hôte. Ils sont désactivés par défaut, mais vous pouvez les activer comme suit :

enable_process_metrics: true

Cela a le même effet que de définir metrics_process_sample_rate sur -1. Par défaut, les processus utilisant une faible mémoire sont exclus de l'échantillonnage. Pour plus d'informations, voir disable-zero-mem-process-filter.

Vous pouvez contrôler la quantité de données que vous envoyez en configurant include_matching_metrics, ce qui vous permet de restreindre la transmission de données métriques en fonction des valeurs de l'attribut métrique. Vous incluez des données métriques en définissant des valeurs littérales ou partielles pour l'un des attributs de la métrique. Par exemple, vous pouvez choisir d'envoyer le host.process.cpuPercent de tous les processus dont le process.name correspond aux ^java expressions régulières.

Dans cet exemple, nous incluons les métriques de processus à l'aide de fichiers exécutables et de noms :

include_matching_metrics:             # You can combine attributes from different metrics
    process.name:
      - regex "^java"                   # Include all processes starting with "java"
    process.executable:
      - "/usr/bin/python2"              # Include the Python 2.x executable
      - regex "\\System32\\svchost"     # Include all svchost executables

Vous pouvez également utiliser ce filtre pour l'intégration Kubernetes :

env:
    - name: NRIA_INCLUDE_MATCHING_METRICS
      value: |
        process.name:
          - regex "^java"
        process.executable:
          - "/usr/bin/python2"
          - regex "\\System32\\svchost"

Filtre d'interface réseau

La configuration utilise un mécanisme de recherche de modèles simple qui peut rechercher des interfaces commençant par une séquence spécifique de lettres ou de chiffres suivant l'un ou l'autre modèle :

• {name}[other characters]
• [number]{name}[other characters], où vous spécifiez le nom à l'aide de l'option index-1

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Filtres d'interface réseau par défaut pour Linux :

• Interfaces réseau commençant par dummy, lo, vmnet, sit, tun, tap ou veth
• Interfaces réseau contenant tun ou tap

Filtres d’interface réseau par défaut pour Windows :

• Interfaces réseau commençant par Loop, isatap ou Local

Pour remplacer les valeurs par défaut, incluez votre propre filtre dans le fichier de configuration :

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Les attributs personnalisés

Les attributs personnalisés sont des paires valeur-clé similaires aux balises dans d'autres outils utilisés pour annoter les données de l'agent infrastructure . Vous pouvez utiliser ces métadonnées pour créer des ensembles de filtres, regrouper vos résultats et annoter vos données. Par exemple, vous pouvez indiquer l'environnement d'une machine (simulation ou production), le service hôte d'une machine (service de connexion, par exemple) ou l'équipe responsable de cette machine.

Exemple d'attribut personnalisé de newrelic.yml

custom_attributes:
  environment: production
  service: billing
  team: alpha-team

Les systèmes complexes et décentralisés comme Kubernetes ont le potentiel de générer beaucoup de télémétrie en peu de temps. Il existe quelques bonnes approches pour gérer l’ingestion de données dans Kubernetes. Ceux-ci seront très simples si vous utilisez l'observabilité comme code dans votre déploiement K8s.

Nous vous recommandons vivement d'installer ce Kubernetes d'analyse d'ingestion de données dashboard avant de prendre toute décision concernant la réduction de l'ingestion. Pour obtenir ce dashboard, consultez le quickstart de l'intégration de l'infrastructure.

Intervalle de grattage

En fonction de vos objectifs d'observabilité, vous pouvez envisager d'ajuster l'intervalle de grattage, qui a une durée par défaut de 15 secondes. L'explorateur de cluster Kubernetes ne s'actualise que toutes les 45 s. Si votre utilisation principale des données Kubernetes est de prendre en charge les visualisations KCE, vous pouvez envisager de modifier votre intervalle de scraping à 20 s. Passer de 15 à 20 ans peut avoir un impact considérable.

Pour plus de détails sur la gestion de cela, consultez notre documentation sur l'intervalle de scraping de l'intégration Helm.

Filtrage de l'espace de nommage

L'intégration Kubernetes version 3 et supérieure permet de filtrer les espaces de nommage récupérés en les étiquetant. Par défaut, tous les espaces de nommage sont scrapés.

Nous utilisons le namespaceSelector de la même manière que Kubernetes. Pour inclure uniquement l'espace de nommage correspondant à une étiquette, modifiez le namespaceSelector en ajoutant ce qui suit à votre values-newrelic.yaml, sous la section newrelic-infrastructure :

common:
  config:
    namespaceSelector:
      matchLabels:
        key1 : "value1"

Dans cet exemple, seul l'espace de nommage avec l'étiquette newrelic.com/scrape définie sur true sera récupéré :

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchLabels:
          newrelic.com/scrape: "true"

Vous pouvez également utiliser des expressions de correspondance Kubernetes pour inclure ou exclure l'espace de nommage. Les opérateurs valides sont :

• Dans
• Pas dans
• Existe
• N'existe pas

La structure générale de la section matchExpressions est constituée d'une ou plusieurs des lignes suivantes :

{key: VALUE, operator: OPERATOR, values: LIST_OF_VALUES}

Voici un exemple complet :

common:
  config:
    namespaceSelector:
      matchExpressions:
      - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

Dans cet exemple, l'espace de nommage avec l'étiquette newrelic.com/scrape définie sur false sera exclu :

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchExpressions:
        - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

Consultez la liste complète des paramètres que vous pouvez définir dans le fichier README du graphique.

Comment puis-je savoir quels espaces de nommage sont exclus ? [#excluded-namespaces]

Tous les espaces de nommage au sein du cluster sont répertoriés grâce à l'échantillon K8sNamespace. L'attribut nrFiltered détermine si les données relatives à l'espace de nommage vont être récupérées.

Utilisez cette requête pour savoir quels espaces de nommage sont monitorés :

FROM K8sNamespaceSample SELECT displayName, nrFiltered
WHERE clusterName = INSERT_NAME_OF_CLUSTER SINCE
2 MINUTES AGO

Quelles données sont supprimées de l’espace de nommage exclu ? [#namespaces-discarded-data]

Les échantillons suivants ne seront pas disponibles pour l'espace de nommage exclu :

• K8sContainerSample
• K8sDaemonsetSample
• K8sDeploymentSample
• K8sEndpointSample
• K8sHpaSample
• K8sPodSample
• K8sReplicasetSample
• K8sServiceSample
• K8sStatefulsetSample
• K8sVolumeSample

Métriques d'état de Kubernetes

L'explorateur cluster Kubernetes ne nécessite que les métriques d'état Kube (KSM) suivantes :

• données du conteneur
• Données Cluster
• Données du nœud
• Données du pod
• Données de volume
• Données du serveur API¹
• Données du responsable du traitement¹
• Données ETCD¹
• Données du planificateur¹

¹ Non collecté dans un environnement Kubernetes géré (EKS, GKE, AKS, etc.)

Vous pouvez envisager de désactiver certains des éléments suivants :

• Données DaemonSet
• Données de déploiement
• données de point de terminaison
• espace de données de nommage
• Données du ReplicaSet²
• Données de service
• Données StatefulSet

² Utilisé dans l'alerte par défaut : « Le ReplicaSet n'a pas la quantité souhaitée de pod »

Exemple de mise à jour des métriques d'état dans le manifeste (déploiement)

$
[spec]
$
  [template]
$
    [spec]
$
      [containers]
$
        [name=kube-state-metrics]
$
        [args]
$
        #- --collectors=daemonsets
$
        #- --collectors=deployments
$
        #- --collectors=endpoints
$
        #- --collectors=namespaces
$
        #- --collectors=replicasets
$
        #- --collectors=services
$
        #- --collectors=statefulsets

Exemple de mise à jour des métriques d'état dans le manifeste (ClusterRole)

$
[rules]
$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - daemonsets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - deployments
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - endpoints
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - namespaces
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - replicasets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - services
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["apps"]
$
#   resources:
$
#   - statefulsets
$
#   verbs: ["list", "watch"]

Configurer lowDataMode dans le graphique nri-bundle

Nos cartes Helm prennent en charge l'option permettant de réduire la quantité de données ingérées au prix de la suppression d'informations détaillées. Pour l'activer, définissez global.lowDataMode sur true dans le graphique nri-bundle .

lowDataMode affecte trois composants spécifiques du graphique nri-bundle :

1. Augmentez l’intervalle de l’agent d’infrastructure de 15 à 30 secondes.
2. L'intégration de Prometheus OpenMetrics exclura quelques métriques comme indiqué dans la documentation Helm ci-dessous.
3. Les détails des étiquettes et des annotations seront supprimés des logs.

Vous pouvez trouver plus de détails sur cette configuration dans notre documentation Helm.

Les intégrations sur hôte de New Relic représentent un ensemble diversifié d'intégrations pour des services tiers tels que Postgresql, MySQL, Kafka, RabbitMQ, etc. Il est impossible de fournir toutes les techniques d'optimisation dans le cadre de ce document, mais ces techniques s'appliquent généralement :

• Gérer le taux d'échantillonnage

• Gérer les parties de la configuration qui peuvent augmenter ou diminuer l'étendue de la collection

• Gérer les parties de la configuration qui permettent des requêtes personnalisées

• Gérez l'attribut personnalisé des agents infrastructure à appliquer à toutes les données d'intégration sur hôte.

  Nous utiliserons quelques exemples pour le démontrer.

  Intégration PostgreSQL

  Les moteurs de la croissance

  • Nombre de tables monitorées
  • Nombre d'indices monitorés

  La configuration de l'intégration PostgreSQL sur l'hôte fournit ces paramètres réglables qui peuvent aider à gérer le volume de données :

• interval: La valeur par défaut est 15 s

• COLLECTION_LIST: liste des tables à monitorer (utilisez ALL pour monitorer TOUTES)

• COLLECT_DB_LOCK_METRICS: Collecter dblock métriques

• PGBOUNCER: Collecter pgbouncer métriques

• COLLECT_BLOAT_METRICS: Collecter les métriques de gonflement

• METRICS: Définissez sur true pour collecter uniquement les métriques

• INVENTORY: Définissez sur true pour activer uniquement la collecte d'inventaire

• CUSTOM_METRICS_CONFIG:Fichier de configuration contenant une requête de collection personnalisée

  Sample config:

  integrations:
    - name: nri-postgresql
      env:
        USERNAME: postgres
        PASSWORD: pass
        HOSTNAME: psql-sample.localnet
        PORT: 6432
        DATABASE: postgres
        COLLECT_DB_LOCK_METRICS: false
        COLLECTION_LIST: '{"postgres":{"public":{"pg_table1":["pg_index1","pg_index2"],"pg_table2":[]}}}'
        TIMEOUT:  10
      interval: 15s
      labels:
        env: production
        role: postgresql
      inventory_source: config/postgresql

  Copier

  Intégration de Kafka

  Les moteurs de la croissance

  • Nombre de courtiers dans le cluster
  • Nombre de sujets dans le cluster

  La configuration de l'intégration Kafka sur l'hôte fournit ces paramètres réglables qui peuvent aider à gérer le volume de données :

• interval: La valeur par défaut est 15 s

• TOPIC_MODE:Détermine le nombre de sujets que nous collectons. Les options sont all, none, list ou regex.

• METRICS: Définissez sur true pour collecter uniquement les métriques

• INVENTORY: Définissez sur true pour activer uniquement la collecte d'inventaire

• TOPIC_LIST: Éventail JSON de noms de sujets à monitorer. Uniquement en vigueur si topic_mode est défini sur liste.

• COLLECT_TOPIC_SIZE: Collectez la taille du sujet métrique. Les options sont true ou false, la valeur par défaut est false.

• COLLECT_TOPIC_OFFSET:Collectez le décalage du sujet métrique. Les options sont true ou false, la valeur par défaut est false.

  La collecte de mesures au niveau du sujet, en particulier les décalages, peut nécessiter beaucoup de ressources et peut avoir un impact sur le volume de données. L'ingestion d'un cluster peut augmenter d'un ordre de grandeur simplement par l'ajout de nouvelles rubriques Kafka au cluster.

  Intégration de MongoDB

  Les moteurs de la croissance

  • Nombre de bases de données monitorées

  L'intégration MongoDB fournit ces paramètres réglables qui peuvent aider à gérer le volume de données :

• interval: La valeur par défaut est 15 s

• METRICS: Définissez sur true pour collecter uniquement les métriques

• INVENTORY: Définissez sur true pour activer uniquement la collecte d'inventaire

• FILTERS: Une cartographie JSON des noms de base de données vers un éventail de noms de collections. Si vide, la valeur par défaut est toutes les bases de données et collections.

  Pour toute intégration sur hôte que vous utilisez, il est important de connaître les paramètres tels que FILTERS , où la valeur par défaut est de collecter les métriques de toutes les bases de données. Il s’agit d’un domaine dans lequel vous pouvez utiliser vos priorités monitoring pour rationaliser les données collectées.

  Example configuration with different intervals for METRIC and INVENTORY:

  integrations:
    - name: nri-mongodb
      env:
        METRICS: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 15s
      labels:
        environment: production
  
    - name: nri-mongodb
      env:
        INVENTORY: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 60s
      labels:
        environment: production
      inventory_source: config/mongodb

  Copier

  Intégration Elasticsearch

  Les moteurs de la croissance

  • Nombre de nœuds dans le cluster
  • Nombre d'indices dans le cluster

  L'intégration Elasticsearch fournit ces paramètres réglables qui peuvent aider à gérer le volume de données :

• interval: La valeur par défaut est 15 s

• METRICS: Définissez sur true pour collecter uniquement les métriques

• INVENTORY: Définissez sur true pour activer uniquement la collecte d'inventaire

• COLLECT_INDICES: Indique s'il faut collecter ou non les métriques d'index.

• COLLECT_PRIMARIES:Indique s'il faut collecter ou non des métriques primaires.

• INDICES_REGEX: Filtrez les indices collectés.

• MASTER_ONLY:Collectez les métriques de cluster sur le maître élu uniquement.

  Example configuration with different intervals for METRICS and INVENTORY:

  integrations:
    - name: nri-elasticsearch
      env:
        METRICS: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        REMOTE_MONITORING: true
      interval: 15s
      labels:
        environment: production
  
    - name: nri-elasticsearch
      env:
        INVENTORY: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        CONFIG_PATH: /etc/elasticsearch/elasticsearch.yml
      interval: 60s
      labels:
        environment: production
      inventory_source: config/elasticsearch

  Copier

  Intégration JMX

  Les moteurs de la croissance

  • Métriques répertoriées dans COLLECTION_CONFIG

  L'intégration JMX est intrinsèquement générique. Il vous permet d'extraire des métriques de n'importe quelle instance JMX. Vous avez le contrôle sur ce qui est collecté par cette intégration. Dans certaines entreprises, les métriques JMX des environnements New Relic représentent une proportion relativement élevée de toutes les données collectées.

  L'intégration JMX fournit ces paramètres réglables qui peuvent aider à gérer le volume de données :

• interval: La valeur par défaut est 15 s

• METRICS: Définissez sur true pour collecter uniquement les métriques

• INVENTORY: Définissez sur true pour activer uniquement la collecte d'inventaire

• METRIC_LIMIT:Nombre de métriques pouvant être collectées par entité. Si cette limite est dépassée, l'entité ne sera pas signalée. Une limite de 0 implique aucune limite.

• LOCAL_ENTITY:Collectez toutes les métriques sur l’entité locale. Utilisé uniquement lors de monitoring de localhost.

• COLLECTION_FILES:Une liste séparée par des virgules des chemins d'accès complets aux fichiers de définition de la collection métrique. Pour l'installation sur l'hôte, le fichier de collecte de métriques JVM par défaut se trouve à /etc/newrelic-infra/integrations.d/jvm-metrics.yml.

• COLLECTION_CONFIG: configuration de la collection métriques en JSON.

  Ce sont les entrées COLLECTION_CONFIG qui régissent le plus la quantité de données ingérées. Comprendre le modèle JMX que vous récupérez vous aidera à l'optimiser.

  COLLECTION_CONFIG exemple pour les métriques JVM

  COLLECTION_CONFIG='{"collect":[{"domain":"java.lang","event_type":"JVMSample","beans":[{"query":"type=GarbageCollector,name=*","attributes":["CollectionCount","CollectionTime"]},{"query":"type=Memory","attributes":["HeapMemoryUsage.Committed","HeapMemoryUsage.Init","HeapMemoryUsage.Max","HeapMemoryUsage.Used","NonHeapMemoryUsage.Committed","NonHeapMemoryUsage.Init","NonHeapMemoryUsage.Max","NonHeapMemoryUsage.Used"]},{"query":"type=Threading","attributes":["ThreadCount","TotalStartedThreadCount"]},{"query":"type=ClassLoading","attributes":["LoadedClassCount"]},{"query":"type=Compilation","attributes":["TotalCompilationTime"]}]}]}'

  Copier

  L’omission d’une entrée de cette configuration, telle que NonHeapMemoryUsage.Init , aura un impact tangible sur le volume global de données collectées.

  COLLECTION_CONFIG exemple pour les métriques Tomcat

  COLLECTION_CONFIG={"collect":[{"domain":"Catalina","event_type":"TomcatSample","beans":[{"query":"type=UtilityExecutor","attributes":["completedTaskCount"]}]}]}

  Copier

  Autre intégration sur hôte

  Il existe de nombreuses autres intégrations sur hôte avec des options configuration qui vous aideront à optimiser la collecte. Certains des plus couramment utilisés sont :

• NGINX

• MySQL

• Redis

• Apache

• RabbitMQ

  C'est un bon point de départ pour en savoir plus.

Cette section se concentre sur monitoring des performances du réseau de New Relic qui s'appuie sur l'agent ktranslate de Kentik. Cet agent est assez sophistiqué et il est important de bien comprendre les documents de configuration avancés avant de procéder à des efforts d'optimisation majeurs. Les options de configuration incluent :

• mibs_enabled: éventail de tous les MIB actifs que l'image docker KTranslate va interroger. Cette liste est générée automatiquement lors de la découverte si l'attribut discovery_add_mibs est true. Les MIB non répertoriés ici ne seront interrogés sur aucun périphérique dans le fichier de configuration. Vous pouvez spécifier une table SNMP directement dans un fichier MIB en utilisant la syntaxe MIB-NAME.tableName . Ex : HOST-RESOURCES-MIB.hrProcessorTable.

• user_tags: valeur clé paire d'attributs pour donner plus de contexte à l'appareil. La balise à ce niveau sera appliquée à tous les périphériques du fichier configuration .

• devices: Section répertoriant les appareils à monitorer pour le débit

• traps: configure l'IP et les ports à monitorer avec des interruptions SNMP (la valeur par défaut est 127.0.0.1:1162)

• discovery: configure la manière dont le point de terminaison peut être découvert. Dans cette section, les paramètres suivants contribueront le plus à augmenter ou à diminuer la portée :

  • cidrs: éventail de plages d'adresses IP cibles en notation CIDR.
  • ports: éventail de ports cibles à analyser lors de l'interrogation SNMP.
  • debug: Indique s'il faut activer le logging au niveau de débogage pendant la découverte. Par défaut, il est défini sur false
  • default_communities: éventail de chaînes de communauté SNMPv1/v2c à analyser pendant l'interrogation SNMP. Cet éventail est évalué dans l'ordre et la découverte accepte la première communauté passante.

  Pour prendre en charge le filtrage des données qui ne créent pas de valeur pour vos besoins d'observabilité, vous pouvez définir la carte d'attributs global.match_attributes.{} et/ou devices.<deviceName>.match_attributes.{} .

  Cela fournira un filtrage au niveau de KTranslate, avant d'envoyer des données à New Relic, vous donnant un contrôle précis sur monitoring d'éléments tels que les interfaces.

  Pour plus de détails, voir des performances du réseau monitoring configuration.

Les logs représentent l'une des sources de télémétrie les plus flexibles dans la mesure où nous acheminons généralement les logs via une couche de transfert dédiée avec ses propres règles de routage et de transformation. Comme il existe une grande variété de transitaires, nous nous concentrerons sur les plus couramment utilisés :

• Agents linguistiques APM (versions récentes)

• Fluentd

• Fluentbit

• Agent d'infrastructure New Relic ( Fluentbit intégré)

• Logstash

  Échantillonnage log de l'agent APM

  Les versions récentes des agents de langage New Relic peuvent transmettre les logs directement à New Relic. Vous souhaiterez peut-être définir certaines limites quant à l'ampleur des pics de logging de chaque instance d'agent APM.

  Vous pouvez activer l'échantillonnage avec la variable d'environnement NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED et la configurer en fournissant le nombre maximal de logs que la file d'attente de logging des agents APM stockera. Il fonctionne sur la base d'une file d'attente de priorité personnalisée et donne à tous les messages du log une priorité. les logs qui se produisent dans une transaction obtiennent la priorité de la transaction.

  La file d'attente des logs est triée en fonction de la priorité et du moment où le log arrive. La priorité la plus élevée passe en premier et, si nécessaire, le log le plus récent a la priorité. Les logs sont ajoutés individuellement à la file d'attente (même ceux d'une transaction), et une fois la limite atteinte, le log à la fin de la file d'attente est poussé vers l'extérieur en faveur du log le plus récent.

  Dans la section ressources ci-dessous, il existe un qui vous aide à quickstart dashboard suivre log le volume de manière simple. Le volume log de suivi vous permettra d'ajuster ou de désactiver le taux d'échantillonnage en fonction de vos besoins d'observabilité.

  Configuration des filtres dans Fluentd ou Fluentbit

  La plupart des transitaires généraux fournissent un workflowde routage assez complet qui inclut le filtrage et la transformation. Notre agent infrastructure fournit des modèles très simples pour filtrer les logs indésirables.

  expressions régulières pour filtrer les enregistrements. Uniquement pris en charge pour les sources tail, systemd, syslog et tcp (uniquement avec le format none). Ce champ fonctionne de manière similaire à grep -E dans le système Unix. Par exemple, pour un fichier donné en cours de capture, vous pouvez filtrer les enregistrements contenant soit WARN soit ERROR en utilisant :

  - name: only-records-with-warn-and-error
      file: /var/log/logFile.log
      pattern: WARN|ERROR

  Copier

  Si vous avez une configuration Fluentd pré-écrite pour Fluentbit qui effectue un filtrage ou une analyse précieuse, vous pouvez les importer dans notre configuration de logging. Pour ce faire, utilisez les paramètres config_file et parsers dans n'importe quel fichier .yaml de votre dossier logging.d :

• config_file: chemin vers un fichier de configuration Fluent Bit existant. Tout chevauchement de source entraîne des messages en double dans gestion des logsde New Relic.

• parsers_file: chemin vers un fichier d'analyse Fluent Bit existant.

  Les noms d’analyseurs suivants sont réservés : rfc3164, rfc3164-local et rfc5424.

  Apprendre à injecter un attribut ou une balise dans vos logs dans votre pipeline de données et à effectuer des transformations peut vous aider à supprimer les fonctionnalités en aval à l'aide des règles de suppression New Relic. En augmentant vos logs avec des métadonnées sur la source, nous pouvons prendre des décisions centralisées et réversibles sur ce qu'il faut déposer sur le backend. Au minimum, assurez-vous que les attributs suivants sont présents dans vos logs sous une forme ou une autre :

• Équipe

• Environnement (développement/stage/production)

• Application

• centre de données

• niveau de log

  Vous trouverez ci-dessous quelques ressources détaillées de routage et de filtrage :

• Filtres et modèles de routage courants dans Fluentd

• Fluentbit de données pipeline

• Transfert des logs avec l'agent New Relic Infrastructure

  Ajuster l'ensemble d'attributs par défaut de l'agent infrastructure

  L'agent infrastructure ajoute certains attributs par défaut, y compris toute balise personnalisée ajoutée à l'hôte. Il est possible que votre configuration en intègre bien plus, y compris un grand nombre de balises AWS, qui apparaissent dans New Relic sous la forme aws.[attributename]. Ces attributs sont importants, il est donc fortement recommandé d'évaluer vos besoins en matière de visualisation, d'analyse et d'alerte par rapport aux modifications configuration prévues. Par exemple, les logs d'un cluster Kubernetes ne seront probablement pas utiles sans métadonnées telles que :

• cluster_name

• pod_name

• container_name

• node_name

New Relic fournit deux options principales pour envoyer des métriques Prometheus à New Relic. Les bonnes pratiques pour la gestion de l'ingestion métrique se concentrent principalement sur la deuxième option - l'intégration Prometheus OpenMetrics (POMI) - car ce composant a été créé par New Relic.

Option 1 : Intégration de l'écriture à distancePrometheus

Pour les options de configuration du scraping du serveur Prometheus, consultez la documentation de configuration de Prometheus. Ces configurations de scraping déterminent quelles métriques sont collectées par le serveur Prometheus. En configurant le paramètre remote_write , vous pouvez écrire les métriques collectées dans la base de données New Relic (NRDB) via l'API métrique New Relic.

Option 2 : intégration dePrometheus OpenMetrics (POMI)

POMI est une intégration autonome qui récupère les métriques des points de terminaison Prometheus découverts dynamiquement et statiques. POMI envoie ensuite ces données à NRDB via l'API métrique New Relic. Cette intégration est idéale pour les clients qui n'utilisent pas actuellement le serveur Prometheus.

POMI : gratter l'étiquette

POMI découvrira tout point de terminaison Prometheus contenant l'étiquette ou l'annotation prometheus.io/scrape=true par défaut. Cela peut être un grand nombre de points de terminaison et donc, un grand nombre de métriques ingérées, en fonction de ce qui est déployé dans le cluster.

Il est suggéré de modifier le paramètre scrape_enabled_label en quelque chose de personnalisé (par exemple newrelic/scrape) et que vous étiquetiez de manière sélective le point de terminaison Prometheus lorsque l'ingestion de données est de la plus haute importance.

Pour la dernière configuration de référence, voir nri-prometheus-latest.yaml.

POMI config parameter:

# Label used to identify scrapable targets. 
# Defaults to "prometheus.io/scrape"
  scrape_enabled_label: "prometheus.io/scrape"

POMI découvrira tout point de terminaison Prometheus exposé au niveau du nœud par défaut. Cela inclut généralement des métriques provenant de Kubelet et de cAdvisor. Si vous exécutez le Daemonset New Relic Kubernetes, il est important de définir require_scrape_enabled_label_for_nodes: true afin que POMI ne collecte pas de métriques en double.

Pour le point de terminaison cible du Daemonset New Relic Kubernetes , consultez notre Kubernetes README sur GitHub.

POMI : étiquette de scraping pour les nœuds

POMI découvrira tout point de terminaison Prometheus exposé au niveau du nœud par défaut. Cela inclut généralement des métriques provenant de Kubelet et de cAdvisor. Si vous exécutez le Daemonset New Relic Kubernetes, il est important de définir require_scrape_enabled_label_for_nodes: true afin que POMI ne collecte pas de métriques en double.

Pour le point de terminaison cible du Daemonset New Relic Kubernetes , consultez notre Kubernetes README sur GitHub.

Paramètres de configuration POMI

# Whether k8s nodes need to be labeled to be scraped or not. 
# Defaults to false.
  require_scrape_enabled_label_for_nodes: false

POMI : coexister avec nri-kubernetes

L'intégration Kubernetes de New Relic collecte un certain nombre de mesures prêtes à l'emploi. Cependant, il ne collecte pas toutes les métriques possibles disponibles à partir d'un cluster Kubernetes.

Dans la configuration POMI, vous verrez une section similaire à celle-ci qui collectera disable métriques pour un sous-ensemble de métriques que l'intégration New Relic Kubernetes collecte déjà à partir de Kube State Metrics.

Il est également très important de définir require_scrape_enabled_label_for_node: true afin que les métriques Kubelet et cAdvisor ne soient pas dupliquées.

POMI config parameters:

transformations:
    - description: "Uncomment if running New Relic Kubernetes integration"
      ignore_metrics:
        - prefixes:
          - kube_daemonset_
          - kube_deployment_
          - kube_endpoint_
          - kube_namespace_
          - kube_node_
          - kube_persistentvolume_
          - kube_persistentvolumeclaim_
          - kube_pod_
          - kube_replicaset_
          - kube_service_
          - kube_statefulset_

POMI : paramètres de demande/limite

Lors de l'exécution de POMI, il est recommandé d'appliquer les limites de ressources suivantes pour un cluster générant environ 500 000 DPM :

• Limite du processeur : 1 cœur (1000 m)
• Limite de mémoire : 1 Go 1024 (1 Go)

Vous devez définir la demande de ressources pour le processeur et la mémoire afin de fournir à POMI suffisamment de ressources du cluster. Régler ceci sur quelque chose d'extrêmement bas (par exemple cpu: 50m) peut entraîner la consommation de ressources de cluster par des « voisins bruyants ».

POMI config parameter:

spec:
  serviceAccountName: nri-prometheus
  containers:
  - name: nri-prometheus
    image: newrelic/nri-prometheus:2.2.0
    resources:
      requests:
        memory: 512Mi
        cpu: 500m
      limits:
        memory: 1G
        cpu: 1000m

POMI : estimation du DPM et de la cardinalité

Bien que la cardinalité ne soit pas directement associée à l'ingestion facturable par Go, New Relic maintient certaines limites de débit sur la cardinalité et les points de données par minute. Être capable de visualiser la cardinalité et le DPM d'un cluster Prometheus peut être très important.

Si vous exécutez déjà Prometheus Server, vous pouvez exécuter des estimations DPM et de cardinalité avant d'activer POMI ou remote_write.

Data points per minute (DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 metrics (highest cardinality):

topk(20, count by (<DNT>**name**</DNT>, job)({__name__=~".+"}))

Certaines intégrations cloud New Relic obtiennent des données à partir des API des fournisseurs cloud . Avec cette implémentation, les données sont collectées à partir d'API monitoring telles que AWS CloudWatch, Azure Monitor et GCP Stackdriver, et les métadonnées d'inventaire sont collectées à partir des API des services spécifiques.

D'autres cloud d'intégration obtiennent leurs données à partir de métriques en streaming (ou métriques « poussées ») qui sont poussées via un service de streaming tel qu'AWS Kinesis.

Intégration basée sur l'API de sondage

Si vous souhaitez signaler plus ou moins de données de votre cloud d'intégration, ou si vous devez contrôler l'utilisation des API des fournisseurs cloud pour éviter d'atteindre le débit limite et les limites de limitation de votre compte cloud , vous pouvez modifier les paramètres de configuration pour modifier la quantité de données qu'ils signalent. Les deux principaux contrôles sont :

• Modifier la fréquence de sondage

• Modifier les données rapportées

  Voici quelques exemples de raisons commerciales pour lesquelles vous souhaitez modifier la fréquence de vos sondages :

• Billing:Si vous devez gérer votre facture AWS CloudWatch, vous souhaiterez peut-être diminuer la fréquence d'interrogation. Avant de faire cela, assurez-vous que les conditions d'alerte définies pour votre cloud d'intégration ne sont pas affectées par cette réduction.

• New services:Si vous déployez un nouveau service ou une nouvelle configuration et que vous souhaitez collecter des données plus souvent, vous souhaiterez peut-être augmenter temporairement la fréquence d'interrogation.

  Prudence

  La modification des paramètres configuration de votre intégration peut avoir un impact sur l'état d'alerte et les tendances des graphiques.

  Pour plus de détails, voir Configurer l'interrogation.

  Métriques « streaming » ou « poussées »

  De plus en plus cloud d'intégration offrent la possibilité de faire circuler les données via un service de streaming au lieu d'utiliser l'interrogation API, ce qui réduit considérablement la latence. Un problème que certains utilisateurs ont observé est qu'il n'est pas aussi facile de contrôler le volume car vous ne pouvez pas configurer la fréquence d'échantillonnage.

  Les règles New Relic pour la suppression des données sont le principal moyen de filtrer les métriques de streaming avec un volume trop élevé. Cependant, il existe certaines choses que vous pouvez faire du côté du fournisseur de cloud pour aider à limiter le volume de flux.

  Par exemple, dans AWS, il est possible d'utiliser des clés de condition pour limiter l'accès à l'espace de nommage CloudWatch.

  La politique suivante limite l'utilisateur à publier des métriques uniquement dans l'espace de nommage nommé MyCustomNamespace:

  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Resource": "*",
      "Action": "cloudwatch:PutMetricData",
      "Condition": {
        "StringEquals": {
          "cloudwatch:namespace": "MyCustomNamespace"
        }
      }
    }
  }

  Copier

  La politique suivante permet à l'utilisateur de publier des métriques dans n'importe quel espace de nommage à l'exception de CustomNamespace2:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData"
      },
      {
        "Effect": "Deny",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData",
        "Condition": {
          "StringEquals": {
            "cloudwatch:namespace": "CustomNamespace2"
          }
        }
      }
    ]
  }

  Copier

Toutes les règles de dépôt de New Relic sont implémentées par le même modèle de données backend et la même API. Notre gestion des logs fournit une interface utilisateur puissante qui facilite grandement la création et le monitoring des règles de dépôt.

Précédemment dans cette série de didacticiels, nous avons abordé la priorisation de la télémétrie en exécutant quelques exercices pour montrer comment nous pourrions déprécier certaines données. Reprenons cet exemple :

Omit debug logs (knowing they can be turned on if there is an issue) (saves 5%)

Méthode 1 : UI des logs

• Identifiez les logs qui nous intéressent à l’aide d’un filtre dans l’interface utilisateur des logs : level: DEBUG.
• Assurez-vous qu'il trouve les logs que nous voulons supprimer.
• Vérifiez quelques syntaxes alternatives telles que level:debug et log_level:Debug. Ces variations sont courantes.
• Sous Manage data, cliquez sur Drop filters, puis créez et activez un filtre nommé « Supprimer les logs de débogage ».
• Vérifiez que la règle fonctionne.

Méthode 2 : Notre API NerdGraph

• Créez la requête NRQL pertinente :

  SELECT count(*) FROM Log WHERE `level` = 'DEBUG'

  Copier
• Assurez-vous qu'il trouve les logs que vous souhaitez supprimer.
• Vérifiez les variations sur le nom et la valeur de l'attribut (Debug vs DEBUG).
• Exécutez l’instruction NerdGraph suivante et assurez-vous qu’elle fonctionne :

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM Log WHERE `level` = 'DEBUG'"
        description: "Drops DEBUG logs.  Disable if needed for troubleshooting."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Implémentons la recommandation : Drop process sample data in DEV environments.

• Créez la requête pertinente :

  SELECT * FROM ProcessSample WHERE `env` = 'DEV'

  Copier

• Assurez-vous qu’il trouve les échantillons de processus que nous voulons supprimer.

• Recherchez d’autres variantes de env telles que ENV et Environment.

• Vérifiez différents types de DEV tels que Dev et Development.

• Utilisez notre API NerdGraph pour exécuter l’instruction suivante et vous assurer qu’elle fonctionne :

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM ProcessSample WHERE `env` = 'DEV'"
          description: "Drops ProcessSample from development environments"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  Copier

Vous pouvez souvent réduire votre consommation de données en réduisant les données avec une couverture redondante. Par exemple : dans un environnement où l'intégration AWS RDS est en cours d'exécution ainsi que l'une des intégrations New Relic sur l'hôte qui monitore la base de données SQL telle que nri-mysql ou nri-postgresql, vous pourrez peut-être ignorer certaines métriques qui se chevauchent.

Par exemple, vous pouvez exécuter une requête comme celle-ci :

FROM Metric select count(*) where metricName like 'aws.rds%' facet metricName limit max

Cela affichera toutes les valeurs metricName correspondant au modèle.

Vous pouvez voir à partir des résultats qu'il existe un volume élevé de métriques du modèle aws.rds.cpu%. Vous pouvez les abandonner car vous avez d'autres instruments pour ceux-là :

• Créez la requête pertinente :

  FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago

  Copier

• Assurez-vous qu'il trouve les échantillons de processus que vous souhaitez supprimer.

• Utilisez l'API NerdGraph pour exécuter l'instruction suivante et assurez-vous qu'elle fonctionne :

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago"
          description: "Drops rds cpu related metrics"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  Copier

Un aspect important des règles de suppression est que vous pouvez configurer une règle qui supprime un attribut spécifique tout en préservant l’intégrité du reste des données. Utilisez ceci pour supprimer des données privées de NRDB ou pour supprimer des attributs excessivement volumineux, tels que des traces d'appels ou de gros morceaux de JSON dans des enregistrements log excessivement volumineux.

Pour définir ces règles de suppression, modifiez le champ action en DROP_ATTRIBUTES au lieu de DROP_DATA.

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT stack_trace, json_data FROM Log where appName='myApp'"
        description: "Drops large fields from logs for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Dans cet exemple, vous pouvez tirer parti de la distribution relative de certains identifiants de trace pour approximer l'échantillonnage aléatoire. Vous pouvez utiliser l'opérateur rlike pour vérifier les valeurs principales de l'attribut trace.id d'un span. L'exemple suivant pourrait supprimer environ 25 % des portées :

SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'

Les expressions utiles incluent :

• r'.*0' environ 6,25 %

• r'.*[0-1]' environ 12,5 %

• r'.*[0-2]' environ 18,75 %

• r'.*[0-3]' environ 25,0 %

  Après avoir épuisé les chiffres, vous pouvez utiliser des lettres, par exemple :

• r'.*[a0-9]' environ 68,75 %

• r'.*[a-b0-9]' environ 75,0 %

  Voici un exemple de mutation complète :

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'"
          description: "Drops approximately 25% of spans for myApp"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  Copier

  Conseil

  Étant donné que les trace.idsont des nombres hexadécimaux, chaque caractère de trace.id est une valeur de 0123456789abcdef. Chaque caractère que vous ajoutez au modèle RLIKE correspondra à 1/16 supplémentaire des lignes de l'événement span, en supposant que les caractères finaux aient une distribution uniforme. Si vous ajoutez des lettres au-delà de F qui ne sont pas utilisées en hexadécimal, les chiffres ajoutés n'affecteront pas le pourcentage correspondant.

Les exemples précédents devraient vous montrer tout ce que vous devez savoir pour utiliser ces techniques sur tout autre événement ou métrique dans NRDB. N'oubliez pas : si vous pouvez le demander, vous pouvez le supprimer. Contactez-nous si vous avez des questions sur la manière précise de structurer une requête pour une règle de suppression.