Si no has configurado filtros de retención personalizados, este es el comportamiento esperado. A continuación, explicamos por qué:

La página Trace Explorer te permite buscar todos los tramos ingeridos o indexados mediante cualquier etiqueta (tag). Aquí puedes consultar cualquiera de tus trazas.

Por defecto, después de que los tramos se hayan ingerido, el filtro inteligente de Datadog los retiene. Datadog también tiene otros filtros de retención que están habilitados por defecto para darte visibilidad sobre tus servicios, endpoints, errores y trazas de alta latencia.

Sin embargo, para utilizar estas trazas en tus monitores, debes establecer filtros de retención personalizados.

Los filtros de retención personalizados permiten decidir qué tramos se indexan y retienen al crear, modificar y desactivar filtros adicionales basados en etiquetas. También puedes establecer un porcentaje de tramos que coincidan con cada filtro que deba retenerse. Estas trazas indexadas pueden utilizarse en tus monitores.

Las métricas de traza y las métricas basadas en tramos personalizados pueden tener valores diferentes porque se calculan a partir de conjuntos de datos distintos:

• Las métricas de traza se calculan sobre la base del 100% del tráfico de la aplicación, independientemente de tu configuración del muestreo de ingesta de trazas. El espacio de nombres del rastreo sigue este formato: trace.<SPAN_NAME>.<METRIC_SUFFIX>.
• Las métricas basadas en tramos personalizados se generan a partir de tus tramos ingeridos, que depende de tu muestreo de ingesta de trazas. Por ejemplo, si estás ingiriendo el 50% de tus trazas, tus métricas basadas en tramos personalizados se basan en el 50% de los tramos ingeridos.

Para garantizar que tus métricas de traza y tus métricas basadas en tramos personalizados tengan el mismo valor, configura una tasa de ingesta del 100% para tu aplicación o servicio.

Esto puede ocurrir cuando el nombre de servicio no es coherente en todos los tramos.

Por ejemplo, puedes tener un único servicio como service:test mostrando múltiples servicios en Datadog:

• service:test
• service:test-mongodb
• service:test-postgresdb

Puedes utilizar dependencias inferidas de servicios (Vista previa). Las API externas inferidas utilizan la nomenclatura por defecto net.peer.name. Por ejemplo: api.stripe.com, api.twilio.com y us6.api.mailchimp.com. Las bases de datos inferidas utilizan la nomenclatura por defecto scheme db.instance.

O bien, puedes fusionar los nombres de servicio utilizando una variable de entorno como DD_SERVICE_MAPPING o DD_TRACE_SERVICE_MAPPING, según el lenguaje.

Para más información, consulta Configurar la biblioteca de rastreo de Datadog o elige tu lenguaje aquí:

Los picos en la ingesta e indexación de datos pueden deberse a varios factores. Para investigar la causa de un aumento, utiliza la función métricas de uso estimado de trazas de APM:

El dashboard de uso de trazas de APM contiene varios grupos de widget que muestran KPI muy importantes e información de uso adicional.

En algunas trazas con un estado de error, la pestaña Errors (Errores) muestra Missing error message and stack trace en lugar de los detalles de la excepción.

Un tramo puede mostrar este mensaje por dos posibles razones:

• El tramo contiene una excepción no controlada.
• Una respuesta HTTP dentro de tramo devuelve un código de estado HTTP entre 400 y 599.

Cuando se maneja una excepción en un bloque try/catch, las etiquetas de tramo error.message, error.type y error.stack no se rellenan. Para rellenar las etiquetas de tramo de error detallado, utiliza el código Instrumentación personalizada.

Tu aplicación instrumentada puede enviar tramos con marcas temporales de hasta 18 horas en el pasado y dos horas en el futuro a partir de la hora actual.

Datadog acepta las siguientes combinaciones para un intervalo determinado de 40 minutos:

• 5000 combinaciones únicas de environments y service
• 30 second primary tag values únicos por entorno
• 100 operation names únicos por entorno y servicio
• 1000 resources únicos por entorno, servicio y nombre de operación
• 30 versions únicas por entorno y servicio

Si necesitas acomodar volúmenes más grandes, ponte en contacto con el soporte de Datadog e indícanos tu caso de uso.

Datadog trunca las siguientes cadenas si superan el número de caracteres indicado:

Además, el número de etiquetas de tramo presentes en cualquier tramo no puede exceder de 1024.

Si el número de servicios excede lo especificado en las directrices de volumen de datos, intenta seguir estas prácticas recomendadas para las convenciones de nomenclatura de servicio.

Excluir los valores de etiqueta de entorno de los nombres de servicio

Por defecto, el entorno (env) es la etiqueta primaria para Datadog APM.

Un servicio suele desplegarse en varios entornos, como prod, staging y dev. Las métricas de rendimiento, como el recuento de solicitudes, la latencia y la tasa de errores, difieren entre varios entornos. El menú desplegable de entorno en el Catálogo de servicios te permite limitar los datos de la pestaña Performance (Rendimiento) a un entorno específico.

Un patrón que suele provocar problemas con un número abrumador de servicios es incluir el valor de entorno en los nombres de servicio. Por ejemplo, es posible que tengas dos servicios únicos en lugar de uno, ya que funcionan en dos entornos distintos: prod-web-store y dev-web-store.

