Actualización del procesamiento de atributos OTLP New Relic

Estamos ajustando nuestra lógica de validación de ingesta OTLP para tener un procesamiento de atributos más flexible.

El extremo OTLP New Relic realiza una variedad de validaciones en atributos. Hay límites de atributos que restringen cosas como la longitud de las claves y los valores, así como restricciones adicionales sobre los tipos de valores para casos extremos que se pueden expresar a través de las definiciones de mensajes de protobuf, pero que no se encuentran normalmente en la práctica, incluyendo matrices heterogéneas (es decir, una matriz con una mezcla de tipos de valores como cadenas y números enteros), matrices anidadas (es decir, una matriz de matrices) y más.

Actualmente, el extremo OTLP New Relic es estricto con la validación. En algunos casos, eliminamos el atributo problemático de forma silenciosa, pero para la mayoría de los problemas de validación, eliminamos todo el registro cuando un solo atributo no es válido.

Esta estricta validación es uno de los problemas más comunes que enfrentan los clientes al enviar datos OTLP a New Relic. Afortunadamente, hay una solución fácil:

Estamos adoptando una postura de procesamiento de atributos indulgente. Cuando un atributo no es válido, lo eliminaremos o modificaremos y conservaremos el registro. En casos graves, aún podemos perder registros cuando no existe una forma intuitiva de conservarlos. Cada vez que podamos o modificamos un atributo, o eliminamos un registro, crearemos un NrIntegrationError para ayudar a rastrear y solucionar el problema en la fuente.

Implementaremos este cambio el 2 de junio de 2025.

¿Cómo me afectará esto?

Creemos que esto será un alivio bienvenido en casi todos los casos. Nuestra estricta validación actual con frecuencia produce datos faltantes, que pueden resultar difíciles de rastrear y diagnosticar, especialmente en entornos con una gran cantidad de implementaciones gestionadas por muchos equipos individuales. Con este cambio, el extremo OTLP New Relic reflejará mejor nuestra filosofía de “almacena lo que envías”.

Sin embargo, dado el modelo de precios basado en el uso de New Relic, este cambio significa que los registros que anteriormente se eliminaban ahora se almacenarán y contribuirán al uso de datos de su cuenta.

Si está siguiendo nuestra documentación OTLP extremo sobre los límites de los atributos y los atributos de sus datos se ajustan a la definición de atributo del estándar OpenTelemetry , no hay nada que hacer. Cumplir con estas restricciones significa que actualmente no se descartan datos y, por lo tanto, no se almacenarán datos adicionales.

Para verificar si actualmente se están descartando datos de su cuenta debido a la validación de atributos, ejecute la siguiente consulta NRQL :

FROM NrIntegrationError SELECT * WHERE message like 'One or more OTLP data point(s) was dropped%'

Si esta consulta devuelve resultados, es posible que observe un cambio en el uso y, por lo tanto, en la facturación luego de este cambio. La cantidad exacta depende de la frecuencia con la que los registros violan los límites. En concreto, los siguientes casos actualmente dan lugar a la eliminación de registros y se ajustarán como se describe a continuación:

• El nombre del atributo excede el límite de longitud de 255 caracteres. El nombre del atributo se truncará y se conservará.
• El valor de la cadena de atributo excede el límite de longitud de 4095 caracteres. El valor del atributo se truncará y se conservará.
• El atributo byte matriz excede el límite de 128k en byte matriz. Se eliminará el atributo y se conservará el registro.
• La longitud de la matriz excede el límite de 64 entradas. Se eliminará el atributo y se conservará el registro.

NOTA: El problema de validación más común que vemos es que los valores de la cadena de atributos exceden el límite de 4095 caracteres. Cambiar la validación de descartar registros con valores de atributo largos a truncar el atributo largo y conservar el registro puede provocar un aumento notable en el uso de datos.

Consulta la sección de mitigación para obtener consejos sobre cómo compensar cualquier uso de datos adicional en el que puedas incurrir.

Mitigación

Parte de la propuesta de valor principal de OpenTelemetryes proporcionar herramientas para tomar el control de su flujo telemetry data . Como tal, hay una variedad de herramientas disponibles para ayudar a mitigar un cambio en el uso de datos. Para obtener una discusión completa, consulte Gestionar el volumen de ingesta de datos de OpenTelemetry. Algunas estrategias son particularmente relevantes aquí:

• Truncar atributo largo
• Eliminar el atributo ofensivo
• Envíe menos registros con ejemplificación

Truncar atributo largo

Aprovechando el procesador de transformación del recolector y el editor truncate_all , trunca todos los atributos hasta un límite conocido, como se muestra aquí. Esto es lo que hará el extremo OTLP New Relic luego de este cambio. Sin embargo, puede aprovechar esta técnica para compensar un cambio en el uso estableciendo un límite inferior que los límites de la plataforma New Relic. Por ejemplo, puede establecer un límite de 1000 si cree que solo necesitará los primeros 1000 caracteres para su caso de uso de observabilidad.

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)

Eliminar el atributo ofensivo

Aprovechando el procesador de transformación del recolector y el editor delete_key , elimine los atributos que no son valiosos:

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")

Puede optar por eliminar claves de atributos que sean particularmente largas y que, por lo tanto, contribuyan demasiado al uso, o atributos que sean cortos pero que, por lo general, no sean útiles. Como referencia, la siguiente lista resume los 10 atributos más comunes que violan el límite de longitud del valor del atributo:

• exception.stactrace
• other - un comodín para atributo personalizado no definido en las convenciones semánticas OpenTelemetry
• db.statement
• process.command_line
• graphql.document
• db.operation
• db.query.text
• http.url
• exception.message
• http.target

Envíe menos registros con ejemplificación

Compensa los datos adicionales ajustando tu frecuencia de ejemplificación empleando cualquiera de las estrategias que se analizan aquí.