Solucionar problemas de APM

Si experimentas un comportamiento inesperado mientras utilizas Datadog APM, lee la información de esta página para resolver el problema. Datadog recomienda actualizar regularmente a la última versión de las bibliotecas de rastreo de Datadog que utilices, ya que cada versión contiene mejoras y correcciones. Si sigues experimentando problemas, ponte en contacto con el soporte de Datadog.

Los siguientes componentes intervienen en el envío de datos de APM a Datadog:

Pipeline de solucionar problemas de APM

Para más información, consulta Soporte adicional.

Retención de trazas

Esta sección aborda cuestiones relacionadas con la retención y filtrado de datos de trazas a través de Datadog.

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.

PRODUCTOFUENTE DEL TRAMO
MonitoresTramos de filtros de retención personalizados
Otros productos
(dashboard, notebook, etc.)
Tramos de filtros de retención personalizados + filtro inteligente de Datadog

Métricas de traza

Esta sección trata de las discrepancias e incoherencias de la solución de problemas con métricas de traza.

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:

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.

Los nombres de métrica deben seguir la convención de nomenclatura de métricas. Los nombres de métrica que empiecen por trace.* no están permitidos y no se guardan.

Servicios

En esta sección, se describen estrategias para solucionar problemas relacionados con el 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 servicio (fase beta). Las API externas inferidas utilizan el esquema de 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í:

dd.service.mapping
Variable de entorno: DD_SERVICE_MAPPING
Por defecto: null
Ejemplo: mysql:my-mysql-service-name-db, postgresql:my-postgres-service-name-db
Renombra dinámicamente los servicios en la configuración. Es útil para hacer que las bases de datos tengan nombres distintos en diferentes servicios.
DD_SERVICE_MAPPING
Define asignaciones de nombres de servicios para permitir cambiar nombres de servicios en trazas. Por ejemplo: postgres:postgresql,defaultdb:postgresql. Disponible en la versión 0.47 o posterior.
DD_SERVICE_MAPPING
**Por defecto: null
Cambia dinámicamente el nombre de los servicios mediante la configuración. Los servicios pueden separarse con comas o espacios, por ejemplo: mysql:mysql-service-name,postgres:postgres-service-name, mysql:mysql-service-name postgres:postgres-service-name.
DD_SERVICE_MAPPING
Configuración: serviceMapping
Por defecto: N/A
Ejemplo: mysql:my-mysql-service-name-db,pg:my-pg-service-name-db
Proporciona nombres de servicio para cada complemento. Acepta pares separados por comas plugin:service-name, con o sin espacios.
DD_TRACE_SERVICE_MAPPING
renombra servicios mediante la configuración. Acepta una lista separada por comas de pares clave-valor de las claves de nombre de servicio a renombrar, y el nombre a utilizar en su lugar, en el formato [from-key]:[to-name].
Ejemplo: mysql:main-mysql-db, mongodb:offsite-mongodb-service
El valor from-key es específico del tipo de integración, y debe excluir el prefijo del nombre de la aplicación. Por ejemplo, para cambiar el nombre de my-application-sql-server a main-db, utiliza sql-server:main-db. Añadido en la versión 1.23.0
DD_SERVICE_MAPPING
INI: datadog.service_mapping
Por defecto: null
Cambia el nombre por defecto de una integración de APM. Cambia el nombre de una o más integraciones a la vez, por ejemplo: DD_SERVICE_MAPPING=pdo:payments-db,mysqli:orders-db (ver nombres de integración).

Ruby no admite DD_SERVICE_MAPPING ni DD_TRACE_SERVICE_MAPPING. Consulta Configuración adicional de Ruby para conocer las opciones de código para cambiar el nombre de servicio.

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:

TIPO DE USOMÉTRICADESCRIPCIÓN
Tramos indexados de APMdatadog.estimated_usage.apm.indexed_spansNúmero total de tramos (spans) indexados por filtros de retención basados en etiquetas.
Tramos ingeridos de APMdatadog.estimated_usage.apm.ingested_spansNúmero total de incorporación de tramos.

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.

Directrices sobre el volumen de datos

Si te encuentras con alguno de los siguientes problemas, puede que estés excediendo las directrices de volumen de Datadog:

  • Tus métricas de traza no están informando como deberían en la plataforma de Datadog.
  • Te faltan algunos de los recursos que esperabas ver en la plataforma de Datadog.
  • Estás viendo trazas desde tu servicio, pero no puedes encontrar este servicio en la página del Catálogo de servicios.

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:

  • 1000 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:

NombreCaracteres
servicio100
operación100
tipo100
recurso5000
clave de etiqueta200
valor de etiqueta25000

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.

El entorno es la etiqueta primaria por defecto

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.

Elegir un entorno específico con el menú desplegable `env` en el Catálogo de servicios

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.

Utilizar el menú desplegable para seleccionar un clúster específico o un 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.

Errores de conexión

En esta sección, se ofrece orientación para diagnosticar y resolver problemas de conexión y comunicación entre tus aplicaciones y el Datadog Agent.

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

Uso de recursos

Esta sección contiene información sobre cómo solucionar problemas de rendimiento relacionados con el uso de recursos.

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.

Seguridad

Esta sección aborda los enfoques para resolver los problemas de seguridad en APM, incluida la protección de datos confidenciales y la gestión del tráfico.

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.

Depuración y registro

Esta sección explica cómo utilizar la depuración y el inicio de logs para identificar y resolver problemas con tu rastreador 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.

Soporte adicional

Si sigues necesitando ayuda adicional, abre un tique en el soporte de Datadog.

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:

Referencias adicionales