Esta guía incluye consejos y mejores prácticas para implementar OpenTelemetry con New Relic y es útil para:
- Clientes existentes de New Relic que actualmente utilizan nuestras soluciones APM u otras soluciones de monitoreo de terceros, pero desean cambiar a OpenTelemetry
- Cualquier organización que quiera cambiar a OpenTelemetry y New Relic
Esta guía lo guiará a través de diez pasos importantes que lo ayudarán a aprovechar al máximo sus datos de OpenTelemetry con New Relic.
1. aplicación instrumentada con OpenTelemetry
El primer paso en cualquier viaje de OpenTelemetry es instrumentar su aplicación. Esta guía proporciona una descripción general de este paso y destaca algunas consideraciones importantes. Para obtener instrucciones más detalladas, consulte Cómo empezar con OpenTelemetry.
Para algunos lenguajes, como Java, .NET, Python y Node.js, OpenTelemetry proporciona un enfoque de instrumentación automática. Este es un excelente punto de partida para muchas aplicaciones que se pueden desarrollar más adelante. Las instrucciones para la instrumentación automática se pueden encontrar aquí:
- Instrumentación automática Java
- Instrumentación automática .NET
- Node.js instrumentación automática
- Instrumentación automática Python
La instrumentación manual se puede utilizar para idiomas que no admiten la instrumentación automática, como Go. También se puede utilizar para aumentar la telemetría recopilada mediante instrumentación automática.
La autoinstrumentación recoge traza y, en algunos casos, métrica. Ambas señales son importantes para observar su aplicación.
Independientemente del enfoque de instrumentación que elija, es importante comprender que varias partes de la UI de New Relic dependen de la presencia de un atributo específico para funcionar correctamente.
El atributo service.name es necesario para asociar su recurso con una entidad en la UI. Y se requiere service.instance.id para que se iluminen ciertos paneles.
Los gráficos de señales doradas para la entidad OpenTelemetry en New Relic incluyen un interruptor que le permite elegir si desea intervalos o métricas para controlar los gráficos. New Relic deriva señales doradas de tramos basados en la siguiente métrica:
http.server.durationrpc.server.durationhttp.status_code
Utilice el SDK para agregar estas métricas a la instrumentación de su aplicación si aún no están presentes con la instrumentación automática.
Todos estos atributos están definidos por las convenciones semánticas de recursos de OpenTelemetry y, por lo general, se configuran creando un recurso utilizando el SDK de OpenTelemetry.
OpenTelemetry también se puede utilizar para capturar registros. Para permitirnos correlacionar la traza de OpenTelemetry con nuestra característica de contexto de inicio de sesión, asegúrese de que los atributos service.name, trace.id y span.id estén incluidos en las entradas log . Para obtener más información sobre cómo informar el registro de OpenTelemetry, consulte nuestros documentos de registro de OpenTelemetry.
2. desplegar el recolector OpenTelemetry
A continuación, es hora de implementar el recolector OpenTelemetry, que se recomienda para usar OpenTelemetry en producción, ya que descarga tareas como procesamiento por lotes, reintentos y cifrado.
A continuación se ofrecen algunos consejos sobre cómo configurar el recolector OpenTelemetry:
Use the right endpoint
. Debe configurarse para exportar datos OTLP a nuestro extremo. Esto se explica en nuestros documentos sobre el envío de datos desde un recolector OpenTelemetry.
Avoided dropped data
.Para evitar que se eliminen datos, recomendamos truncar cualquier atributo que tenga más de 4095 caracteres de longitud. Para ver un ejemplo de aplicación de estas prácticas, consulte esta configuración del recolector.
Infrastructure
. Para recopilar infraestructura métrica, incluya el receptor métrico host en la configuración del recolector. Cuando utilizamos el receptor host como parte de la configuración del recolector, automáticamente detectamos la métrica del host como parte de una entidad host y sintetizamos sus métricas doradas (en resumen, obtienes la misma experiencia que obtendrías con nuestro agente de infraestructura).
Scaling
. Un gran despliegue de OpenTelemetry deberá elegir una estrategia para escalar el recolector, tanto para obtener beneficios de rendimiento como de resiliencia. Para obtener detalles sobre cómo escalar el recolector, consulte los documentos de OpenTelemetry.
Kubernetes
.Si sus servicios OpenTelemetry-instrumentado se ejecutan en un entorno Kubernetes, siga los pasos en Vincular la aplicación OpenTelemetry-instrumentado a Kubernetes. Esto garantiza que sus datos de Kubernetes se correlacionen con los datos de OpenTelemetry.
Muchos clientes optan por ejecutar recolector utilizando métodos de implementación tanto de agente como de puerta de enlace:
Agent
: con este método, el recolector se ejecuta en el mismo host que la aplicación (por ejemplo, binario, sidecar o daemonset).
Gateway
: con este método, una o más instancias de recolector se ejecutan como un servicio independiente por clúster, centro de datos o región.
El agente recolector en cada host realiza tareas de procesamiento básicas antes de exportar datos a un grupo de recolectores de puerta de enlace. El recolector de puerta de enlace, a su vez, está configurado para exportar datos a New Relic. Para obtener más detalles, consulte Arquitectura de referencia para OpenTelemetry con New Relic.
3. Implementar una estrategia de muestreo de trazas
De forma predeterminada, OpenTelemetry capturará el 100% de la traza de la aplicación y la enviará a New Relic. Entonces, antes de implementar OpenTelemetry en producción, se debe implementar una estrategia de muestreo para traza. Esto ayuda a reducir la sobrecarga de la aplicación relacionada con la telemetría, así como también a reducir la cantidad de datos que salen de su red y el volumen de ingesta de datos en New Relic.
Para conocer las mejores prácticas relacionadas con el muestreo de OpenTelemetry, consulte nuestros documentos de muestreo. La configuración de muestreo debe modificarse como parte del proceso de prueba de carga (que se describe a continuación), con el objetivo de garantizar suficientes datos de traza para solucionar problemas y al mismo tiempo evitar la salida e ingesta excesiva de datos.
Al utilizar muestreo tail-based, tenga cuidado de evitar tramos huérfanos y fragmentados. Para saber cómo escalar el recolector cuando se utiliza el procesador de muestreo de cola para evitar tramos huérfanos, consulte los documentos de OpenTelemetry sobre el escalado del recolector.
4. Realice pruebas de carga y ajuste la configuración.
Antes de poner OpenTelemetry en producción con una aplicación, lo mejor es realizar una prueba de carga en un entorno de preproducción. Esto le brinda la oportunidad de:
- Mida la sobrecarga de la instrumentación de OpenTelemetry en la aplicación, analizando la utilización incremental de CPU y memoria, así como la latencia del servicio.
- Mida el volumen de salida de datos del recolector y el volumen de ingesta en New Relic, ya que ambos aumentarán la ingesta y tendrán posibles impactos en la facturación.
- Esto también brinda la oportunidad de probar la carga del recolector OpenTelemetry y garantizar que pueda manejar suficientemente una carga similar a la de producción. Para obtener sugerencias sobre cómo escalar el recolector, consulte los documentos de OpenTelemetry.
5. Definir objetivos de nivel de servicio.
Una vez que los datos de OpenTelemetry fluyen hacia New Relic, es importante que defina los objetivos de nivel de servicio, para poder determinar cuándo no se cumplen los SLO y tomar las medidas correspondientes.
El nivel de servicio se utiliza para medir el desempeño de un servicio desde el punto de vista del usuario final (o aplicación cliente). Con New Relic, puede definir y consumir indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO) para su aplicación. Recomendamos configurar el nivel de servicio para los servicios instrumentados de OpenTelemetry.
Después de crear su conjunto de SLO, New Relic comenzará a generar datos SLI. La vista operativa muestra cómo su nivel de servicio mejora o degrada en diferentes ventanas de tiempo. Puede utilizar esta vista para realizar un seguimiento del logro de SLI a lo largo del tiempo (%) y ver el cumplimiento de cada nivel de servicio.
También puede monitor el presupuesto de errores para cada SLO, lo que indica qué porcentaje de solicitudes aún podrían tener una mala respuesta durante el período del SLO, sin comprometer el objetivo.
6. Configurar la gestión de alertas e incidentes
También es importante configurar la política de alertas, para que pueda detectar y solucionar problemas antes de que afecten al usuario final de la aplicación.
En un nivel alto, se configuran mediante política de alertas, que incluye una o más condiciones de alerta. incidente de condición de alerta se agrupan como problemas. Finalmente, los problemas pueden desencadenar un flujo de trabajo que incluye lógica para convertir los problemas en notificaciones. Para obtener un diagrama que le ayude a comprender estos conceptos, consulte Conceptos de alertas.
Por ejemplo, podría definir una condición de alerta para abrir un incidente si el tiempo de respuesta de un servicio instrumentado por OpenTelemetry supera los 500 ms. Luego, podría definir un flujo de trabajo que envíe una notificación por correo electrónico a una lista de distribución cuando se produzca el incidente de la condición de alerta, o notificar a un equipo de guardia mediante Slack.
También puede configurar alertas sobre el nivel de servicio, para notificarle cuando ocurra un incidente de impacto significativo en el negocio.
Para saber cómo crear una política de alertas con condiciones, consulte Cree su primera alerta. Para saber cómo convertir problemas en notificación, consulte flujo de trabajo. Al crear un flujo de trabajo, puede especificar uno o más destinos para enviar notificaciones a sistemas de terceros, como Slack, ServiceNow y Jira.
Integrar New Relic alerta con sistemas y procesos de gestión de incidentes es clave para obtener valor de los datos de OpenTelemetry porque brinda más visibilidad a los problemas de la aplicación y proporciona información valiosa que facilita la rápida solución de los problemas.
Para obtener más consejos sobre alertas:
7. Crear carga de trabajo para la entidad relacionada con el grupo.
New Relic carga de trabajo le permite agrupar entidades relacionadas, proporcionando datos agregados de salud y actividad desde los servicios frontend hasta backend en toda su stack. carga de trabajo lo ayuda a comprender el estado de sistemas complejos, detectar problemas, comprender la causa y el impacto de un incidente y resolver esos problemas rápidamente.
Recomendamos crear carga de trabajo para agrupar los servicios de OpenTelemetry junto con la entidad relacionada. Esto podría incluir el monitoreo de entidad por parte de nuestro monitoreo de infraestructura, , el monitoreo de Kubernetes, y otras entidades. carga de trabajo le ayuda a agrupar entidades en partes más manejables, generalmente alineadas con los equipos responsables de esas entidades. Esto es especialmente valioso para entornos grandes, que pueden tener miles de entidades de monitor.
La creación de carga de trabajo desbloquea otras características valiosas en New Relic, como Errors Inbox. Con Errors Inbox, sus equipos pueden detectar, clasificar y tomar medidas de manera proactiva sobre todos los errores antes de que afecten a sus clientes. Los errores se agrupan de forma inteligente para reducir el ruido y garantizar que los errores críticos se detecten de forma rápida y eficiente. Esto le permite a su equipo resolver errores de toda su stack, incluidos errores de datos de APM, browser (RUM), dispositivos móviles, AWS Lambda Serverless y OpenTelemetry, que se muestran en una pantalla.
A medida que OpenTelemetry se implementa para los servicios de su aplicación, recomendamos utilizar Errors Inbox para revisar y corregir de manera proactiva los errores más comunes antes de que afecten al usuario final. Para saber qué atributos de OpenTelemetry utiliza Errors Inbox para identificar grupos de errores, consulte Cómo se crean huellas digitales únicas.
8. Cree un panel para visualizaciones personalizadas
New Relic proporciona una serie de vistas listas para usar de sus datos de OpenTelemetry para ayudarlo a comenzar. A medida que sus equipos comiencen a utilizar los datos para la resolución de problemas y a identificar problemas de manera proactiva, es posible que descubra la necesidad de visualizaciones personalizadas. Puedes crear un panel personalizado para este propósito.
Para conocer los beneficios de crear un panel personalizado y cómo comenzar a utilizarlos, consulte Panel.
9. Agregue contexto con instrumentación personalizada
Ya sea que se comience con instrumentación automática o manual, a menudo tendrá sentido agregar instrumentación adicional con el tiempo a medida que surjan necesidades de datos adicionales durante la clasificación de problemas. Por ejemplo:
- Se puede agregar atributo a los intervalos para proporcionar contexto adicional sobre la solicitud, lo que puede ser útil durante la resolución de problemas para comprender el impacto del problema en el negocio (por ejemplo, agregar el ID del inquilino a un intervalo, para ayudar con la resolución de problemas de una aplicación multiinquilino). .
- Se pueden capturar tramos anidados adicionales, lo que proporciona más detalles para la resolución de problemas de un aspecto particular de la aplicación con mayor profundidad.
- La métrica personalizada se puede capturar, ya sea desde una perspectiva técnica (por ejemplo, rastrear el número de aciertos de caché y errores) o desde una perspectiva comercial (por ejemplo, rastrear el número promedio de artículos en el carrito durante el proceso de pago).
Los documentos de OpenTelemetry brindan orientación y ejemplos de estos y más por idioma. Por ejemplo, cuando utilice Java, puede utilizar los siguientes documentos:
También tenemos algunos ejemplos que muestran una instrumentación manual de OpenTelemetry utilizando varios lenguajes.
10. Usar, medir y perfeccionar
Para mejorar su madurez de observabilidad, es importante adoptar una mentalidad de mejora continua. Como OpenTelemetry y otros datos capturados en New Relic se utilizan para solucionar problemas, debe tomar nota de lo siguiente y tomar las medidas necesarias:
- ¿La condición de alerta existente detectó proactivamente el problema antes de que el usuario final se viera afectado? De lo contrario, debería modificar las condiciones de alerta o agregar otras nuevas.
- ¿Siguen apareciendo alertas críticas que no requieren ninguna acción? Si es así, la condición de alerta debe modificarse para que solo se planteen aquellas condiciones que requieren acción.
- ¿Se proporcionaron suficientes detalles en la traza para solucionar el problema? De lo contrario, debería revisar la instrumentación y considerar capturar más atributos de tramo y tramos anidados.
- ¿Se requirió una consulta NRQL personalizada para solucionar el problema? Si es así, debería considerar incorporar algunos de los gráficos resultantes al panel.
A medida que la instrumentación se perfeccione con el tiempo, se mejorará la capacidad de detectar problemas de forma proactiva y se reducirá el tiempo para resolverlos. Esto conduce a una reducción tanto del tiempo medio de detección (MTTD) (tiempo medio de detección) como del MTTR (tiempo medio de resolución).
Contamos con una guía de gestión de calidad de alertas que lo guía a través del proceso de mejora y optimización de la calidad de sus alertas, lo que en última instancia conduce a un mayor tiempo de actividad y disponibilidad, un MTTR reducido y un menor volumen de alertas.
También contamos con una guía de administración a nivel de servicio que le explica cómo mejorar y optimizar la calidad de su administración a nivel de servicio. La implementación exitosa de estas recomendaciones puede proporcionar los siguientes beneficios:
- Reducción del número de incidentes que perturban el negocio
- MTTR reducido
- Esfuerzo reducido por incidente