Soluciona problemas de errores de seguimiento distribuido

En este documento, se describe cómo diagnosticar y resolver problemas relacionados con el registro de seguimiento distribuido cuando se usan Cloud Trace y políticas de telemetría con Secure Web Proxy.

Los rastros no aparecen en Trace

Si los intervalos de seguimiento generados por el Secure Web Proxy no aparecen en el Explorador de registros, verifica los siguientes elementos:

  1. Verifica que la API de Cloud Trace esté habilitada: Asegúrate de que la API de Trace (cloudtrace.googleapis.com) esté habilitada en elGoogle Cloud proyecto que aloja tu puerta de enlace de Secure Web Proxy.

    <pre class="devsite-click-to-copy">
gcloud services enable cloudtrace.googleapis.com
</pre>

  2. Verifica que la política de telemetría exista y esté activa: Usa el comando gcloud beta network-services telemetry-policies describe para verificar que tu política de telemetría exista en la región correcta y haga referencia a la puerta de enlace de Secure Web Proxy adecuada:

    gcloud beta network-services telemetry-policies describe POLICY_NAME \
    --location=REGION

    Reemplaza lo siguiente:

    • POLICY_NAME: Nombre de tu política de telemetría, como my-swp-tracing-policy
    • REGION: Es la región en la que se implementa tu política de telemetría, como us-central1.

  3. Verifica la frecuencia de muestreo: Si el valor de samplingRate de tu política es bajo (por ejemplo, 0.01 para el 1% o 0.001 para el 0.1%), es posible que no se muestreen las solicitudes de pruebas manuales individuales. Para confirmar que el registro funciona, actualiza temporalmente tu política para que use un muestreo del 100% (samplingRate: 1.00) y, luego, restablece tu tasa de producción.

  4. Valida el URI del recurso de puerta de enlace de destino: Verifica que el campo telemetryTarget.resources en la política de telemetría especifique la URL del recurso exacta y completamente calificada, o el nombre abreviado de la puerta de enlace de Secure Web Proxy.

    //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/GATEWAY_NAME

    Reemplaza lo siguiente:

    • PROJECT_ID: ID de tu proyecto de Google Cloud
    • REGION: Región en la que se implementa tu puerta de enlace de Secure Web Proxy, como us-central1
    • GATEWAY_NAME: Es el nombre de la instancia de la puerta de enlace de Secure Web Proxy.

    Cualquier discrepancia en el ID del proyecto, la región o el nombre de la puerta de enlace impide que el proxy reciba la configuración de la política.

  5. Verifica los permisos de Identity and Access Management (IAM):

    • Asegúrate de haber otorgado a tu cuenta de usuario o cuenta de servicio el rol de Usuario de Cloud Trace (roles/cloudtrace.user) para ver los tramos en la consola de Google Cloud .
    • Asegúrate de haber otorgado el rol de agente de Cloud Trace (roles/cloudtrace.agent) a las siguientes cuentas de servicio:
      • service-PROJECT_NUMBER@compute-system.
      • service-PROJECT_NUMBER@gcp-sa-networksecurity.
      • Cuentas de servicio de máquina virtual (VM) cliente, si las aplicaciones cliente generan o propagan intervalos

Faltan intervalos secundarios o no funcionan los gráficos de seguimiento

Si los tramos del proxy de Secure Web Proxy aparecen como registros raíz independientes o desconectados en lugar de tramos secundarios de las solicitudes de tu aplicación, haz lo siguiente:

  1. Habilita el muestreo basado en la matriz: En el archivo YAML de la política de telemetría, verifica que parentBasedSampling.enabled esté configurado como true.

    tracingConfiguration:
  samplingRate: 0.01
  parentBasedSampling:
    enabled: true

    Cuando el muestreo basado en la relación principal-secundario está inhabilitado, es posible que Secure Web Proxy descarte los seguimientos que se muestrearon de forma upstream si no coinciden con el samplingRate local.

  2. Verifica la instrumentación de OpenTelemetry: Comprueba que tu aplicación use un SDK de OpenTelemetry que tenga habilitada la propagación del contexto de seguimiento distribuido. Para obtener más información, consulta la documentación del propagador TraceContext de OpenTelemetry.

Volumen de transferencia de registros inesperadamente alto

Si observas un volumen o costos de transferencia de registros más altos de lo esperado en Trace, haz lo siguiente:

  1. Reduce la tasa de muestreo de referencia: En los entornos de producción con mucho tráfico, establece samplingRate en una fracción más pequeña, como 0.01 (1%) o 0.001 (0.1%).
  2. Confía en el muestreo basado en la página principal: Mantén el modelo de referencia de la puerta de enlace samplingRatebajo y habilita parentBasedSampling. Esta combinación ayuda a garantizar que el proxy solo muestree las solicitudes que las aplicaciones ascendentes seleccionan específicamente.
  3. Quita las políticas de depuración temporales: Si aplicaste un muestreo del 100% (samplingRate: 1.00) durante la solución de problemas, quita la política o revierte a tu configuración anterior después de que se complete el proceso de depuración.

¿Qué sigue?