Comience con la observabilidad del recolector

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.

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.

Configuración paso a paso

Descargar el archivo de configuración

De forma predeterminada, el recopilador no emite su telemetría interna, por lo que deberá habilitarla primero.

bash

$curl 'https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/heads/main/examples/internal-telemetry-config.yaml' \
>  --silent --output internal-telemetry-config.yaml

Establecer 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_KEY en el ejemplo a continuación.
INTERNAL_TELEMETRY_SERVICE_NAME: El valor predeterminado es otel-collector, determina el nombre de la entidad en New Relic
INTERNAL_TELEMETRY_OTLP_ENDPOINT: el valor predeterminado es EE. UU. https://otlp.nr-data.net; si está en la UE, establezca esto en https://otlp.eu01.nr-data.net; si está en JP, establezca esto en https://otlp.jp.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:

bash

$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:2.5.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.

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_collector al 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.
Una vez etiquetado, consulte Ver el recolector en la UI para explorar los datos del recolector.

Opcional: personalizar 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 el recolector. 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 UI no muestren datos. Consulte también Limitaciones. Las opciones de configuración de la telemetría interna del recolector cambian a medida que la comunidad de OTel evoluciona. Tiene control total sobre la 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.

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 mencionó en la página de resumen, APM puede mostrar métricas de infraestructura para la infraestructura en la que se ejecuta el recolector, pero solo si la infraestructura está instrumentada y se puede establecer una relación. La relación está determinada por atributos adicionales en la telemetría interna del recolector. Puede leer más sobre este tema en nuestra documentación de OTel. Los pasos para configurar esto dependen en gran medida de la 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.

Te ofrecemos esta traducción automática para facilitar la lectura.