En este tutorial se explica cómo solucionar los errores de tiempo de ejecución que se producen al usar Eventarc para enrutar eventos de Cloud Storage a un servicio de Cloud Run sin autenticar mediante registros de auditoría de Cloud.
Crear un repositorio estándar de Artifact Registry
Crea un repositorio estándar de Artifact Registry para almacenar tu imagen de contenedor:
gcloud artifacts repositories create REPOSITORY \ --repository-format=docker \ --location=$REGION
Sustituye REPOSITORY
por un nombre único para el repositorio.
Crea un segmento de Cloud Storage
Crea un segmento de Cloud Storage en cada una de las dos regiones como origen de eventos del servicio de Cloud Run:
Crea un segmento en
us-east1
:export BUCKET1="troubleshoot-bucket1-PROJECT_ID" gcloud storage buckets create gs://${BUCKET1} --location=us-east1
Crea un segmento en
us-west1
:export BUCKET2="troubleshoot-bucket2-PROJECT_ID" gcloud storage buckets create gs://${BUCKET2} --location=us-west1
Una vez que se haya creado el origen del evento, despliega el servicio de receptor de eventos en Cloud Run.
Implementar el receptor de eventos
Despliega un servicio de Cloud Run que recibe y registra eventos.
Para obtener el código de muestra, clona el repositorio de GitHub:
Go
git clone https://github.com/GoogleCloudPlatform/golang-samples.git cd golang-samples/eventarc/audit_storage
Java
git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git cd java-docs-samples/eventarc/audit-storage
.NET
git clone https://github.com/GoogleCloudPlatform/dotnet-docs-samples.git cd dotnet-docs-samples/eventarc/audit-storage
Node.js
git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git cd nodejs-docs-samples/eventarc/audit-storage
Python
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git cd python-docs-samples/eventarc/audit-storage
Revisa el código de este tutorial, que consta de lo siguiente:
Un controlador de eventos que recibe el evento entrante como un CloudEvent en la solicitud HTTP
POST
:Go
Java
.NET
Node.js
Python
Un servidor que usa el controlador de eventos:
Go
Java
.NET
Node.js
Python
Un archivo Dockerfile que define el entorno operativo del servicio. El contenido del Dockerfile varía según el idioma:
Go
Java
.NET
Node.js
Python
Crea tu imagen de contenedor con Cloud Build y súbela a Artifact Registry:
export PROJECT_ID=$(gcloud config get-value project) export SERVICE_NAME=troubleshoot-service gcloud builds submit --tag $REGION-docker.pkg.dev/${PROJECT_ID}/REPOSITORY/${SERVICE_NAME}:v1
Despliega la imagen de contenedor en Cloud Run:
gcloud run deploy ${SERVICE_NAME} \ --image $REGION-docker.pkg.dev/${PROJECT_ID}/REPOSITORY/${SERVICE_NAME}:v1 \ --allow-unauthenticated
Si la implementación se realiza correctamente, la línea de comandos muestra la URL del servicio.
Crear activador
Después de implementar un servicio de Cloud Run, configura un activador para que detecte eventos de Cloud Storage a través de los registros de auditoría.
Crea un activador de Eventarc para detectar eventos de Cloud Storage que se enrutan mediante Registros de auditoría de Cloud:
gcloud eventarc triggers create troubleshoot-trigger \ --destination-run-service=troubleshoot-service \ --event-filters="type=google.cloud.audit.log.v1.written" \ --event-filters="serviceName=storage.googleapis.com" \ --event-filters="methodName=storage.objects.create" \ --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com
De esta forma, se crea un activador llamado
troubleshoot-trigger
.Para confirmar que se ha creado
troubleshoot-trigger
, ejecuta el siguiente comando:gcloud eventarc triggers list
La salida debería ser similar a la siguiente:
NAME: troubleshoot-trigger TYPE: google.cloud.audit.log.v1.written DESTINATION: Cloud Run service: troubleshoot-service ACTIVE: By 20:03:37 LOCATION: us-central1
Generar y ver un evento
Confirma que has desplegado el servicio correctamente y que puedes recibir eventos de Cloud Storage.
Crea y sube un archivo al
BUCKET1
segmento de almacenamiento:echo "Hello World" > random.txt gcloud storage cp random.txt gs://${BUCKET1}/random.txt
Monitoriza los registros para comprobar si el servicio ha recibido un evento. Para ver la entrada del registro, sigue estos pasos:
Filtra las entradas de registro y devuelve el resultado en formato JSON:
gcloud logging read "resource.labels.service_name=troubleshoot-service \ AND textPayload:random.txt" \ --format=json
Busca una entrada de registro similar a la siguiente:
"textPayload": "Detected change in Cloud Storage bucket: ..."
Ten en cuenta que, al principio, no se devuelve ninguna entrada de registro. Esto indica que hay un problema en la configuración que debes investigar.
Investigar el problema
Sigue el proceso para investigar por qué el servicio no recibe eventos.
Tiempo de inicialización
Aunque el activador se crea inmediatamente, puede tardar hasta dos minutos en propagarse y filtrar eventos. Ejecuta el siguiente comando para confirmar que un activador está activo:
gcloud eventarc triggers list
El resultado indica el estado del activador. En el siguiente ejemplo, troubleshoot-trigger
se activará a las 14:16:56:
NAME TYPE DESTINATION_RUN_SERVICE ACTIVE
troubleshoot-trigger google.cloud.audit.log.v1.written troubleshoot-service By 14:16:56
Una vez que el activador esté activo, vuelve a subir un archivo al bucket de almacenamiento. Los eventos se escriben en los registros de servicio de Cloud Run. Si el servicio no recibe eventos, puede que se deba al tamaño de los eventos.
Registros de auditoría
En este tutorial, los eventos de Cloud Storage se enrutan mediante registros de auditoría de Cloud y se envían a Cloud Run. Confirma que los registros de auditoría estén habilitados en Cloud Storage.
En la Google Cloud consola, ve a la página Registros de auditoría.
- Seleccione la casilla Google Cloud Storage.
- Asegúrate de que estén seleccionados los tipos de registro Actividad de administración, Lectura de datos y Escritura de datos.
Una vez que hayas habilitado los registros de auditoría de Cloud, vuelve a subir el archivo al segmento de almacenamiento y consulta los registros. Si el servicio sigue sin recibir eventos, puede que se deba a la ubicación del activador.
Ubicación de activación
Puede haber varios recursos en diferentes ubicaciones y debe filtrar los eventos de las fuentes que se encuentren en la misma región que el destino de Cloud Run. Para obtener más información, consulta las ubicaciones compatibles con Eventarc y el artículo ¿Qué son las ubicaciones de Eventarc?
En este tutorial, has desplegado el servicio de Cloud Run en us-central1
. Como has definido eventarc/location
en us-central1
, también has creado un activador en la misma ubicación.
Sin embargo, has creado dos segmentos de Cloud Storage en las ubicaciones us-east1
y us-west1
. Para recibir eventos de esas ubicaciones, debe crear activadores de Eventarc en ellas.
Crea un activador de Eventarc ubicado en us-east1
:
Confirma la ubicación del activador:
gcloud eventarc triggers describe troubleshoot-trigger
Define la ubicación y la región en
us-east1
:gcloud config set eventarc/location us-east1 gcloud config set run/region us-east1
Vuelve a desplegar el receptor de eventos creando y desplegando la imagen de contenedor en Cloud Run.
Crea un activador en
us-east1
:gcloud eventarc triggers create troubleshoot-trigger-new \ --destination-run-service=troubleshoot-service \ --event-filters="type=google.cloud.audit.log.v1.written" \ --event-filters="serviceName=storage.googleapis.com" \ --event-filters="methodName=storage.objects.create" \ --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com
Comprueba que se haya creado el activador:
gcloud eventarc triggers list
Un activador puede tardar hasta dos minutos en inicializarse antes de empezar a enrutar eventos.
Para confirmar que el activador se ha implementado correctamente, genera y consulta un evento.
Otros problemas que pueden surgir
Puede que tengas otros problemas al usar Eventarc.
Tamaño del evento
Los eventos que envíe no deben superar los límites de tamaño de evento.
Un activador que antes enviaba eventos ha dejado de funcionar
Verifica que la fuente esté generando eventos. Consulta los registros de auditoría de Cloud y comprueba que el servicio monitorizado emite registros. Si se registran los registros, pero no se envían los eventos, ponte en contacto con el equipo de Asistencia.
Verifica que exista un tema de Pub/Sub con el mismo nombre de activador. Eventarc usa Pub/Sub como capa de transporte y utilizará un tema de Pub/Sub que ya exista o creará uno automáticamente y lo gestionará por ti.
- Para ver una lista de los activadores, consulta
gcloud eventarc triggers list
. Para enumerar los temas de Pub/Sub, ejecuta el siguiente comando:
gcloud pubsub topics list
Comprueba que el nombre del tema de Pub/Sub incluya el nombre del activador creado. Por ejemplo:
name: projects/PROJECT_ID/topics/eventarc-us-east1-troubleshoot-trigger-new-123
Si falta el tema de Pub/Sub, vuelve a crear el activador para un proveedor, un tipo de evento y un destino de Cloud Run específicos.
- Para ver una lista de los activadores, consulta
Comprueba que el activador se haya configurado para el servicio.
En la Google Cloud consola, ve a la página Servicios.
Haz clic en el nombre del servicio para abrir su página Detalles del servicio.
Haz clic en la pestaña Activadores.
Debería aparecer el activador de Eventarc asociado al servicio.
Verifica el estado del tema y la suscripción de Pub/Sub mediante los tipos de métricas de Pub/Sub.
Puedes monitorizar los mensajes no entregados reenviados con la métrica
subscription/dead_letter_message_count
. Esta métrica muestra el número de mensajes que no se pueden entregar y que Pub/Sub reenvía desde una suscripción.Si no se publican mensajes en el tema, consulta Cloud Audit Logs y asegúrate de que el servicio monitorizado emite registros. Si se registran los registros, pero no se envían los eventos, ponte en contacto con el equipo de Asistencia.
Puede monitorizar las suscripciones push con la métrica
subscription/push_request_count
y agrupando la métrica porresponse_code
ysubcription_id
.Si se notifican errores de envío, consulta los registros del servicio Cloud Run. Si el endpoint receptor devuelve un código de estado distinto de OK, significa que el código de Cloud Run no funciona como se esperaba y debes ponerte en contacto con el equipo de Asistencia.
Para obtener más información, consulta Crear políticas de alertas de umbral de métricas.