L'un des principaux atouts d'OpenTelemetry est son riche ensemble d'outils offrant un contrôle inégalé sur votre pipeline de données télémétriques. Ce contrôle complète le modèle de tarification à la consommation de New Relic.
Cette page parle d'une variété de concepts qui contribuent au volume de données lors de l'utilisation OpenTelemetry avec New Relic, ainsi que des outils/modèles disponibles pour gérer votre pipeline de données télémétriques. Il est organisé en sections traitant des concepts clés contribuant au volume de données pour les ressources, la trace, les métriques et les logs, suivis d'un catalogue d'outils disponibles pour aider à gérer le volume.
Concepts clés : Ressources
OTLP définit une structure de message hiérarchique similaire sur tous les signaux, ce qui évite la répétition au niveau du protocole en partageant les informations entre les enregistrements.
- Chaque demande d'exportation contient plusieurs
Resource{SignalRecord} - Chaque
Resource{SignalRecord}contient plusieursScope{SignalRecord} - Chaque
Scope{SignalRecord}contient plusieurs{SignalRecord} {SignalRecord}estSpan,Metric, etLogRecord
Cette structure hiérarchique est aplatie lorsqu'elle est envoyée au point de terminaison New Relic, et chaque attribut de ressource est dénormalisé en enregistrements Span, Metric et Log individuels. Pour plus d'informations sur la manière dont les données OpenTelemetry sont gérées dans New Relic, consultez les pages suivantes :
La plupart des implémentations du langage OpenTelemetry fournissent un package avec des détecteurs de ressources, qui contribuent à l'attribut de ressource en fonction des informations détectées dans l'environnement. Ces attributs peuvent être extrêmement utiles, mais peuvent inclure plus d’informations que nécessaire.
Pour plus de détails, voir les éléments suivants :
Concepts clés : trace
Échantillonnage
L'échantillonnage est le processus de contrôle des étendues exportées vers un backend d'observabilité. Les données de trace peuvent fournir des informations très précieuses et détaillées, mais si elles ne sont pas contrôlées, elles peuvent rapidement remplir les disques durs (et les factures !).
Par défaut, les SDK OpenTelemetry utilisent l'échantillonneur ParentBased(root=AlwaysOn) . L'échantillonneur ParentBased délègue à différents échantillonneurs configurables selon qu'il existe ou non un parent span, que ce parent soit local au processus actuel ou distant et que ce parent soit échantillonné. L'échantillonneur par défaut ParentBased(root=AlwaysOn) échantillonnera une plage si l'une des conditions suivantes est vraie :
- Il n'y a pas de span parent (c'est-à-dire que ce span est la racine)
- Le parent est échantillonné, que le parent soit local ou distant
En d’autres termes, il échantillonnera la plage à moins que le parent ne soit déséchantillonné.
Il s’agit d’une bonne valeur par défaut pour la communauté OpenTelemetry car elle permet à l’utilisateur d’installer l’instrumentation et de voir les données trace sans avoir besoin d’abord de connaître le concept d’échantillonnage. Cependant, vous devez être prudent avec le déploiement en production d'OpenTelemetry. En vertu de cette politique, toutes les portées sont échantillonnées, sauf si un composant ou une passerelle en amont prend des décisions d'échantillonnage intelligentes auxquelles le système en aval doit se conformer.
Pour des alternatives, voir les éléments suivants :
- Échantillonneur ParentBased(root=TraceIdRatioBased)
- Filtre Collector Processeur
- Processeur d'échantillonnage de queue Collector
Données d'étendue
Les étendues OpenTelemetry sont composées d'une variété de champs de niveau supérieur (nom, type, etc.), d'attributs, d'événements d'étendue et de liens d'étendue. La quantité de données attachées aux étendues correspond directement au volume de données dans New Relic.
La bibliothèque d'instrumentation prend des décisions sur les éléments d'information à attacher aux travées, en suivant souvent les conventions sémantiques. Lorsque des exceptions se produisent, les informations sont souvent jointes à l'étendue sous la forme d'un événement d'étendue d'exception. Cet événement comprend un attribut représentant le message d'exception, le type et trace des appels, qui, selon la langue et l'application, peuvent être constitués de milliers d'octets. Si des exceptions se produisent fréquemment, les traces d'appels peuvent produire un volume de données élevé dans New Relic.
Pour connaître les stratégies de gestion des données d'étendue, consultez les éléments suivants :
traceur
Une portée d'instrumentation est une unité logique de code d'application avec une télémétrie qui lui est associée. Chaque bibliothèque d'instrumentation possède un (ou plusieurs) périmètres uniques et un ou plusieurs traceurs correspondants.
Les traceurs qui ne produisent pas de données trace de grande valeur peuvent être désactivés de manière sélective sans interrompre la trace.
Pour plus de détails, voir SDK désactiver traceur, Meter, enregistrer.
Concepts clés : Métriques
Intervalle de collecte
Les métriques regroupent les mesures individuelles et exportent l'état agrégé hors processus. Pour les protocoles push comme OTLP, l'exportation se produit sur un intervalle configurable par défaut sur 60s. Cet intervalle correspond directement au volume de données dans New Relic. Réduisez l’intervalle à 30s et le volume de données devrait approximativement doubler. Augmentez l’intervalle à 120s et le volume de données devrait être réduit de moitié environ.
L'intervalle par défaut 60s est une valeur par défaut raisonnable, car il équilibre le compromis entre le volume de données et le décalage d'observabilité. Augmentez l'intervalle trop haut et les retards dans les signaux critiques atteignant le dashboard et les alertes New Relic peuvent aggraver les problèmes.
Pour plus de détails, voir SDK périodique exportant métrique Reader exportIntervalMillis.
Cardinalité
Les mesures que les métriques agrègent sont associées à un ensemble d'attributs. Le nombre d’ensembles distincts d’attributs est appelé cardinalité. La cardinalité est importante car elle détermine la quantité de mémoire d'application requise pour maintenir l'état agrégé des mesures, la quantité de données exportées à chaque intervalle de collecte et le volume de données dans New Relic.
Si la cardinalité est trop élevée, envisagez d'omettre les attributs qui y contribuent. Si vous contrôlez l'instrumentation, cela pourrait signifier enregistrer moins d'attributs à chaque mesure. Cependant, l’instrumentation n’est souvent pas directement configurable.
Pour plus de détails sur la façon de supprimer un attribut des métriques, consultez les éléments suivants :
Temporalité de l'agrégation
Dans les métriques OpenTelemetry, le concept de temporalité d'agrégation définit si l'état des mesures agrégées se réinitialise ou non après chaque collecte. Lorsque la temporalité d'agrégation est cumulative, l'état agrégé ne se réinitialise pas et les métriques représentent les valeurs cumulées depuis le démarrage de l'application. Lorsque la temporalité de l'agrégation est delta, l'état agrégé se réinitialise après chaque collecte et les métriques représentent la différence depuis la collecte précédente.
Alors que le point de terminaison OTLP de New Relic prend en charge la temporalité d'agrégation cumulative, l'architecture des métriques New Relic est un système de métriques delta. L'utilisation du paramètre cumulatif par défaut entraînera généralement une utilisation plus importante de la mémoire des SDK et entraînera une ingestion élevée de données. La conversion de l'agrégation cumulative à l'agrégation delta est une activité à l'état, car vous devez conserver le point précédent de chaque série temporelle afin de calculer la différence. Pour cette raison, il est préférable de configurer la temporalité d'agrégation dans le SDK, ce qui permet d'économiser la mémoire de l'application et d'éviter une complexité supplémentaire en aval.
Pour plus de détails, voir les éléments suivants :
Compteurs et instruments
Une portée d'instrumentation est une unité logique de code d'application avec une télémétrie qui lui est associée. Chaque bibliothèque d'instrumentation possède un (ou plusieurs) oscilloscopes uniques et un ou plusieurs compteurs correspondants, et chaque compteur possède un ou plusieurs instruments.
Les compteurs ou instruments qui ne fournissent pas de données métriques précieuses peuvent être désactivés de manière sélective.
Pour plus de détails, voir les éléments suivants :
Concepts clés : logarithme
Données LogRecord
OpenTelemetry log Les enregistrements sont composés d'une variété de champs de niveau supérieur (horodatage, gravité, corps, etc.) et d'attributs. La quantité de données attachées aux enregistrements log correspond directement au volume de données dans New Relic.
La bibliothèque d'instrumentation (appelée log appenders dans OpenTelemetry log l'espace puisque OpenTelemetry log l'API de pont est destinée à relier les logs log des API à OpenTelemetry) prend des décisions sur les éléments d'information à joindre aux log enregistrements , en suivant souvent les conventions sémantiques .
Pour connaître les stratégies de gestion des données log , consultez les éléments suivants :
- Limites du SDK LogRecord
- SDK configure les appenders log
- Filtre Collector Processeur
- Processeur de transformation Collector
enregistreur
Une portée d'instrumentation est une unité logique de code d'application avec une télémétrie qui lui est associée. Pour le logging OpenTelemetry, chaque enregistreur distinct (ponté par un log appender utilisant OpenTelemetry log l'API de pont de ) a une portée d'instrumentation unique.
Les enregistreurs qui ne produisent pas de données log de grande valeur peuvent être désactivés de manière sélective.
Pour plus de détails, voir les éléments suivants :
Catalogue d'outils de gestion Pipeline
Le tableau suivant répertorie une variété d’outils utiles pour gérer votre pipeline de données OpenTelemetry. Notez qu'OpenTelemetry est un écosystème hautement extensible. Si ces outils ne suffisent pas, d’autres outils peuvent être disponibles ou vous pourrez peut-être écrire une logique d’extension personnalisée pour les SDK de langage ou Collector afin d’atteindre vos objectifs.
Nom | Collector ou SDK ? | Description |
|---|---|---|
Kit de développement logiciel (SDK) | Les SDK de langage OpenTelemetry package des détecteurs pour fournir des attributs de ressources en fonction de l'environnement. Certains d'entre eux sont souvent activés par défaut avec des options d'instrumentation sans code comme l'agent Java OpenTelemetry. Consultez la documentation linguistique pour plus de détails sur la façon d'activer/désactiver les détecteurs de ressources. | |
Kit de développement logiciel (SDK) | Kit de développement logiciel (SDK) | L'échantillonneur bash Réglez l'échantillonneur |
Kit de développement logiciel (SDK) | Le OpenTelemetry trace SDK permet de configurer des limites de portée pour spécifier la longueur et la quantité maximales d'attributs, le nombre maximal d'événements de portée et le nombre maximal de liens de portée. Les limites de portée peuvent être configurées par programmation sur le SDK bash Définissez les limites d'étendue pour qu'elles s'alignent sur les limites d'attribut du point de terminaison New Relic OTLP. | |
Kit de développement logiciel (SDK) | Le OpenTelemetry log SDK permet de configurer des limites de portée pour spécifier la longueur maximale et la quantité d'attribut. Les limites de LogRecord peuvent être configurées par programmation sur le SDK bash Définissez les limites d'enregistrement log pour qu'elles s'alignent sur les limites d'attribut du point de terminaison New Relic OTLP. | |
SDK désactiver le traceur, les compteurs, l'enregistreur | Kit de développement logiciel (SDK) | Le SDK OpenTelemetry définit |
SDK périodique exportant lecteur métrique | Kit de développement logiciel (SDK) | Le SDK métrique OpenTelemetry permet de configurer l'intervalle de collecte du lecteur métrique exportateur périodique. L'intervalle peut être configuré par programmation, mais il est courant d'utiliser des variables d'environnement : bash Définissez l'intervalle de collecte sur 60 s (60 000 ms). Il s'agit de la valeur par défaut, mais elle peut être ajustée en fonction des besoins. |
Kit de développement logiciel (SDK) | Le SDK de métrique OpenTelemetry permet de configurer | |
Kit de développement logiciel (SDK) | Le SDK de métriques OpenTelemetry permet de configurer la temporalité d'agrégation pour l'exportateur OTLP. Cette temporalité peut être configurée par programmation, mais il est courant d'utiliser des variables d'environnement : bash Définissez la temporalité d'agrégation de l'exportateur métrique OTLP sur delta, en s'alignant sur la préférence du point de terminaison OTLP New Relic. | |
Kit de développement logiciel (SDK) | L'API de pont est conçue pour être utilisée par les OpenTelemetry log log appenders , qui relient les logs des log API à OpenTelemetry. Ces log appendeurs peuvent être installés automatiquement avec des options d'instrumentation sans code comme OpenTelemetry Java l'agent , ou peuvent nécessiter des étapes d'installation manuelles. Ils disposent souvent d'options configuration permettant de spécifier quel log et quelles données sont intégrés à OpenTelemetry. De plus, il est souvent possible de configurer l'API log en cours de pontage pour spécifier quel log (en fonction de la gravité ou du nom de l'enregistreur) doit être transmis à l'appender log . Consultez les documents linguistiques individuels pour plus de détails. | |
Collector | Le processeur de filtre Collector peut être utilisé pour filtrer les enregistrements span, métriques et log de votre pipeline d'observabilité. Pour les travées, il peut fonctionner comme un simple échantillonneur de queue, agissant sur les travées terminées mais sans accès à la trace complète (Remarque : cela peut entraîner une trace interrompue). Pour les métriques, il peut être utilisé pour supprimer des métriques ou des séries qui n'ont pas de grande valeur. Pour les logs, il peut être utilisé pour supprimer les enregistrements log qui n'ont pas de valeur élevée (par exemple logs avec une gravité à grain fin ou provenant d'un enregistreur bruyant). | |
Collector | L'échantillonnage de queue Collector vous permet de décider d'échantillonner en fonction de la trace terminée. Par exemple, vous pouvez mettre l'accent sur la conservation des traces qui comportent des erreurs ou qui touchent à des zones à fort intérêt du système. L'inconvénient est que le processeur d'échantillonnage de queue ajoute de la complexité à votre d'observabilité pipeline car il nécessite que toutes les étendues d'une trace soient acheminées vers la même Collector instance et que le conserve les étendues Collector en mémoire en attendant la trace fin de la . Cela nécessite une planification minutieuse lorsque votre pipeline d’observabilité atteint une échelle qui ne peut pas être gérée par une seule instance de Collector. | |
Collector | Le processeur de ressources Collector vous permet d'écrire des règles simples pour manipuler les attributs de ressources des étendues, des métriques et des logs. Par exemple, vous pouvez supprimer les attributs qui n’ont pas de grande valeur. | |
Collector | Le Processeur de transformation Collector métrique vous permet de manipuler des données métriques. Par exemple, vous pouvez supprimer des séries qui n'ont pas de valeur élevée ou fusionner des séries temporelles pour réduire la cardinalité (parfois appelée réagrégation spatiale). | |
Collector | Le processeur de transformation Collector vous permet de transformer des données d'observabilité en utilisant des conditions pour sélectionner les données et des instructions pour les modifier. Par exemple, vous pouvez supprimer un attribut de ressource, tronquer un attribut, modifier les champs de niveau supérieur pour les étendues, les métriques et les enregistrements de logs, et bien plus encore. | |
Collector | Le processeur Collector cumulativetodelta vous permet de transformer la temporalité d'agrégation métrique de cumulative à delta. Cela est utile pour aligner vos métriques avec la temporalité d'agrégation préférée du point de terminaison OTLP de New Relic. A noter que la traduction de l'agrégation cumulative à l'agrégation delta est un processus à l'état, nécessitant que le Collector stocke le dernier point de chaque série temporelle en mémoire afin de calculer et d'émettre la différence. Cela nécessite une planification minutieuse des Collector ressources mémoire et la structuration du d'observabilité pipeline pour garantir que tous les points de la même série arrivent à la même Collector instance. |