Nous ajustons notre logique de validation d'ingestion OTLP pour avoir un traitement des attributs plus indulgent.
Le point de terminaison OTLP de New Relic effectue une variété de validations sur les attributs. Il existe des limites d'attributs qui limitent des éléments tels que la longueur des clés et des valeurs, ainsi que des contraintes supplémentaires sur les types de valeurs pour les cas limites qu'il est possible d'exprimer via les définitions de message protobuf, mais qui ne sont généralement pas rencontrées dans la pratique, y compris l'éventail hétérogène (c'est-à-dire un éventail avec un mélange de types de valeurs comme des chaînes et des entiers), l'éventail imbriqué (c'est-à-dire un éventail d'éventails) et plus encore.
Actuellement, le point de terminaison OTLP de New Relic est strict avec la validation. Dans certains cas, nous supprimons l'attribut problématique en silence, mais pour la plupart des problèmes de validation, nous supprimons l'enregistrement entier lorsqu'un seul attribut n'est pas valide.
Cette validation stricte est l’un des problèmes les plus courants rencontrés par les clients lors de l’envoi de données OTLP à New Relic. Heureusement, il existe une solution simple :
Nous adoptons une posture de traitement des attributs indulgente. Lorsqu'un attribut n'est pas valide, nous supprimons ou modifions cet attribut et conservons l'enregistrement. Dans les cas graves, nous pouvons encore supprimer des enregistrements alors qu’il n’existe aucun moyen intuitif de les conserver. Chaque fois que nous supprimons ou modifions un attribut, ou supprimons un enregistrement, nous créons une NrIntegrationError pour aider à localiser et à résoudre le problème à la source.
Nous déploierons ce changement le 2 juin 2025.
Comment cela va-t-il m'affecter ?
Nous pensons que cela constituera un soulagement bienvenu dans presque tous les cas. Notre validation stricte actuelle génère fréquemment des données manquantes, qui peuvent être difficiles à localiser et à diagnostiquer, en particulier dans les environnements avec un grand nombre de déploiements gérés par de nombreuses équipes individuelles. Avec ce changement, le point de terminaison New Relic OTLP incarnera mieux notre philosophie de « stocker ce que vous envoyez ».
Cependant, étant donné le modèle de tarification basé sur l'utilisation de New Relic, ce changement signifie que les enregistrements qui étaient auparavant supprimés seront désormais stockés et contribueront à l'utilisation des données de votre compte.
Si vous suivez notre documentation OTLP sur les limites d'attributs et que les attributs de vos données sont conformes à la définition d'attribut standard OpenTelemetry , il n'y a rien à faire. Le respect de ces contraintes signifie qu'aucune donnée n'est actuellement supprimée et qu'aucune donnée supplémentaire ne sera donc stockée.
Pour vérifier si des données de votre compte sont actuellement supprimées en raison de la validation des attributs, exécutez la requête NRQL suivante :
FROM NrIntegrationError SELECT * WHERE message like 'One or more OTLP data point(s) was dropped%'Si cette requête renvoie des résultats, vous pouvez constater un changement dans l'utilisation et donc dans la facturation suite à ce changement. Le montant exact dépend de la fréquence à laquelle les enregistrements enfreignent les limites. Plus précisément, les cas suivants entraînent actuellement des suppressions d’enregistrements et seront ajustés comme décrit ci-dessous :
- Le nom de l'attribut dépasse la limite de longueur de 255 caractères. Le nom de l'attribut sera tronqué et conservé.
- La valeur de la chaîne d'attribut dépasse la limite de longueur de 4 095 caractères. La valeur de l'attribut sera tronquée et conservée.
- L'étendue d'octets de l'attribut dépasse la limite de 128 Ko sur l'étendue d'octets. L'attribut sera supprimé et l'enregistrement conservé.
- La longueur de l'éventail dépasse la limite de 64 entrées. L'attribut sera supprimé et l'enregistrement conservé.
REMARQUE : le problème de validation le plus courant que nous constatons est celui des valeurs de chaîne d’attribut dépassant la limite de 4 095 caractères. Le changement de la validation consistant à supprimer les enregistrements avec des valeurs d'attribut longues pour tronquer l'attribut long et conserver l'enregistrement peut entraîner une augmentation notable de l'utilisation des données.
Consultez la section atténuation pour obtenir des conseils sur la manière de compenser toute utilisation de données supplémentaire que vous pourriez subir.
Atténuation
Une partie de la proposition de valeur principale d' OpenTelemetryconsiste à fournir des outils pour prendre le contrôle de votre pipeline de données télémétriques. Il existe donc une variété d’outils disponibles pour aider à atténuer un changement dans l’utilisation des données. Pour une discussion complète, voir Gérer le volume d'ingestion de données OpenTelemetry. Quelques stratégies sont particulièrement pertinentes ici :
- Tronquer les attributs longs
- Supprimer les attributs incriminés
- Envoyer moins d'enregistrements avec l'échantillonnage
Tronquer les attributs longs
En tirant parti du processeur de transformation collecteur et de l'éditeur truncate_all , tronquez tous les attributs à une limite connue, comme démontré ici. C'est ce que fera le point de terminaison New Relic OTLP après ce changement. Cependant, vous pouvez exploiter cette technique pour compenser un changement d'utilisation en définissant une limite inférieure aux limites de la plateforme New Relic. Par exemple, vous pouvez définir une limite de 1 000 si vous pensez que vous n’aurez besoin que des 1 000 premiers caractères pour votre cas d’utilisation d’observabilité.
transform: trace_statements: - truncate_all(span.attributes, 4095) - truncate_all(resource.attributes, 4095) log_statements: - truncate_all(log.attributes, 4095) - truncate_all(resource.attributes, 4095) metric_statements: - truncate_all(datapoint.attributes, 4095) - truncate_all(resource.attributes, 4095)Supprimer les attributs incriminés
En exploitant le processeur de transformation collecteur et l'éditeur delete_key , supprimez les attributs qui n'ont pas de valeur :
transform: trace_statements: - delete_key(span.attributes, "attribute.key.to.drop") log_statements: - delete_key(log.attributes, "attribute.key.to.drop") metric_statements: - delete_key(datapoint.attributes, "attribute.key.to.drop")Vous pouvez choisir de supprimer les clés d'attribut qui sont particulièrement longues et qui contribuent donc de manière disproportionnée à l'utilisation, ou les attributs qui sont courts mais qui ne sont généralement pas utiles. Pour référence, la liste suivante résume les 10 attributs les plus courants qui enfreignent la limite de longueur de la valeur d'attribut :
exception.stactraceother- un fourre-tout pour les attributs personnalisés non définis dans les conventions sémantiques OpenTelemetrydb.statementprocess.command_linegraphql.documentdb.operationdb.query.texthttp.urlexception.messagehttp.target
Envoyer moins d'enregistrements avec l'échantillonnage
Compensez les données supplémentaires en ajustant votre taux d’échantillonnage à l’aide de l’une des stratégies décrites ici.