Ruby agent release notesRSS

Feature: SpanLink events are now supported for the Hybrid agent

Spans created by an OpenTelemetry API can now have Span Links associated with them. Links can be added on a span's start, by passing them to the links argument, or by calling the OpenTelemetry::Trace::Span#add_link API. PR#3586

Feature: SpanEvent events are now supported for the Hybrid agent

Spans created by an OpenTelemetry API can now have SpanEvent events associated with them via the OpenTelemetry::Trace::Span#add_event API. SpanEvent events capture timestamped annotations on a span and are sent to New Relic alongside the parent span. PR#3587

Feature: Set span kind on all Hybrid agent spans

Previously, only OpenTelemetry spans translated into external request segments or datastore segments added span kind as an attribute. Now, the agent adds span kind to all OpenTelemetry spans where the value is available. PR#3589

Feature: Add support for OpenTelemetry::Tracer#start_root_span

The OpenTelemetry::Tracer#start_root_span API can now be used to force a transaction to start for a given span, provided it has a :server or :consumer span kind. For any other span kinds, it will no-op. This method is most commonly used in background job instrumentation. PR#3588

Bugfix: Fix instrumentation.rails_event_logger: false not disabling the instrumentation

Previously, setting instrumentation.rails_event_logger to false didn't disable the Rails.event instrumentation as expected; it would still be installed during Rails boot. This is now fixed. PR#3564

Bugfix: Normalize boolean-like values to disabled for instrumentation config keys

Previously, only disabled would turn off an instrumentation.* config key. Now, boolean-like values such as false, no, or off also resolve to disabled and prevent the instrumentation from being installed. PR#3579

Bugfix: Per-library logging supportability metrics now reflect each library's instrumentation state

Previously, the Supportability/Logging/Ruby/{library}/{enabled|disabled} metrics reported the value of the global application_logging.enabled setting for every library, rather than each library's actual state. As a result, the metric reported enabled even when you had disabled logging instrumentation for a specific library or weren't using that library's gem at all. Now, each library's metric reflects whether its own logging instrumentation is enabled. PR#3571

Característica: agregar soporte para Dalli 5.0 y corregir la instrumentación del metaprotocolo

El agente ahora es compatible con Dalli 5.0+, que eliminó Dalli::Protocol::Binary a favor del metaprotocolo exclusivamente. Para Dalli 3.2.0+, La instrumentación de pipelined_get ahora tiene como objetivo correctamente a Dalli::Protocol::Base (donde se define el método) en lugar de a Dalli::Protocol::Binary, lo que corrige una brecha donde las llamadas de get_multi quedaban sin instrumentar al usar el metaprotocolo. Para Dalli 5.0+, el agente instrumenta adicionalmente Dalli::Protocol::Meta#read_multi_req, que es invocado por la optimización get_multi de servidor único de Dalli. PR#3541

Característica: agregar la opción de configuración active_record_use_table_name

Una nueva opción de configuración, active_record_use_table_name, usa el nombre de la tabla de un modelo de Active Record en lugar de su nombre de clase al nombrar métricas, spans y segmentos de traza de la transacción. Esto puede ser particularmente útil para reducir la cardinalidad en aplicaciones que utilizan herencia de tabla única. La opción tiene como valor predeterminado false para conservar el comportamiento existente. PR#3540

Característica: ocultar parcialmente las claves de licencia en los registros del agente

Anteriormente, el agente ocultaba por completo las claves de licencia de New Relic en los registros del agente. Ahora, los primeros 10 caracteres son visibles mientras que el resto se reemplaza con *. Esto conserva lo suficiente para solucionar problemas relacionados con la región sin exponer la parte secreta de la clave. PR#3547

Corrección de error: corrige la incompatibilidad de la instrumentación de Semantic Logger con rails_semantic_logger

Anteriormente, se generaba un ArgumentError cuando una excepción llegaba a ActionDispatch::DebugExceptions al usar rails_semantic_logger. Esto fue solucionado. ¡Gracias a @jdelStrother por reportar esto! PR#3548

Característica: agregar instrumentación de Rails.event para logging estructurado

El agente ahora admite Rails.event como logs de evento estructurados. Cuando está habilitado, los eventos publicados a través de Rails.event.notify se capturan y reenvían a New Relic como logs de eventos. Las cargas de eventos, las etiquetas, el contexto, los timestamps y las ubicaciones de origen se capturan automáticamente como atributos de log.

Esta instrumentación se puede configurar con las siguientes opciones:

• instrumentation.rails_event_logger - Controla si la instrumentación de Rails.event está habilitada. De forma predeterminada, usa el valor de application_logging.enabled.
• instrumentation.rails_event_logger.event_names - Una matriz de nombres de eventos específicos para capturar. Cuando está vacío (predeterminado), se capturan todas las notificaciones de Rails.event. Utilice esto para filtrar eventos por nombre, por ejemplo: ['user.signup', 'payment.processed'].

PR#3526

Característica: agregar instrumentación para las continuaciones de Rails Active Job

El agente ahora instrumenta las continuaciones de Active Job de Rails, proporcionando visibilidad de la ejecución de pasos individuales dentro de trabajos de larga duración. Los nombres de los pasos se incluyen en las métricas de segmento (por ejemplo, Ruby/ActiveJob/default/MyJob/step/process_records) y se capturan atributos específicos del paso, como la posición del cursor, el estado reanudado y el estado interrumpido. Una nueva opción de configuración, disable_active_job_step_names, permite a los usuarios excluir los nombres de pasos de los nombres de métricas para reducir la cardinalidad de métricas si es necesario (el valor predeterminado es false). PR#3493

Característica: agregar sidekiq.separate_transactions opción de configuración

Una nueva opción de configuración, sidekiq.separate_transactions, permite que los trabajos de Sidekiq ejecutados durante una transacción web se ejecuten en su propia transacción separada. Cuando está habilitado, esto evita que el tiempo de ejecución del trabajo de Sidekiq se incluya en las métricas de transacciones web, proporcionando datos de rendimiento más precisos. La característica es opcional (predeterminado: falso) para mantener la compatibilidad con versiones anteriores. Esto solo afecta a los trabajos ejecutados durante transacciones web activas; los trabajos que se inician de forma independiente o anidados dentro de otros trabajos en segundo plano no se ven afectados. Issue#3364 PR#3514

Corrección de errores: actualizar las expresiones regulares que podrían haber sido vulnerables a ataques ReDOS

Anteriormente, el agente tenía algunas regexes identificadas como posibles objetivos de ataques de complejidad de tiempo polinómico (ReDOS). Esas expresiones regulares ahora se actualizaron para resolver las inquietudes. PR#3520

Corrección de errores: evitar caídas durante la creación de segmentos HTTPX

Anteriormente, si start_external_request_segment encontraba un error y devolvía nil, el agente generaba un NoMethodError al intentar agregar encabezados al segmento faltante. Hemos agregado una comprobación de seguridad para garantizar que la instrumentación maneje estos casos con elegancia.

¡Bravo a @thebravoman por el reporte! Issue#3509 PR#3510

Corrección de errores: hacer que Transaction#finish sea idempotente

Anteriormente, si el método Transaction#finish se llamaba múltiples veces, se podía crear más de una transacción para la misma operación. Ahora, un mutex protege las llamadas a Transaction#finish para garantizar que las operaciones de finalización solo se ejecuten una vez. PR#3513

Corrección de errores: Advertencia única de obsolescencia de Log para la API Datastores.wrap

Anteriormente, esta advertencia se registraba en cada llamada a Datastores.wrap. Ahora, solo se registrará en la primera llamada. Además, la documentación se ha actualizado para indicar el estado obsoleto del segundo y tercer argumento de devolución de llamada. Issue#3516 PR#3519

Característica: agregar asignación de nombres de consulta de la base de datos mediante comentarios SQL

Las consultas de la base de datos ahora se pueden nombrar explícitamente usando comentarios SQL. Las consultas pueden incluir /* NewRelicQueryName: CustomName */ comentarios para asignar nombres estables para un mejor seguimiento e identificación. Esto es especialmente útil para rastrear consultas específicas de la base de datos durante regresiones de rendimiento o incidentes. PR#3480

Característica: agregar instrumentación del logger semántico

El agente ahora admite el reenvío de logs y la decoración de Semantic Logger para la gema semantic_logger versiones 4.6.0+. Si utilizaba previamente el apéndice integrado de New Relic de Semantic Logger, se recomienda elegir un enfoque para evitar enviar logs duplicados. La instrumentación de Semantic Logger de New Relic se puede deshabilitar estableciendo instrumentation.semantic_logger en disabled. PR#3467

Gracias a @jdelStrother por proporcionar retroalimentación valiosa que ayudó a dar forma a esta instrumentación.

Característica: agregar nueva configuración 'ignored_middleware_classes'

Una nueva opción de configuración, ignored_middleware_classes, permite a los usuarios excluir middlewares específicos de la instrumentación (ej. Rack::Cors). El valor predeterminado es una matriz vacía. Issue#1814 PR#3481

Característica: agregar nueva API NewRelic::Agent.add_transaction_log_attributes

Una nueva API, NewRelic::Agent.add_transaction_log_attributes, permite a los usuarios agregar atributos personalizados a nivel de transacción a los logs de eventos para la transacción actual. Estos atributos solo se aplicarán a los logs creados dentro del alcance de la transacción actual. PR#3472

Corrección de error: proporcionar opción de configuración para reducir la cardinalidad de las métricas de broadcast de ActionCable

De forma predeterminada, las métricas para las llamadas al método broadcast de ActionCable incluyen el valor del broadcasting. Este valor puede tener muy alta cardinalidad. Ahora, la opción de configuración :simplify_action_cable_broadcast_metrics permite a los usuarios eliminar el valor de transmisión del nombre de la métrica. Esto crea una métrica que se ve como: Ruby/ActionCable/broadcast. Cuando esta opción de configuración está habilitada, el valor de transmisión se agregará como un atributo de span. PR#3463

Corrección de errores: eliminar la instrucción require inactiva de 'digest/md5' para el cumplimiento de FIPS/FedRAMP

En la versión 7.1.0 del agente, el uso de MD5 se reemplazó por SHA1 para el cumplimiento de FIPS (PR). Sin embargo, el antiguo require para 'digest/md5' no se eliminó. Eliminamos el requisito para ayudar a nuestros usuarios de FIPS/FedRAMP. ¡Gracias a @ashleyboehs por informarnos sobre esto! Issue#3469 PR#3470

Bugfix: impedir que el agente se inicie durante rails test para evitar el retraso en el apagado

Anteriormente, el agente causaba un retraso de cierre de -3 segundos al ejecutar el comando rails test. La constante Rails::Command::TestCommand se ha agregado a la lista autostart.denylisted_constants predeterminada para evitar que el agente se inicie durante las ejecuciones de pruebas de Rails. Gracias a @varyform por informarnos sobre esto. PR#3478

Corrección de errores: soluciona las advertencias "no se puede calcular el tiempo de transacción transcurrido" al usar el servidor web Falcon

El agente ahora usa Fiber.current.object_id en lugar de Thread.current.object_id para rastrear el estado de la transacción cuando se ejecuta en Falcon, lo que evita colisiones de requests concurrentes que comparten el mismo hilo. También soluciona un "NameError: uninitialized constant Async::HTTP::VERSION" al usar Falcon. Gracias a @97jaz y @gsar por informarnos sobre esto. PR#3483

Corrección de errores: corregir error tipográfico en harvest.rb que causaba NoMethodError

Un error tipográfico en lib/new_relic/agent/agent_helpers/harvest.rb causó un NoMethodError: undefined method 'agent' for NewRelic:Module. Gracias a @oakbow por informar este problema. PR#3484

Corrección de error: elimina el uso del obsoleto ObjectSpace._id2ref

El agente ahora usa un enfoque alternativo en lugar del método ObjectSpace._id2ref obsoleto, eliminando las advertencias de obsolescencia al ejecutarse en Ruby 4.0+. PR#3490

Corrección de error: se corrigió NoMethoError en la instrumentación de logging

Anteriormente, cuando la instrumentación de la gema Logging intentaba decorar los logs locales, lanzaba un NoMethodError si encontraba un objeto que no era una cadena. Esto ya está solucionado. PR#3501

Función: Introducir Agente híbrido para soporte de rastreo de OpenTelemetry

Las API de rastreo de OpenTelemetry ahora pueden traducirse a telemetría de New Relic con las nuevas funciones de agente híbrido del agente Ruby de New Relic. Esto permite que la gema newrelic_rpm se comporte de manera similar a un SDK de OpenTelemetry, aceptando llamadas de la API de OpenTelemetry y convirtiéndolas en Transacciones y Segmentos de New Relic con atributos y nombres familiares.

Las siguientes opciones de configuración se relacionan con las funciones del Agente híbrido:

Característica: Agregar opción de configuración error_collector.backtrace_truncate_location

Se agregó una nueva opción de configuración, error_collector.backtrace_truncate_location, que permite al usuario especificar dónde truncar el backtrace cuando el número de marcos excede error_collector.max_backtrace_frames. Las opciones son 'top' (elimina marcos del inicio), 'middle' (elimina marcos del medio, conservando el inicio y el final) o 'end' (elimina marcos del final). El valor predeterminado es 'middle'. PR#3424

Función: Agregar instrumentación de la gema Logging

El agente ahora registrará los logs generados por la gema Logging. PR#3420

Función: Agregar opción de configuración utilization.detect_in_parallel

Se ha agregado una nueva opción de configuración, utilization.detect_in_parallel, que controla si el agente utiliza hilos al detectar información del proveedor de la nube para acelerar el inicio del agente. Cuando se establece en false, la detección de proveedores se ejecuta secuencialmente sin crear hilos. El valor predeterminado es true. PR#3439