Datadog recomienda ajustar tu instrumentación renombrando los servicios.

Las métricas de traza no están muestreadas, lo que significa que tu aplicación instrumentada muestra todos los datos, en lugar de subsecciones de ellos. También se aplican las directrices de volumen.

Utilizar la segunda etiqueta primaria en lugar de poner particiones de métrica o agrupar variables en nombres de servicio

Las segundas etiquetas primarias son etiquetas adicionales que puedes utilizar para agrupar y añadir tus métricas de traza. Puedes utilizar el menú desplegable para limitar los datos de rendimiento a un determinado nombre de clúster o valor de centro de datos.

Incluir particiones de métrica o variables de agrupación en los nombres de servicio en lugar de aplicar la segunda etiqueta primaria aumenta innecesariamente el número de servicios únicos en una cuenta y provoca posibles retrasos o pérdidas de datos.

Por ejemplo, en lugar del servicio web-store, podrías decidir nombrar diferentes instancias de un servicio web-store-us-1, web-store-eu-1 y web-store-eu-2 para ver las métricas de rendimiento para estas particiones en paralelo. Datadog recomienda implementar el valor de región (us-1, eu-1, eu-2) como una segunda etiqueta primaria.

Lee cómo encontrar y solucionar estos problemas en Errores de conexión.

Lee sobre la detección del uso de la CPU de recopilación de trazas y sobre el cálculo de los límites de recursos adecuados para el Agent en Uso de recursos del Agent.

Dentro de los logs del Datadog Agent, si ves mensajes de error sobre límites de tasa o eventos máximos por segundo, puedes cambiar estos límites siguiendo estas instrucciones. Si tienes alguna duda, antes de cambiar los límites, consulta con el equipo de soporte de Datadog.

Hay varias opciones de configuración disponibles para limpiar datos confidenciales o descartar trazas correspondientes a los checks de estado u otro tráfico no deseado que pueden configurarse dentro del Datadog Agent o, en algunos lenguajes, el cliente de rastreo. Para más detalles sobre las opciones disponibles, consulta Seguridad y personalización de Agent. Aunque esto ofrece ejemplos representativos, si necesitas ayuda para aplicar estas opciones a tu entorno, ponte en contacto con el soporte de Datadog.

Para capturar todos los detalles en el rastreador de Datadog, habilita el modo de depuración en tu rastreador mediante la variable de entorno DD_TRACE_DEBUG. Puedes habilitarlo para tu propia investigación o si el soporte de Datadog lo ha recomendado para propósitos de triaje. Sin embargo, asegúrate de desactivar el registro de depuración cuando hayas terminado los tests para evitar la sobrecarga de registro que introduce.

Estos logs pueden mostrar errores de instrumentación o errores específicos de integración. Para obtener más información sobre la activación y captura de estos logs de depuración, consulta la página para solucionar problemas del modo de depuración.

Durante el inicio, las bibliotecas de rastreo de Datadog emiten logs que reflejan las configuraciones aplicadas en un objeto JSON, así como cualquier error encontrado, incluido si se puede llegar al Agent en los lenguajes donde esto es posible. Algunos lenguajes requieren que se habilite este inicio de logs con la variable de entorno DD_TRACE_STARTUP_LOGS=true. Para más información, consulta Logs de inicio.

Cuando abres un tique de soporte, el equipo de soporte de Datadog puede pedirte los siguientes tipos de información:

1. Enlaces a una traza o capturas de pantalla del problema: esto ayuda a reproducir tus problemas a efectos de solucionar problemas.

2. Logs de inicio del rastreador: los logs de inicio ayudan a identificar errores de configuración del rastreador o problemas de comunicación entre el rastreador y el Datadog Agent. Comparando la configuración del rastreador con la de la aplicación o el contenedor, los equipos de soporte pueden identificar las configuraciones aplicadas incorrectamente.

3. Logs de depuración del rastreador: los logs de depuración del rastreador proporcionan una visión más detallada que los logs de inicio, esto demuestra:

   • Una instrumentación de integración adecuada durante el flujo de tráfico de aplicación
   • Contenido de tramos creados por el rastreador
   • Errores de conexión al enviar tramos al Agent

4. Flare de Datadog Agent: los flares del Datadog Agent te permiten ver lo que está ocurriendo dentro del Datadog Agent, por ejemplo, si las trazas están siendo rechazadas o están malformadas. Esto no ayuda si las trazas no llegan al Datadog Agent, pero sí ayuda a identificar la fuente de un problema, o cualquier discrepancias en las métricas.

5. Una descripción de tu entorno: entender la configuración del despliegue de tu aplicación ayuda al equipo de soporte a identificar posibles problemas de comunicación entre el Agent y el rastreador e identificar errores de configuración. Para problemas complejos, el equipo de soporte puede solicitar manifiestos de Kubernetes, definiciones de tareas de ECS o archivos de configuración de despliegue similares.

6. Código de rastreo personalizado: la instrumentación personalizada, la configuración y añadir etiquetas de tramo puede afectar significativamente a las visualizaciones de trazas en Datadog.

7. Información sobre la versión: saber qué versiones de lenguaje, marco, Datadog Agent y rastreador de Datadog estás utilizando permite al soporte verificar requisitos de compatibilidad, buscar problemas conocidos, o recomendar una actualización de versión. Por ejemplo: