La UI APM OpenTelemetry proporciona una experiencia de monitoreo integral para los servicios instrumentados con OpenTelemetry, ofreciendo las mismas poderosas capacidades APM que espera del agente de lenguaje tradicional de New Relic.
Requisitos previos
Antes de emplear la UI OpenTelemetry APM, cerciorar de tener:
- Configuró su servicio con instrumentación OpenTelemetry
- Configura tu servicio para enviar datos a New Relic
- Se creó la entidad de servicioOpenTelemetry
Si no completó estos pasos, consulte Monitoreo deOpenTelemetry APM para obtener instrucciones de configuración.
Encuentre sus servicios de OpenTelemetry
Para localizar sus servicios OpenTelemetry-instrumentado:
- En la UI New Relic, navegue a All entities > Services - OpenTelemetry o APM & Services
- Seleccione un servicio para abrir su página Summary
Sugerencia
Emplee la etiqueta de entidad en el explorador de entidades para filtrar servicios. Obtenga más información sobre cómo las entidades etiquetadas se calculan en los recursos deOpenTelemetry en New Relic.
Cómo funciona OpenTelemetry con New Relic APM
Los servicios instrumentados de OpenTelemetrybrindan la misma experiencia APM curada que los servicios que emplean el agente de lenguaje de New Relic. Así es como funciona:
Proceso de mapeo de datos
New Relic asigna automáticamente sus datos de OpenTelemetry a nuestras convenciones APM mediante lo siguiente:
- Generación de métricas APM : Creamos la métrica necesaria para la experiencia APM directamente desde sus datos OpenTelemetry
- Conservación de datos originales: sus datos originales OpenTelemetry permanecen disponibles para el panel personalizado y las alertas.
- Convenciones de normalización: manejamos las convenciones semánticas en evolución de OpenTelemetry para que no tenga que rastrear las diferencias de versión
Beneficios para los usuarios existentes de New Relic
Si está realizando la transición de New Relic agente a OpenTelemetry, puede continuar empleando las versiones familiares de Métrica y Consulta mientras adopta los estándares OpenTelemetry.
Importante
Por qué normalizamos los datos de OpenTelemetry
Las convenciones semánticas de OpenTelemetry aún están evolucionando y muchas aún no son estables. Al normalizar sus datos según las convenciones de New Relic, logramos lo siguiente:
- Reduzca la complejidad del seguimiento de qué versiones de la convención OpenTelemetry emplea su instrumentación
- Proporcione una experiencia consistente a medida que realiza la transición del agente New Relic a OpenTelemetry
- Cerciorar de que su experiencia con APM se mantenga estable independientemente de los cambios de OpenTelemetry
Fuentes de datos y priorización
La experiencia de APM emplea tres tipos de datos de OpenTelemetry:
- Métrica (primarias): proporciona estadísticas de servicio precisas como rendimiento, tiempo de respuesta y tasa de errores
- Spans (suplementario): Se emplea cuando las métricas no están disponibles o para una característica específica como la traza de la transacción.
- Logs: integrados para resolución de problemas y correlación
Por qué se prefieren las métricas: las métricas brindan una imagen completa del rendimiento de su servicio, mientras que los tramos generalmente se muestrean y pueden no representar todo el tráfico.
La experiencia de APM aprovecha principalmente estas convenciones semánticas de OpenTelemetry:
- HTTP - transacción sitio web y llamadas externas
- RPC - Llamadas a procedimientos remotos
- Mensajería - Operaciones de cola de mensajes
- base de datos - operaciones de base de datos
Cómo se derivan las transacciones de los datos de OpenTelemetry
La experiencia APM de New Relic se centra en la noción de transacción. Al emplear un agente de New Relic, es responsabilidad de la instrumentación del agente definir el alcance de una transacción (por ejemplo, una sola solicitud sitio web). El agente produce datos métricos que impulsan la gran mayoría de la experiencia de New Relic APM al registrar métricas de transacciones que miden la duración de las transacciones y sus operaciones individuales (por ejemplo, llamadas externas y llamadas de base de datos).
La instrumentación de OpenTelemetry no tiene un análogo directo a una transacción de New Relic, por lo que adaptar la noción de transacciones a los datos de OpenTelemetry es clave.
Al aprovechar las convenciones semánticas de OpenTelemetry, podemos aprovechar los medios altamente estructurados y estandarizados de OpenTelemetrypara describir la telemetría con el fin de impulsar la experiencia APM de una manera muy similar a la del agente de New Relic.
Las convenciones semánticas definen métricas estándar para medir operaciones comunes como el manejo requests HTTP o RPC. Estas métricas son análogas a las métricas de transacciones que produce el agente New Relic para describir transacciones sitio web. Aprovechamos las métricas HTTP y RPC de OpenTelemetrypara sintetizar las métricas que impulsan la UI APM, como la métricaapm.service.transaction.duration .
New Relic también proporciona un concepto de transacción no sitio web. Las transacciones no sitio web se emplean comúnmente para sistemas que realizan el procesamiento de mensajes. La instrumentación que aprovecha las convenciones de mensajería de OpenTelemetrydará como resultado una síntesis métrica que representa las transacciones en el sitio web.
Importante
Operaciones de mensajería y datos de lapso
Las convenciones de mensajería de OpenTelemetry son menos maduras que las convenciones HTTP y RPC. Actualmente, generamos transacciones no sitio web métricas para operaciones de mensajería a partir de datos span en lugar de datos métricos. Este enfoque sigue las convenciones semánticas de mensajería, pero puede ver afectado por su estrategia de ejemplificación.
Nombres de transacciones
Cada transacción tiene un nombre que se deriva del atributo requerido por las convenciones semánticas de OpenTelemetry. Consulte la sección Métrica del servicioAPM para saber cómo se deriva este nombre.
Nombre de transacción desconocido
A veces es posible que veas una transacción con unknown en el nombre. Esto es una indicación de que los datos de origen empleados para derivar la transacción no siguen ninguna de las convenciones semánticas de OpenTelemetry establecido que actualmente admitimos.
Algunos ejemplos:
- HTTP métrica faltante
http.request.methodohttp.route. Por ejemplo, si a la métricahttp.server.request.durationle falta el atributohttp.route, el nombre de la transacción seráWebTransaction/server/GET unknown. - marco o protocolos para los cuales OpenTelemetry actualmente no define convenciones semánticas (por ejemplo, trabajos en segundo plano y marco CI).
Navegando por la experiencia APM
Resumen
La página Summary proporciona una descripción general del estado de su servicio y se centra en la noción de transacción de New Relic. Consulte Cómo se derivan las transacciones de los datos de OpenTelemetry para obtener más detalles.
Las métricas New Relic que controlan la página Summary son las métricas apm.service.transaction.duration y apm.service.error.count. Consúltelos para obtener detalles sobre cómo se derivan de sus datos de OpenTelemetry.
Personalización del objetivo Apdex
En la instrumentación New Relic, el objetivo de apdex personalizado se configura usando agente configuración. Para OpenTelemetry, al ver un servicio, navegue a Settings > Application para configurar su objetivo Apdex.
rastreo distribuido
La página de rastreo distribuido proporciona información detallada y valiosa sobre los datos de traza OpenTelemetry . Consulte rastreo distribuido para obtener información sobre el uso de la página. Consulte OpenTelemetry traza en New Relic para obtener detalles sobre cómo se incorporan los datos de OpenTelemetry traza en New Relic.
Al igual que con las señales doradas, los intervalos se clasifican como errores si el estado del intervalo se establece en ERROR (por ejemplo, otel.status_code = ERROR). Si el intervalo es un error, la descripción del estado del intervalo (por ejemplo, otel.status_description) se muestra en los detalles del error.
OpenTelemetry span evento adjunta información de contexto de evento adicional a un lapso particular. Se emplean más comúnmente para capturar información de excepciones. Si está disponible, puede ver el evento de un lapso en trace details.
Sugerencia
La presencia de un evento de excepción de lapso no califica el lapso como un error por sí solo. Sólo los intervalos con estado de intervalo establecido en ERROR se clasifican como errores.
Mapa de servicios
La página del mapa de servicio proporciona una representación visual de toda su arquitectura. Consulte los mapas de servicio para obtener más información.
Transacción
La página de transacciones proporciona herramientas para identificar problemas y analizar las transacciones de un servicio.
OpenTelemetry no tiene un análogo directo con la noción de transacción de New Relic. Consulte Cómo se derivan las transacciones de los datos de OpenTelemetry para obtener más detalles.
Las métricas New Relic que impulsan la página Transacción son las métricas apm.service.transaction.duration y apm.service.error.count. Consúltelos para obtener detalles sobre cómo se derivan de sus datos de OpenTelemetry.
Traza de la transaccion
La traza de la transacción para OpenTelemetry se deriva de sus datos de intervalo. En la página de transacciones puede encontrar una lista de la traza de la transacción. Esta lista requiere que los datos de lapso y los datos métricos para una transacción determinada estén correlacionados entre sí. Hacemos esto agregando un atributo transaction.name al tramo raíz de una traza de la transacción.
Desglose de segmentos
Al hacer clic en una transacción, se abre una vista detallada de la transacción que revela un desglose del segmento. A diferencia del agente New Relic, OpenTelemetry no emite métricas para segmentos individuales. Por lo tanto, las métricas de New Relic necesarias para impulsar la descomposición del segmento se derivan de los datos de tramo.
La desventaja notable de calcular el desglose de segmentos a partir de datos de tramos es que los tramos generalmente se muestrean. Sin embargo, incluso con la ejemplificación, el desglose de segmentos todavía puede servir para ayudarlo a identificar métodos u operaciones específicos que consumen la mayor parte del tiempo dentro de una transacción.
A partir de los datos de span, estimamos una tasa de ejemplificación calculando un rendimiento basado en los datos de span recibidos y dividiendo ese dato por el rendimiento real según lo informado por sus datos métricos. La tasa de ejemplificación estimada nos permite extrapolar la descomposición del segmento de una transacción.
Este proceso no es perfecto y puede ver afectado por diversos factores, entre ellos, el más notable es su estrategia de ejemplificación. Funciona mejor cuando se muestrea estrictamente un porcentaje de los datos de intervalo. Sin embargo, por ejemplo, si solo se toman muestras de los tramos que representan errores, el desglose del segmento puede estar sesgado.
Base de datos
La página de base de datos proporciona herramientas para identificar problemas y analizar las operaciones del cliente de base de datos de un servicio.
La instrumentación OpenTelemetry representa llamadas a base de datos empleando las convenciones semánticas de base de datos.
La métrica New Relic que impulsa la página base de datos es la métrica apm.service.datastore.operation.duration. Consúltelo para obtener detalles sobre cómo se deriva de sus datos de OpenTelemetry.
Consumo de tiempo por persona que llama
Al hacer clic en una llamada de base de datos específica, verá el gráfico "Consumo de tiempo por persona que llama". Este gráfico está impulsado por la métrica apm.service.transaction.overview. Esta es la misma métrica que impulsa la vista de desglose de segmentos de la página de transacciones y se deriva de los datos de lapso.
Importante
Las convenciones semánticas de la base de datos de OpenTelemetry se consideraron recientemente estables. Todavía no existe mucha instrumentación estable, y la instrumentación que existe a menudo sólo emite datos de span y no datos métricos.
Como tal, al emplear instrumentación que aún no adoptó las convenciones semánticas estables, las métricas APM generadas a partir de la página base de datos se derivan de los datos span.
A medida que la instrumentación estable esté disponible y usted la adopte, la página de base de datos comenzará a aprovechar los datos métricos OpenTelemetry. Comunicar con la comunidad OpenTelemetry para consultar sobre la disponibilidad de instrumentación de base de datos estable en su idioma.
Servicios externos
La página de servicios externos proporciona herramientas para identificar problemas y analizar las llamadas externas de un servicio, incluidas las entidades que llaman (servicios ascendentes) y las entidades llamadas (servicios descendentes).
La instrumentación de OpenTelemetry representa llamadas a servicios externos empleando las convenciones semánticas HTTP y RPC.
La métrica New Relic que impulsa la página base de datos es la métrica apm.service.external.host.duration. Consúltelo para obtener detalles sobre cómo se deriva de sus datos de OpenTelemetry.
Consumo de tiempo por persona que llama
Al hacer clic en una llamada externa específica, verá el gráfico "Consumo de tiempo por persona que llama". Este gráfico está impulsado por la métrica apm.service.transaction.overview. Esta es la misma métrica que impulsa la vista de desglose de segmentos de la página de transacciones y se deriva de los datos de lapso.
Tiempo de ejecución de JVM
La página de tiempo de ejecución de JVM proporciona herramientas para identificar problemas y analizar la JVM de un servicio Java. La página solo se muestra para servicios que emplean OpenTelemetry Java. Para diferenciar entre distintas instancias de servicio, la página requiere que se configure el atributo de recurso service.instance.id (consulte Servicios para obtener más detalles).
La página de tiempo de ejecución JVM muestra señales doradas junto con métricas de tiempo de ejecución JVM para correlacionar los problemas de tiempo de ejecución con el uso del servicio.
La consulta asume que los datos se ajustan a las convenciones semánticas métricasJVM . Tenga en cuenta que estas convenciones están incorporadas en la biblioteca de instrumentación de tiempo de ejecución de Java de OpenTelemetry, que se incluye automáticamente con el agente de Java de OpenTelemetry.
Tiempo de ejecución de Go
La página de tiempo de ejecución de Go proporciona herramientas para identificar problemas y analizar el tiempo de ejecución de un servicio Go. La página solo se muestra para servicios que emplean OpenTelemetry Go. Para diferenciar entre distintas instancias de servicio, la página requiere que se configure el atributo de recurso service.instance.id (ver Servicios para obtener más detalles).
La página de tiempo de ejecución de Go muestra señales doradas junto con métricas de tiempo de ejecución de Go para correlacionar los problemas de tiempo de ejecución con el uso del servicio.
La consulta supone que los datos son producidos por la biblioteca de instrumentación en tiempo de ejecuciónOpenTelemetry Go. Tenga en cuenta que actualmente no existen convenciones semánticas para la métrica del tiempo de ejecución de Go.
Logs
La página de Logs proporciona herramientas para identificar problemas y analizar el log de un servicio. Consulte Usar UI de log para obtener más información.
Errors Inbox
La página Bandeja de entrada de errores proporciona herramientas para detectar y clasificar los errores de un servicio. Consulte Primeros pasos con la Bandeja de entrada de errores para obtener más detalles.
La página Bandeja de entrada de errores se basa en datos de traza. Al igual que con las señales doradas, los intervalos se clasifican como errores si el estado del intervalo se establece en ERROR (por ejemplo, otel.status_code = ERROR).
Los intervalos de error se agrupan por su huella digital de error, y se calculan normalizando valores de identificación como UUID, valores hexadecimales, direcciones de email, etc. Cada intervalo de error distinto es una instancia individual dentro del grupo de errores. El mensaje del grupo de errores se determina de la siguiente manera:
- Descripción del estado del intervalo (por ejemplo,
otel.status_description) rpc.grpc.status_codeDe las convenciones semánticas de RPChttp.status_codeDe las convenciones semánticas de HTTPhttp.response.status_codeDe las convenciones semánticas de HTTPundefinedsi ninguno de los anteriores está presente
Vista de lapso (heredada)
En el pasado, los servicios instrumentados de OpenTelemetry ofrecían una experiencia de usuario completamente diferente a la del agente de idiomas de New Relic. Esta experiencia más antigua proporcionó gráficos seleccionados impulsados por datos de lapso. Los datos de lapso generalmente se muestrean, por lo que pueden ser engañosos, particularmente cuando se representan cosas como el rendimiento.
Por ahora, la antigua experiencia de usuario todavía está disponible a través de la página Vista Span (heredada). En la parte superior, contiene cuatro pestañas: Resumen, Transacciones, Base de datos y Servicios externos. Todos los gráficos en estas pestañas se basan en datos de intervalo.
Sugerencia
vista heredada basada en tramos
Nuestra antigua experiencia OpenTelemetry APM nos permitió visualizar datos desde perspectivas tanto métricas como de amplitud. Dado que los datos de extensión generalmente se muestrean, las métricas brindan mediciones de rendimiento y tiempo de respuesta más precisas. La vista basada en lapsos aún está disponible, pero se eliminará gradualmente. Consulte Vista de tramo (heredado) para obtener más detalles.
Métrica New Relic APM derivada de datos de span
Las métricas New Relic APM que impulsan la experiencia APM generalmente se derivan de datos métricos. Sin embargo, hay algunos escenarios en los que las métricas APM se derivan de datos de intervalo. Para los siguientes escenarios, tenga en cuenta que la estrategia de ejemplificación que esté empleando influirá en la métrica generada.
Desglose de segmentos
La vista de desglose del segmento de transacción se basa en datos de lapso. Consulte el desglose de segmentos para obtener más información.
base de datos de llamadas
Las convenciones semánticas de la base de datos OpenTelemetry fueron declaradas recientemente estables. Sin embargo, la mayoría de los instrumentos de base de datos aún no adoptaron las convenciones estables y aún no emiten datos métricos. Por lo tanto, al emplear instrumentación más antigua, las métricas que rigen la página base de datos se generan a partir de datos span. Se recomienda actualizar a la última instrumentación de base de datos estable tan pronto como esté disponible para su idioma.
Sistemas de mensajería
Las convenciones semánticas de mensajería de OpenTelemetry aún están en desarrollo. La mayoría de la instrumentación de mensajería aún no emite datos métricos. New Relic representa las interacciones con los sistemas de mensajería como transacciones no sitio web. Consulte Cómo se derivan las transacciones de los datos de OpenTelemetry para obtener más información.
OpenTelemetry Ruby
OpenTelemetry ahora admite métrica para la mayoría de los lenguajes, sin embargo Ruby es una excepción notable. Para Ruby, realizamos un esfuerzo de máxima fe para generar una métrica New Relic APM a partir de datos de intervalo.
Servicio APM métrica
La unidad métrica apm.service.* impulsa la experiencia APM de New Relic. Las siguientes secciones describen los datos de origen OpenTelemetry que se emplean para derivar la métrica apm.service.*.
recurso métrico
Los siguientes atributos de recurso se copian de los datos de origen a APM métrica:
container.identity.guidhost.nameinstrumentation.providerk8s.cluster.namek8s.container.namek8s.namespace.namek8s.pod.nameservice.instance.idservice.name
métrica: apm.service.transaction.duration
Nombre | Unidad (UCUM) | Descripción | |
|---|---|---|---|
| Distribución |
| Duración de las transacciones. [2] |
Atributo | Tipo | Descripción | Ejemplo |
|---|---|---|---|
|
| El nombre de la transacción. |
|
|
| El tipo de transacción. |
|
|
| Describe una clase de error con el que finalizó la transacción. |
|
[1]: Se copia la unidad de la métrica de origen.
[2]: Si error.type se resuelve como un valor distinto de nulo, apm.service.error.count se incrementa con el recuento respectivo de los datos de origen.
fuentes métricas
Convención semántica | Nombre de la métrica | Condiciones |
|
|
|
|---|---|---|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
métrica: apm.service.transaction.overview
Nombre | Unidad (UCUM) | Descripción | |
|---|---|---|---|
| Resumen | s | Tiempo de ruptura del segmento de una transacción. |
Atributo | Tipo | Descripción | Ejemplo |
|---|---|---|---|
|
| El nombre de la transacción. |
|
|
| El tipo de transacción. |
|
dominio atributo | varios | atributo específico del dominio que depende de la convención de origen, incluyendo: | Ver |
Fuentes de span
Convención semántica | Tipo de lapso | Condiciones |
|
| dominio atributo |
|---|---|---|---|---|---|
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
métrica: apm.service.external.host.duration
Nombre | Unidad | (UCUM) | Descripción | |
|---|---|---|---|---|
| Distribución |
| Duración de las llamadas externas. |
Atributo | Tipo | Descripción | Ejemplo |
|---|---|---|---|
|
| Dominio del servidor si está disponible sin búsqueda DNS inversa; de lo contrario, dirección IP o nombre de socket de dominio Unix |
|
[1]: Se copia la unidad de la métrica de origen.
fuentes métricas
Convención semántica | Nombre de la métrica | Condiciones |
|
|---|---|---|---|
|
|
| |
|
|
| |
|
|
|
métrica: apm.service.datastore.operation.duration
Nombre | Unidad (UCUM) | Descripción | |
|---|---|---|---|
| Distribución |
| Duración de las llamadas de almacenamiento de datos. |
[1]: Se copia la unidad de la métrica de origen.
Atributo | Tipo | Descripción | Ejemplo |
|---|---|---|---|
|
| El producto del sistema de gestión de base de datos (DBMS) identificado por la instrumentación del cliente. |
|
|
| El nombre de una colección (tabla, contenedor) dentro de la base de datos. |
|
|
| El nombre de la operación o comando que se está ejecutando. |
|
|
| Resumen de baja cardinalidad de una consulta de la base de datos. |
|
fuentes métricas
Convención semántica | Nombre de la métrica | Condiciones |
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
Funciones auxiliares
Las funciones auxiliares son referencias a fragmentos de la lógica del atributo mapeo que son más complejos que las simples referencias a atributos.
Función | Descripción |
|---|---|
| Devuelve el valor de cadena de |
| Devuelve el valor de cadena de rpc.grpc.status_code si en el conjunto: |
| Devuelve la primera palabra en |
| Devuelve la primera palabra en |
| marcador de posición para |
Señales doradas
Las señales doradas de rendimiento, tiempo de respuesta y tasa de errores aparecen en varios lugares de la OpenTelemetry APM UI. Cuando se emplean, se calculan de la siguiente manera:
Para métrica, la consulta asume que los datos se ajustan a las convenciones semánticas HTTP métrica o RPC métrica .
Para los tramos, las consultas son genéricas y emplean únicamente el modelo de datos de tramos de nivel superior. Los intervalos se cuentan para el rendimiento y el tiempo de respuesta si son intervalos de entrada raíz en un servicio, se calculan empleando una heurística de WHERE span.kind = server OR span.kind = consumer. Los intervalos son errores si tienen un código de estado de ERROR (por ejemplo, otel.status_code = ERROR).
Limitar datos con filtros
Varias páginas incluyen una barra de filtros, con opciones como Restringir datos a.... Esto le permite filtrar consultas en la página para que coincidan con los criterios. Por ejemplo, puede restringir el despliegue a un canary en individuo filtrando por service.version='1.2.3-canary'. Los filtros se conservan al navegar entre páginas.
Métricas doradas
Las métricas doradas son versiones de baja cardinalidad de datos de señales doradas, como HTTP/RPC métrica. Pueblan varias experiencias de plataforma, incluida la entidad Explorer, la página de actividad de carga de trabajo y la página de detalles de seguimiento de cambios. Estas métricas emplean nombres como newrelic.goldenmetrics.ext.service.*.
Importante
Históricamente, las métricas doradas OpenTelemetry se calculaban a partir de tramos. Los intervalos suelen ser muestreados, por lo que solo proporcionan una imagen parcial. Ahora que las métricas están ampliamente disponibles, las métricas doradas se calculan empleando datos métricos en lugar de datos de intervalo.