Facilitar la resolución de problemas a través de la correlación entre productos
El etiquetado unificado de servicios ofrece capacidades de correlación de alto nivel. En ocasiones, es posible que los puntos de partida de tu investigación sean un log, una traza, una vista o un test Synthetic únicos. Correlacionar logs, trazas y vistas con otros datos proporciona un contexto útil que te permite calcular el impacto en tus actividades e identificar la causa raíz de un problema rápidamente.
En esta guía te explica cómo correlacionar los datos de toda la pila. Dependiendo de tu caso de uso, puedes omitir algunos pasos. Los pasos que dependen de otros se indican explícitamente.
- Correlacionar logs del lado del servidor con trazas
- Correlacionar productos frontend
- Correlacionar la experiencia del usuario con el comportamiento del servidor
Correlacionar logs del lado del servidor con trazas
Cuando tus usuarios encuentran errores o una latencia elevada en tu aplicación, la visualización de logs específicos de una solicitud problemática puede revelar exactamente qué ha salido mal. Al reunir todos los logs relativos a una solicitud determinada, puedes ver con lujo de detalles cómo se ha gestionado de principio a fin y así diagnosticar rápidamente el problema.
Correlacionar tus logs con trazas también facilita la aplicación de una agresiva estrategia de muestreo sin pérdida de coherencia a nivel de la entidad mediante el uso de trace_id.
La correlación de logs de aplicación te proporciona una amplia visibilidad de toda tu pila, pero algunos casos de uso específicos requieren una correlación más profunda en tu pila. Sigue los siguientes enlaces para completar la configuración de cada caso de uso:
Correlacionar logs de aplicación
¿Por qué?
Los logs de aplicación ofrecen el mayor contexto en torno a la mayoría de los problemas de código y de lógica empresarial. Incluso pueden ayudarte resolver otros problemas de servicios. Por ejemplo, la mayoría de los errores de base de datos de logs de ORM.
¿Cómo?
Utiliza una de las varias correlaciones OOTB. Si utilizas un rastreador personalizado o si tienes algún problema, consulta la sección de FAQ acerca de correlaciones.
Correlacionar logs de proxy
¿Por qué?
Los logs de proxy proporcionan más información que los logs de aplicación, ya que abarcan más puntos de entrada y brindan información sobre el contenido estático y las redirecciones.
¿Cómo?
El rastreador de aplicaciones genera los ID de rastreo por defecto. Esto se puede cambiar inyectando x-datadog-trace-id en los encabezados de solicitudes HTTP.
NGINX
Configurar OpenTracing
Consulta la integración de rastreo NGINX.
Inyectar un ID de rastreo en logs
El ID de rastreo se almacena como variable opentelemetry_trace_id. Actualiza el formato de log NGINX añadiendo el siguiente bloque de configuración en la sección HTTP de tu archivo de configuración NGINX /etc/nginx/nginx.conf:
http {
log_format main '$remote_addr - $opentelemetry_trace_id $http_x_forwarded_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" ';
access_log /var/log/nginx/access.log;
}
Analizar los ID de rastreo en pipelines
Clona el pipeline NGINX.
Personaliza el primer analizador grok:
- En *Parsing rules (Reglas de análisis), sustituye la primera regla de análisis por:
access.common %{_client_ip} %{_ident} %{_trace_id} %{_auth} \[%{_date_access}\] "(?>%{_method} |)%{_url}(?> %{_version}|)" %{_status_code} (?>%{_bytes_written}|-)
- En Advanced settings (Configuración avanzada), en Helper Rules (Reglas de ayuda), añade la línea:
_trace_id %{notSpace:dd.trace_id:nullIf("-")}
Añade un reasignador de ID de rastreo en el atributo dd.trace_id.
Correlacionar logs de base de datos
¿Por qué?
Los logs de base de datos suelen ser difíciles de contextualizar debido a la similitud de las consultas, la anonimización variable y el elevado uso.
Por ejemplo, las consultas lentas de producción son difíciles de reproducir y analizar sin invertir mucho tiempo y recursos. A continuación se muestra un ejemplo de cómo correlacionar el análisis de consultas lentas con las trazas.
¿Cómo?
PostgreSQL
Para enriquecer tus logs de base de datos
Los logs predeterminados de PostgreSQL no tienen información. Para enriquecerlos, sigue esta guía sobre integraciones.
Las prácticas recomendadas para consultas lentas también sugieren registrar planes de ejecución de sentencias lentas automáticamente, para que no tengas que ejecutar EXPLAIN manualmente. Para ejecutar EXPLAIN automáticamente, actualiza /etc/postgresql/<VERSION>/main/postgresql.conf con:
session_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '500ms'
Las consultas de más de 500ms registran su plan de ejecución.
Nota: auto_explain.log_analyze = 'true' proporciona aún más información, pero afecta enormemente al rendimiento. Para obtener más información, consulta la documentación oficial.
Inyectar trace_id en tus logs de base de datos
Inyecta trace_id en la mayoría de tus logs de base de datos con comentarios SQL. El siguiente es un ejemplo con Flask y SQLAlchemy:
if os.environ.get('DD_LOGS_INJECTION') == 'true':
from ddtrace import tracer
from sqlalchemy.engine import Engine
from sqlalchemy import event
@event.listens_for(Engine, "before_cursor_execute", retval=True)
def comment_sql_calls(conn, cursor, statement, parameters, context, executemany):
trace_ctx = tracer.get_log_correlation_context()
statement = f"{statement} -- dd.trace_id=<{trace_ctx['trace_id']}>"
return statement, parameters
Nota: Esto sólo correlaciona logs que incluyen una declaración de consulta. Los errores de logs como ERROR: duplicate key value violates unique constraint "<TABLE_KEY>" permanecen fuera de contexto. La mayoría de las veces puedes obtener información sobre errores a través de tus logs de aplicación.
Clona y personaliza el pipeline PostgreSQL:
Añade un nuevo analizador grok:
extract_trace %{data}\s+--\s+dd.trace_id=<%{notSpace:dd.trace_id}>\s+%{data}
Añade un reasignador de ID de rastreo en el atributo dd.trace_id.
El siguiente es un ejemplo de plan de ejecución de una consulta lenta a partir de una traza lenta:
Correlacionar productos frontend
Correlacionar logs de navegador con RUM y Session Replay
¿Por qué?
Los logs de navegador de un evento RUM proporcionan contexto e información sobre un problema. En el siguiente ejemplo, los logs de navegador indican que la causa principal de la consulta errónea es un ID de usuario no válido.
Correlacionar tus logs de navegador con RUM también facilita la aplicación de una agresiva estrategia de muestreo sin pérdida de coherencia a nivel de la entidad mediante el uso de atributos como session_id y view.id.
¿Cómo?
Los logs de navegador y los eventos RUM se correlacionan automáticamente. Para obtener más información, consulta Facturación de RUM y Session Replay. Debes hacer coincidir las configuraciones entre los SDK de navegador RUM y los SDK de logs.
Correlacionar la experiencia del usuario con el comportamiento del servidor
Las monitorizaciones backend y frontend tradicionales están aisladas y pueden requerir flujos de trabajo separados para solucionar problemas en toda la pila. Las correlaciones de pila completa de Datadog te permiten identificar la causa raíz, ya sea que provenga de un problema con el navegador o de un tiempo de inactividad en una base de datos, y calcular su impacto en el usuario.
En esta sección se explica cómo habilitar estas correlaciones:
Correlacionar vistas de RUM con trazas
¿Por qué?
La integración de APM con RUM y Session Replay te permite ver datos frontend y backend en una sola lente, además de:
- Localizar rápidamente los problemas en cualquier punto de la pila, incluido el frontend.
- Comprender plenamente lo que experimentan tus usuarios
¿Cómo?
Puedes acceder a las vistas de RUM en el Explorador de trazas y a las trazas de APM en el Explorador RUM. Para obtener más información, consulta Conectar RUM y trazas.
No existe una correlación directa entre las vistas de RUM y los logs del servidor. Para ver eventos RUM en un log y logs en un evento RUM, haz clic en la pestaña Traces (Trazas).
Aprovechar la correlación de trazas para solucionar problemas en tests Synthetic
¿Por qué?
La integración de APM con la monitorización Synthetic te permite navegar desde la ejecución fallida de un test hasta la causa raíz del problema a través de la traza generada por el test.
Obtener datos específicos relacionados con la red a partir de tu test, además de información de backend, de infraestructura, de logs a partir de tu traza y de eventos RUM (sólo para tests de navegador) te permite acceder a detalles adicionales sobre el comportamiento de tu aplicación y la experiencia del usuario.
¿Cómo?
Después de habilitar APM en el endpoint de tu aplicación, puedes acceder a las trazas de APM en la página de monitorización Synthetic y ejecución permanente de tests.
Para obtener más información, consulta Conectar tests Synthetic y trazas.
Leer más
Más enlaces, artículos y documentación útiles:
