Me he sumergido en una integración de Stackdriver Trace en Google Cloud Run. Puedo hacer que funcione con el agente, pero me molestan algunas preguntas.
Dado que
- El agente Stackdriver agrega trazas en un pequeño búfer y las envía periódicamente.
- El acceso a la CPU está restringido cuando un servicio Cloud Run no maneja una solicitud.
- No hay gancho de apagado para los servicios de Cloud Run; no puede borrar el búfer antes del apagado: el contenedor solo recibe un SIGKILL . Esta es una señal que no puede captar de su aplicación.
- La ejecución de un proceso en segundo plano que envía información fuera del ciclo de solicitud-respuesta parece violar el contrato de Knative Container Runtime
- Las colecciones de datos de registro están documentadas y no requieren que ejecute un agente, pero no existe tal solución para la telemetría.
- Encontré un informe de alguien experimentando rastros perdidos en Cloud Run usando el enfoque basado en agentes
Cómo lo hace Google
Entré en el código fuente de Cloud Endpoints ESP (la integración de Cloud Run está en beta) para ver si lo resuelven de una manera diferente, pero se usa el mismo patrón: hay un búfer con trazas (1s) y Se borra periódicamente.
Pregunta
Si bien mi integración de rastreo parece funcionar en mi configuración de prueba, me preocupan los rastreos incompletos y faltantes cuando ejecuto esto en un entorno de producción.
¿Es este un problema hipotético o un problema real?
Parece que la forma correcta de abordar esto es escribir telemetría en los registros, en lugar de utilizar un proceso de agente. ¿Es eso compatible con Stackdriver Trace?
fuente
Respuestas:
Tienes razón. Esta es una preocupación justa ya que la mayoría de las bibliotecas de rastreo tienden a muestrear / cargar tramos de rastreo en segundo plano.
Dado que (1) su CPU está casi escalada casi a cero cuando el contenedor no está manejando ninguna solicitud y (2) la instancia del contenedor puede ser eliminada en cualquier momento debido a la inactividad, no puede cargar de manera confiable esos intervalos de rastreo recopilados en su aplicación. Como dijiste, a veces puede funcionar ya que no detenemos completamente la CPU, pero no siempre funcionará.
Parece que algunas de las bibliotecas Stackdriver (y / o OpenTelemetry fka OpenCensus) le permiten controlar el ciclo de vida de empujar trazos de traza.
Por ejemplo, este paquete Go para el exportador de OpenCensus Stackdriver tiene un
Flush()
método al que puede llamar antes de completar su solicitud en lugar de confiar en el tiempo de ejecución para cargar periódicamente los trazos de seguimiento: https://godoc.org/contrib.go.opencensus.io/ exporter / stackdriver # Exporter.FlushSupongo que otras bibliotecas de rastreo en otros idiomas también exponen métodos Flush () similares, de lo contrario, hágamelo saber en los comentarios y esta sería una solicitud de función válida para esas bibliotecas.
fuente
Si considera que un servicio de Cloud Run recibe una sola solicitud, definitivamente es un problema, ya que la biblioteca no tendrá tiempo para vaciar los datos antes de que la CPU de la instancia del contenedor se acelere.
Sin embargo, en casos de uso de la vida real:
Tenga en cuenta que las bibliotecas de rastreo suelen muestrear las solicitudes de rastreo, raramente rastrean el 100% de las solicitudes.
No, Stackdriver Trace toma sus datos de los tramos enviados a su API. Tenga en cuenta que para enviar datos a Stackdriver Trace, puede usar bibliotecas como OpenCenss y OpenTelemetry, las bibliotecas propietarias de Stackdriver Trace no son la forma recomendada de ninguna manera.
fuente