Avance
Todavía estamos trabajando en esta característica, ¡pero nos encantaría que la probaras!
Esta función se proporciona actualmente como parte de una vista previa de conformidad con nuestras políticas de prelanzamiento.
Monitoree la salud y el rendimiento de su colector de OpenTelemetry con una experiencia de UI de APM dedicada. Cuando su colector falla o funciona incorrectamente, puede causar una interrupción de los datos de observabilidad, pérdida permanente de datos o información distorsionada. Por eso creamos Collector Observability: una experiencia de APM diseñada para el trabajo de streaming que realizan los recopiladores. Puede aprovechar la telemetría interna del recopilador para ver de un vistazo cómo se desempeña cada componente de su recopilador, de modo que pueda detectar problemas antes de que afecten su pipeline de observabilidad.
Configurar el monitoreo del colector
Facturación
Su uso de Collector Observability es facturable durante la versión preliminar de conformidad con su Orden, según corresponda al modelo de precios asociado a su Cuenta y como se define a continuación.
Los costos asociados con esta función están determinados por los siguientes factores, según corresponda al modelo de precios asociado a su Cuenta:
Core Compute: La página de Resumen, medida en Core CCU, es facturable durante la vista previa. La página de Procesos no es facturable durante la vista previa.
Ingesta de datos: Los datos adicionales de la telemetría interna, medidos en GB ingestados, son facturables durante la vista previa.
Si esta función pasa a estar disponible de forma general, su uso será facturable de acuerdo con su Orden.
Habilite la telemetría interna para su colector
De forma predeterminada, el recopilador no emite su telemetría interna, por lo que deberá habilitarla primero.
Descargar el archivo de configuración
$curl 'https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/heads/main/examples/internal-telemetry-config.yaml' \> --silent --output internal-telemetry-config.yamlEstablecer variables de entorno
INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY: Clave de licencia de ingesta para la cuenta a la que se debe enviar la telemetría interna. Esta clave puede ser diferente a la clave que utiliza el colector para enviar datos regulares a New Relic, es decir,NEW_RELIC_LICENSE_KEYen el ejemplo a continuación.INTERNAL_TELEMETRY_SERVICE_NAME: El valor predeterminado esotel-collector, determina el nombre de la entidad en New RelicINTERNAL_TELEMETRY_OTLP_ENDPOINT: El valor predeterminado es EE. UU.https://otlp.nr-data.net; si está en la UE, establezca esto enhttps://otlp.eu01.nr-data.net
Ejecutar el colector con la configuración fusionada
Además de la configuración normal para componentes y pipelines (en el siguiente ejemplo --config=/etc/nrdot-collector/config.yaml), agregue un segundo argumento --config que combinará ambas configuraciones:
$docker run \> -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \> -e NEW_RELIC_LICENSE_KEY='...' \> -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \> -v './internal-telemetry-config.yaml:/etc/nrdot-collector/config-internal.yaml' \> newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \> --config='/etc/nrdot-collector/config-internal.yaml'Importante
El orden de los argumentos de --config importa si tiene una configuración preexistente bajo el nodo service::telemetry. El colector utiliza una estrategia de 'el último gana' a nivel de nodo al fusionar configuraciones y ciertas partes de la configuración (p. ej., listas, nodos hoja) no se pueden fusionar, por lo que se sobrescriben con el último argumento --config.
Alternativa (no recomendada para producción)
No recomendamos esto por razones de confiabilidad, pero para fines de prueba también puede hacer referencia a la configuración directamente y el colector la obtendrá al inicio:
$docker run \> -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \> -e NEW_RELIC_LICENSE_KEY='...' \> -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \> newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \> --config='https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/tags/1.10.0/examples/internal-telemetry-config.yaml'Agregar etiqueta de entidad
La etiqueta newrelic.service.type: otel_collector actúa como una opción de participación en la experiencia a nivel de la interfaz de usuario. Seleccione una de las siguientes opciones:
- Opción 1: Use la configuración de ejemplo proporcionada arriba que contiene la configuración de la Opción 2.
- Opción 2: Agregue el argumento
--config=yaml:service::telemetry::resource::newrelic.service.type: otel_collectoral colector. Esto agrega el atributo como un atributo de recurso y New Relic realiza el etiquetado por usted en la ingesta. Si elimina esta opción, la etiqueta tardará un día en expirar. - Opción 3: Agregar etiqueta mediante la UI de APM (parte superior de la página, junto al nombre de la entidad). También puede eliminar esto a través de la interfaz de usuario para volver a cambiar.
Personalización de la configuración
La configuración predeterminada expone variables de entorno adicionales de la forma INTERNAL_TELEMETRY_... para ajustar opciones comunes, como los niveles de detalle y el muestreo. Consulte la configuración en sí para obtener más detalles.
Recomendamos utilizar la configuración predeterminada para monitorear su colector. Sin embargo, puede modificar la configuración de ejemplo para satisfacer sus necesidades, como reducir el nivel de detalle, el muestreo o las tasas de recolección de datos. Consulte la documentación oficial para obtener más detalles. Tenga en cuenta que los cambios en la configuración pueden provocar que ciertas partes de la interfaz de usuario no muestren datos. Consulte también Limitaciones. Las opciones de configuración de la telemetría interna del recopilador cambian a medida que la comunidad de OTel evoluciona. Tiene control total sobre su configuración, incluido si desea utilizar los valores predeterminados proporcionados.
Consideraciones de sobrecarga
Al igual que toda telemetría, la telemetría interna del colector aumenta su ingesta de datos. La sobrecarga depende de su carga de trabajo y configuración. Estos son los factores clave a tener en cuenta:
Métricas Genera una sobrecarga constante para el recopilador y todos los componentes activos, independientemente del rendimiento. Las métricas se emiten en un intervalo constante (60 segundos por defecto). Cualquier componente puede emitir métricas personalizadas, como lo indica el respectivo metadata.yaml, lo que puede aumentar la sobrecarga.
Si necesita reducir la cantidad de métricas que emite su colector, recomendamos establecer el nivel de métrica en normal, p. ej. a través de la variable de entorno INTERNAL_TELEMETRY_METRICS_LEVEL en la configuración de ejemplo, ya que la interfaz de usuario solo utiliza un subconjunto de las métricas de detailed y suelen ser métricas destinadas a ajustar el rendimiento o a problemas de red, por lo que puede volver a habilitarlas según sea necesario.
Logs Tiene un impacto mínimo durante la operación normal. Puede ocurrir una mayor sobrecarga cuando los logs de errores aumentan rápidamente, pero esto se reduce porque los logs se muestrean de forma predeterminada. El algoritmo de muestreo permite un número constante de logs por intervalo definido y luego muestrea a una tasa estática. Consulte service::telemetry::logs::sampling.
Trazas Deshabilitado por defecto debido a:
- Madurez limitada de las trazas. No todos los componentes están instrumentados, consulte este problema de GitHub.
- Sobrecarga impredecible que varía con la carga de trabajo y la configuración de lotes de los agentes y recopiladores ascendentes.
- No hay algoritmo de muestreo adaptativo disponible. Esto hace imposible proporcionar una recomendación de muestreo universal que no conlleve el riesgo de costos inesperados para ciertos casos de uso.
Cuando las trazas maduren, proporcionarán información valiosa sobre cuánto tiempo dedica el colector a procesar datos a nivel de componente. Para experimentar con las trazas a medida que se desarrollan, configure INTERNAL_TELEMETRY_TRACE_LEVEL=info y comience con una tasa de muestreo baja como INTERNAL_TELEMETRY_TRACE_SAMPLE_RATIO=0.001 (0.1%) mientras monitorea su volumen de ingesta y ajusta según sea necesario.
Ver su colector en la interfaz de usuario
Explore la telemetría interna en la UI de APM
Para ver la telemetría interna de su colector, navegue a APM & Services > Services - OpenTelemetry > your_collector_name para explorar la entidad del colector.
Dependiendo de los componentes que utilice su colector, es posible que algunos gráficos no se rellenen. Por ejemplo, si no procesa los logs en su colector, los gráficos relacionados con esa señal estarán vacíos.
Página de resumen
La página de Resumen le proporciona una descripción general de la salud y el rendimiento de su colector:
- Métricas generales de salud del colector
- Gráficos para receptores, procesadores, exportadores y comportamiento de procesamiento por lotes (requiere batchprocessor)
- Gráfico dedicado para memorylimiter debido a su modo de falla único
- Relaciones de infraestructura y métricas (si está configurado, consulte ejemplos de configuración)
Página de procesos
Rastree el consumo de recursos a nivel de sistema con la página Procesos:
- Utilización y tendencias de la CPU
- Uso de memoria y patrones
- Indicadores de rendimiento a nivel de proceso
Ejemplos de configuración
Esta sección contiene ejemplos de cómo la guía paso a paso anterior se traduce a diferentes casos de uso que involucran al colector.
Colector simple con telemetría interna habilitada
Ejemplo mínimo de un colector ejecutándose con docker compose.
Poblar relaciones de infraestructura (opcional, experimental)
Como se muestra arriba, APM puede mostrar métricas de infraestructura para la infraestructura en la que se ejecuta el colector, pero solo si su infraestructura está instrumentada y se puede establecer una relación. La relación está determinada por atributos adicionales en la telemetría interna del colector. Puede leer más sobre este tema en nuestra documentación de OTel. Los pasos para configurar esto dependen en gran medida de su infraestructura exacta. Para la opción común de Kubernetes, creamos un ejemplo que muestra cómo lograr relaciones entre contenedores y servicios basado en nuestra solución de OTel para Kubernetes.
Limitaciones
La telemetría del recopilador aún no es estable:
- La versión admitida de telemetría interna se define implícitamente por la versión del recopilador principal que usamos para construir NRDOT; consulte la versión del otlpreceiver en el manifiesto de nrdot-collector.
- Si la telemetría emitida cambia durante la Vista previa pública, nos reservamos el derecho de dar soporte solo a la versión más reciente.
Requisitos de formato de exportación: La interfaz de usuario del recopilador espera telemetría en el formato exportado por el
otlpexporter. No admite métricas exportadas a través de Prometheus.Métricas de componentes personalizados: La telemetría interna que no aparece en la documentación de telemetría interna aún no se admite. Los componentes personalizados o de contribución emiten métricas estándar, pero también pueden definir sus propias métricas. Seguimos trabajando en una forma de ayudarlo a obtener información de ellos sin crear dashboards personalizados.
Métricas doradas para contenedores OTel: Aún no cuenta con soporte completo, lo que significa que algunas columnas en el panel de infraestructura podrían no completarse para los contenedores.