Optimisez votre ingestion de données

Un compte ingère environ 20 % de plus que ce qui avait été budgété. Un responsable leur a demandé de trouver un moyen de réduire la consommation. Leur facteur de valeur le plus important est le temps de disponibilité, les performances et la fiabilité.

Leur patrimoine comprend :

• APM(développement, simulation, production)

• Tracing distribué

• Navigateur

• monitoring d'infrastructure de 100 hôtes

• monitoring K8s (développement, simulation, production)

• Logs (développement, simulation, production - y compris débogage)

  Plan d'optimisation

  • Omettre les logs de débogage (sachant qu'il peut être activé en cas de problème) (économise 5 %)
  • Omettre plusieurs métriques d'état K8 qui ne sont pas nécessaires pour afficher cluster Kubernetes l'explorateur (économise 10 %)
  • Supprimez quelques événements Browser personnalisés qu'ils collectaient à l'époque où ils effectuaient de nombreux tests A/B de nouvelles fonctionnalités (économisez 10 %)

  Après avoir exécuté ces changements, l'équipe est à 5 % en dessous de son budget et a libéré de l'espace pour faire un pilote NPM. Leur responsable est convaincu qu'ils ne perdent pas de temps significatif de disponibilité et d'observabilité de fiabilité.

  Résultat final

  • 5% en dessous de leur budget initial
  • Marge de manœuvre créée pour un pilote NPM qui répond aux objectifs de temps de disponibilité, de performance et de fiabilité
  • Perte minimale de temps de disponibilité et de fiabilité observabilité

Une équipe responsable d'une nouvelle plateforme orientée utilisateur mettant l'accent sur monitoring des applications mobiles et monitoring des navigateurs fonctionne à 50 % au-dessus du budget. Ils devront adapter leur ingestion, mais ils sont déterminés à ne sacrifier aucune observabilité de l'expérience client .

Leur patrimoine comprend :

• Applications mobiles

• Navigateur

• APM

• Tracing distribué

• infrastructure sur 30 hôtes, incluant des échantillons de processus

• monitoring sans serveur pour certains processus asynchrones backend

• Logs de leur fonction sans serveur

• Diverses intégrations cloud

  Plan d'optimisation

  • Omettez les logs sans serveur (ils sont fondamentalement redondants par rapport à ce qu'ils obtiennent de leur intégration Lambda )
  • Réduisez le taux d'échantillonnage du processus sur leurs hôtes à chaque minute
  • Supprimer des données d'échantillon de processus dans des environnements DEV
  • Désactivez l'intégration EC2 qui est hautement redondante avec les autres monitoring deinfrastructure fournies par l'agent d'infrastructure New Relic.

  Résultat final

  • 5% de plus que leur budget initial
  • Suffisant pour les faire passer à travers la haute saison
  • Aucune perte d'observabilité de l'expérience client

  Après avoir effectué les changements, ils n'ont désormais dépassé que de 5 % leur budget initial, mais ils concluent que cela sera suffisant pour traverser la haute saison.

Une équipe est en train de refactoring un grand monolithe Python en quatre microservices. Le monolithe partage de nombreuses infrastructure avec la nouvelle architecture, notamment une base de données clients et une couche de cache. Ils ont dépassé de 70 % le budget prévu et il leur reste deux mois avant de pouvoir officiellement démanteler le monolithe.

Leur patrimoine comprend :

• monitoring K8s (microservices)

• monitoring de l'hôte New Relic (monolithe)

• APM (microservices et monitoring d'hôte)

• Tracing distribué (microservices et monitoring des hôtes )

• Postgresql (partagé)

• Redis (partagé)

• MSSQL (future base de données pour l'architecture des microservices)

• Logging de l'équilibreur de charge (microservices et monitoring de l'hôte)

  Plan d'optimisation

  • Configurer le logging de l'équilibreur de charge pour monitorer uniquement les codes de réponse 5xx (monolithe)
  • Taux d'échantillonnage personnalisé sur ProcessSample, StorageSample et NetworkSample jusqu'à 60 s pour les hôtes exécutant le monolithe
  • Désactivez monitoring MSSQL car actuellement la nouvelle architecture ne l'utilise pas.
  • Désactivez le tracing distribué pour le monolithe car il est beaucoup moins utile qu'il ne le sera pour l'architecture des microservices.

  Résultat final

  • 1% en dessous de leur budget initial
  • Aucune perte d'observabilité de l'innovation et de la croissance

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 pour soutenir l'entreprise, il est possible que vous puissiez être plus économe dans votre architecture globale. Dans un cas extrême, vous pouvez avoir un microservice de profil utilisateur qui est 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. Cependant, un levier à notre disposition est de réduire la fréquence des appels à ce service à, par exemple, toutes les minutes.

  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. Elles sont souvent utiles, mais à mesure que la logique et les priorités de l’application changent, les données 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 des informations supplémentaires (potentiellement des en-têtes plus détaillés).

  Pour un exemple de la riche configuration disponible en relation avec APM, consultez notre documentation sur l'agent Java

  Événement d'erreur

  Il est possible de déterminer comment les erreurs seront gérées par APM. Cela peut réduire le volume de données dans certains cas. Il peut par exemple s’agir d’une erreur importante mais inoffensive qui ne peut pas être supprimée pour le moment.

  Nous avons la capacité de collect, ignore ou mark as expected. 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 que nous avons définie. Nous avons un certain contrôle sur le degré de verbosité monitoring des requêtes de base de données. Ces requêtes apparaîtront dans la page de trace de transaction.

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

• Collecter des données de requête brutes au lieu de les masquer ou de désactiver la collecte de requêtes

• Modification du seuil de trace d'appel

• Activation de la collecte de plans d'explication de requête

  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 sur le nombre d'événements pouvant être signalés par cycle de collecte. S'il n'y avait pas de limite, un très grand nombre d'événements envoyés pourrait avoir un impact sur les performances de votre application ou de New Relic. Lorsque la limite est atteinte, les agents commencent à échantillonner les événements afin de donner un échantillon représentatif des événements tout au long du cycle de collecte. Différents agents ont des limites différentes.

  Les événements plafonnés et sujets à échantillonnage comprennent :

• é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 détermine le nombre d'événements échantillonnés qui peuvent ê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, veuillez lire ces mises en garde et recommandations :

• 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 déterminer si les é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. Dans certains cas, vous souhaiterez peut-être définir certaines limites quant à l'ampleur des pics du 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 configuration des transactions commerciales. Dans de nombreux cas, 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é

  La configuration de tracing distribué présente certaines différences spécifiques à chaque langue.

  Le tracing distribué peut être désactivé selon les 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 aux agents APM (ci-dessus) capture jusqu'à 10 % de votre trace, mais si vous souhaitez que nous analysions toutes vos données et trouvions la trace la plus pertinente, vous pouvez configurer 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

Les demandes peuvent être bloquées 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 sur 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 à New Relic 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é.

Les indicateurs de fonctionnalité suivants peuvent être configurés :

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 de New Relic contient quelques méthodes puissantes pour 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 qui peuvent être ajustées. De plus, il est possible de créer des expressions régulières pour contrôler ce qui est collecté à partir de certains collecteurs tels que pour ProcessSample et NetworkSample.

Taux d'échantillonnage configurables

Il existe un certain nombre de taux d'échantillonnage qui peuvent être configurés dans l'infrastructure, mais ceux-ci sont les plus couramment utilisés.

Échantillons de processus

Les échantillons de processus peuvent constituer la source de données à volume le plus élevé provenant de l’agent d’infrastructure. C'est parce qu'il enverra des informations sur tout processus en cours d'exécution sur un hôte. Ils sont désactivés par défaut mais ils peuvent être activés 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 peu de 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 envoyées à New Relic 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"

Un exclude_matching_metrics est disponible et fonctionne de manière similaire pour exclure les données métriques.

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ées 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

Ils sont puissants et utiles, mais si les données ne sont pas bien organisées ou sont devenues obsolètes de quelque manière que ce soit, vous devriez envisager de les rationaliser.

Il n’est pas surprenant qu’un système complexe et décentralisé comme Kubernetes ait le potentiel de générer rapidement beaucoup de télémétrie. 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 des décisions concernant la réduction de l'ingestion de K8. 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. La valeur par défaut est 15 s. Désormais, l'explorateur de cluster Kubernetes ne s'actualise que toutes les 45 s. Si votre utilisation principale des données K8s est de prendre en charge les visualisations KCE, vous pouvez envisager de modifier votre intervalle de grattage à 20 s. Ce passage 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 v3 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 grattés.

Nous utilisons le namespaceSelector de la même manière que Kubernetes. Afin d'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 pouvant être modifiés 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 de l'état du Kube

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 la définition d'une 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 n'est pas possible de fournir toutes les techniques d'optimisation dans le cadre de ce document, mais nous pouvons fournir ces techniques généralement applicables :

• 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 car ils seront appliqués à 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

  Exemple de configuration :

  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.

  Il convient de noter que 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. Il est très possible que l’ingestion d’un cluster puisse 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.

  Exemple configuration avec des intervalles différents pour métrique et INVENTAIRE :

  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.

  Exemple de configuration avec des intervalles différents pour METRICS et 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 nous permet d'extraire des métriques de n'importe quelle instance JMX. Nous avons un bon contrôle sur ce qui est collecté par cette intégration. Dans certains environnements New Relic d'entreprise, les métriques JMX 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. Dans certains cas, vous souhaiterez peut-être définir certaines limites quant à l'ampleur des pics du logging de chaque instance d'agent APM.

  Nous pouvons activer l'échantillonnage avec la variable d'environnement NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED

  Il est configuré simplement en fournissant le nombre maximal de logs qui seront stockés dans la file d'attente du logging des agents APM. Il fonctionne sur la base d’une file d’attente prioritaire personnalisée. Tous les messages du log sont prioritaires. les logs qui se produisent dans une transaction obtiennent la priorité de la transaction.j

  La file d'attente pour les logs est triée en fonction de la priorité et du moment où le log arrive. La priorité la plus élevée l'emporte et, si nécessaire, le log le plus récent gagnera (nous gardons un compte pour chaque entrée dans la file d'attente). Les logs sont ajoutés individuellement à la file d'attente (même ceux d'une transaction) et lorsque la limite est 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, vous trouverez un quickstart dashboard qui vous aide à 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. L'agent infrastructure de New Relic 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 aucun). 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 des configurations Fluentd pré-écrites pour Fluentbit qui effectuent un filtrage ou une analyse précieux, vous pouvez les importer dans notre configuration du logging New Relic. 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 la gestion des logs de 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 facilement 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 pour une observabilité optimale, il est donc fortement recommandé d'évaluer vos besoins en matière de visualisation, d'analyse et d'alerte à la lumière de toute modification configuration prévue. 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 de gestion de l'ingestion métrique dans ce document se concentreront principalement sur l'option 2 - 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 , les métriques collectées peuvent être écrites 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 Prometheus Server.

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. En fonction de ce qui est déployé dans le cluster, cela peut représenter un grand nombre de points de terminaison et donc un grand nombre de métriques ingérées.

Il est suggéré que le paramètre scrape_enabled_label soit modifié en quelque chose de personnalisé (par exemple newrelic/scrape) et que le point de terminaison Prometheus soit étiqueté ou annoté de manière sélective 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.

Paramètre de configuration POMI :

# 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 désactivera la collecte de métriques pour un sous-ensemble de métriques que l'intégration New Relic Kubernetes collecte déjà à partir de Kube State Métriques.

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.

Paramètres de configuration POMI :

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)

La demande de ressources pour le processeur et la mémoire doit être définie à un niveau raisonnable afin que POMI reçoive 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 ».

Paramètre de configuration POMI :

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 y exécuter des estimations de DPM et de cardinalité avant d'activer POMI ou remote_write.

Points de données par minute (DPM) :

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 métriques (forte cardinalité) :

topk(20, count by (**name**, 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 généralement 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 à partir de votre cloud d'intégration, ou si vous devez contrôler l'utilisation des API des fournisseurs cloud pour éviter d'atteindre les limites de débit et de limitation de votre compte cloud , vous pouvez modifier les paramètres 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 :

• Facturation: 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 toutes les conditions d'alerte définies pour votre cloud d'intégration ne sont pas affectées par cette réduction.

• Nouveaux 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. Cela s’est avéré réduire 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 le taux d'échantillonnage ne peut pas être configuré.

  Les règles de New Relic concernant la suppression de données seront bien abordées dans la section suivante. Ils constituent le principal moyen de filtrer les mesures de streaming dont le volume est trop élevé. Cependant, certaines mesures peuvent être prises du côté du fournisseur de cloud pour limiter quelque peu le volume du 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. Cependant, la gestion des log New Relic fournit une interface utilisateur puissante qui facilite grandement la création et le monitoring des règles de dépôt.

Dans notre section précédente sur la priorisation de la télémétrie, nous avons effectué 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 nous voulons 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

• Recherchez divers 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

Dans certains cas, nous pouvons économiser sur les données lorsque nous avons 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.

Pour une exploration rapide, nous pouvons exécuter une requête comme celle-ci :

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

Cela nous montrera toutes les valeurs metricName correspondant au modèle.

Nous voyons d’après les résultats qu’il y a un volume élevé de métriques du modèle aws.rds.cpu%. Laissons tomber ceux-là car nous avons 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 nous voulons 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
      }
    }
  }
}

L’un des avantages des règles de suppression est que nous pouvons configurer une règle qui supprime un attribut spécifique mais conserve le reste des données intact. Utilisez ceci pour supprimer des données privées de NRDB ou pour supprimer un attribut excessivement volumineux. Par exemple, les traces d'appels ou les gros morceaux de JSON dans les enregistrements log peuvent parfois être très 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, nous tirerons parti de la distribution relative de certains identifiants de trace pour approximer l'échantillonnage aléatoire. Nous pouvons 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 %

Voici un exemple de mutation complète :

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        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
      }
    }
  }
}

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. Si vous pouvez le demander, vous pouvez le laisser tomber. Contactez New Relic si vous avez des questions sur la manière précise de structurer une requête pour une règle de suppression.