Implementa la transmisión de registros de Google Cloud a Splunk

Last reviewed 2023-11-16 UTC

En este documento, se describe cómo implementar un mecanismo de exportación para transmitir registros de los recursos de Google Cloud a Splunk. Se da por sentado que ya leíste la arquitectura de referencia para este caso de uso.

Estas instrucciones están destinadas a los administradores de operaciones y seguridad que desean transmitir registros de Google Cloud a Splunk. Debes estar familiarizado con Splunk y el recopilador de eventos HTTP (HEC) de Splunk cuando uses estas instrucciones para operaciones de TI o casos de uso de seguridad. Aunque no es obligatorio, es útil estar familiarizado con las canalizaciones de Dataflow, Pub/Sub, Cloud Logging, Identity and Access Management y Cloud Storage para esta implementación.

Para automatizar los pasos de implementación en esta arquitectura de referencia mediante el uso de la infraestructura como código (IaC), consulta el repositorio de GitHub terraform-splunk-log-export.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de referencia y se demuestra cómo fluyen los datos de registro de Google Cloud a Splunk.

Como se muestra en el diagrama, Cloud Logging recopila los registros en un receptor de registros a nivel de la organización y los envía a Pub/Sub. El servicio de Pub/Sub crea un solo tema y suscripción para los registros y reenvía los registros a la canalización principal de Dataflow. La canalización principal de Dataflow es una canalización de transmisión de Pub/Sub a Splunk que extrae registros de la suscripción a Pub/Sub y los entrega a Splunk. En paralelo a la canalización principal de Dataflow, la canalización secundaria de Dataflow es una canalización de transmisión de Pub/Sub a Pub/Sub para volver a reproducir mensajes si falla una entrega. Al final del proceso, Splunk Enterprise o Splunk Cloud Platform actúan como un extremo de HEC y reciben los registros para un análisis más detallado. Para obtener más información, consulta la sección Arquitectura de la arquitectura de referencia.

Para implementar esta arquitectura de referencia, realiza las siguientes tareas:

• Realiza tareas de configuración.
• Crear un receptor de registros agregado en un proyecto dedicado.
• Crea un tema de mensajes no entregados.
• Configura un extremo de HEC de Splunk.
• Configura la capacidad de canalización de Dataflow.
• Exporta registros a Splunk.
• Transforma registros o eventos en tránsito con funciones definidas por el usuario (UDF) dentro de la canalización de Splunk Dataflow.
• Manejar fallas de entrega para evitar la pérdida de datos debido a posibles problemas de red temporales o configuraciones incorrectas.

Antes de comenzar

Completa los siguientes pasos para configurar un entorno para tu arquitectura de referencia de Google Cloud a Splunk:

• Abre un proyecto, habilita la facturación y activa las APIs.
• Asigna roles de IAM.
• Configurar el entorno
• Configura herramientas de redes seguras.

Abre un proyecto, habilita la facturación y activa las APIs

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Make sure that billing is enabled for your Google Cloud project.

3. Enable the Cloud Monitoring API, Secret Manager, Compute Engine, Pub/Sub, and Dataflow APIs.

   Enable the APIs

Asigna roles de IAM

En la consola de Google Cloud, asegúrate de tener los siguientes permisos de Identity and Access Management (IAM) para la organización y los recursos del proyecto. Para obtener más información, consulta Otorga, cambia y revoca el acceso a los recursos.

Permisos	Funciones predefinidas	Recurso
logging.sinks.create logging.sinks.get logging.sinks.update	Escritor de configuración de registros (roles/logging.configWriter)	Organización
compute.networks.* compute.routers.* compute.firewalls.* networkservices.*	Administrador de red de Compute (roles/compute.networkAdmin) Administrador de seguridad de Compute (roles/compute.securityAdmin)	Proyecto
secretmanager.*	Administrador de Secret Manager (roles/secretmanager.admin)	Proyecto

Si los roles predefinidos de IAM no incluyen suficientes permisos para realizar tus tareas, crea un rol personalizado. Un rol personalizado te dará el acceso que necesitas y te permitirá seguir el principio de menor privilegio.

Nota: Para crear el receptor de registros agregado a nivel de la organización, debes tener asignado el rol de Escritor de configuración de registros en la jerarquía de la organización. Si no tienes acceso para cambiar los permisos a nivel de la organización, solicita al administrador de la organización de Google Cloud que cree el receptor de registros en toda la organización. Para obtener más información sobre el control de acceso de Cloud Logging, consulta Roles predefinidos de Cloud Logging.

Configure su entorno

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Configura el proyecto para tu sesión activa de Cloud Shell:

   gcloud config set project PROJECT_ID
   

   Reemplaza PROJECT_ID con el ID del proyecto.

Configura herramientas de redes seguras

En este paso, configurarás herramientas de redes seguras antes de procesar y exportar registros a Splunk Enterprise.

1. Crea una red de VPC y una subred:

   gcloud compute networks create NETWORK_NAME --subnet-mode=custom
   gcloud compute networks subnets create SUBNET_NAME \
   --network=NETWORK_NAME \
   --region=REGION \
   --range=192.168.1.0/24
   

   Reemplaza lo siguiente:

   • NETWORK_NAME: El nombre de tu red.
   • SUBNET_NAME: El nombre de tu subred
   • REGION: La región que deseas usar para esta red.

2. Crea una regla de firewall para que las máquinas virtuales (VMs) de trabajador de Dataflow se comuniquen entre sí:

   gcloud compute firewall-rules create allow-internal-dataflow \
   --network=NETWORK_NAME \
   --action=allow \
   --direction=ingress \
   --target-tags=dataflow \
   --source-tags=dataflow \
   --priority=0 \
   --rules=tcp:12345-12346
   

   Esta regla permite el tráfico interno entre las VMs de Dataflow que usan los puertos TCP 12345-12346. Además, el servicio de Dataflow establece la etiqueta dataflow.

3. Crea una puerta de enlace de Cloud NAT:

   gcloud compute routers create nat-router \
   --network=NETWORK_NAME \
   --region=REGION
   
   gcloud compute routers nats create nat-config \
   --router=nat-router \
   --nat-custom-subnet-ip-ranges=SUBNET_NAME \
   --auto-allocate-nat-external-ips \
   --region=REGION
   

4. Habilita el Acceso privado a Google en la subred:

   gcloud compute networks subnets update SUBNET_NAME \
   --enable-private-ip-google-access \
   --region=REGION
   

Crea un receptor de registros

En esta sección, crearás el receptor de registros en toda la organización y su destino de Pub/Sub, junto con los permisos necesarios.

1. En Cloud Shell, crea un tema de Pub/Sub y una suscripción asociada como el destino del receptor de registros nuevo:

   gcloud pubsub topics create INPUT_TOPIC_NAME
   gcloud pubsub subscriptions create \
   --topic INPUT_TOPIC_NAME INPUT_SUBSCRIPTION_NAME
   

   Reemplaza lo siguiente:

   • INPUT_TOPIC_NAME: El nombre del tema de Pub/Sub que se usará como destino del receptor de registros.
   • INPUT_SUBSCRIPTION_NAME: El nombre de la suscripción a Pub/Sub del destino del receptor de registros.

2. Crea el receptor de registros de la organización:

   gcloud logging sinks create ORGANIZATION_SINK_NAME \
   pubsub.googleapis.com/projects/PROJECT_ID/topics/INPUT_TOPIC_NAME \
   --organization=ORGANIZATION_ID \
   --include-children \
   --log-filter='NOT logName:projects/PROJECT_ID/logs/dataflow.googleapis.com'
   

   Reemplaza lo siguiente:

   • ORGANIZATION_SINK_NAME: El nombre de tu organización.
   • ORGANIZATION_ID: El ID de tu organización

   El comando consta de las siguientes marcas:

   • La marca --organization especifica que este es un receptor de registros a nivel de la organización.
   • La marca --include-children es obligatoria y garantiza que el receptor de registros a nivel de la organización incluya todos los registros en todas las subcarpetas y proyectos.
   • La marca --log-filter especifica los registros que se deben enrutar. En este ejemplo, excluyes los registros de operaciones de Dataflow específicamente para el proyecto PROJECT_ID, ya que la canalización de exportación de registros de Dataflow genera más registros a medida que procesa los registros. El filtro evita que la canalización exporte sus propios registros, lo que evita un ciclo exponencial potencial. El resultado incluye una cuenta de servicio en el formato o#####-####@gcp-sa-logging.iam.gserviceaccount.com.

3. Otorga el rol de IAM de publicador de Pub/Sub a la cuenta de servicio del receptor de registros en el tema de Pub/Sub INPUT_TOPIC_NAME. Este rol permite que la cuenta de servicio del receptor de registros publique mensajes en el tema.

   gcloud pubsub topics add-iam-policy-binding INPUT_TOPIC_NAME \
   --member=serviceAccount:LOG_SINK_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/pubsub.publisher
   

   Reemplaza LOG_SINK_SERVICE_ACCOUNT por el nombre de la cuenta de servicio de tu receptor de registros.

Crea un tema de mensajes no entregados

Para evitar una posible pérdida de datos que ocurre cuando un mensaje no se puede entregar, debes crear un tema de mensajes no entregados de Pub/Sub y la suscripción correspondiente. El mensaje con errores se almacena en el tema de mensajes no entregados hasta que un operador o ingeniero de confiabilidad de sitios pueda investigar y corregir la falla. Para obtener más información, consulta la sección Vuelve a reproducir mensajes con errores de la arquitectura de referencia.

• En Cloud Shell, crea un tema y una suscripción de mensajes no entregados de Pub/Sub para evitar la pérdida de datos mediante el almacenamiento de cualquier mensaje no entregado:

  gcloud pubsub topics create DEAD_LETTER_TOPIC_NAME
  gcloud pubsub subscriptions create --topic DEAD_LETTER_TOPIC_NAME DEAD_LETTER_SUBSCRIPTION_NAME
  

  Reemplaza lo siguiente:

  • DEAD_LETTER_TOPIC_NAME: El nombre del tema de Pub/Sub que será el tema de los mensajes no entregados
  • DEAD_LETTER_SUBSCRIPTION_NAME: El nombre de la suscripción a Pub/Sub para el tema de mensajes no entregados.

Configura un extremo de HEC de Splunk

En los siguientes procedimientos, configurarás un extremo de HEC de Splunk y almacenarás el token de HEC recién creado como un secreto en Secret Manager. Cuando implementas la canalización de Splunk Dataflow, debes proporcionar la URL del extremo y el token.

Configura el HEC de Splunk

1. Si todavía no tienes un extremo de HEC de Splunk, consulta la documentación de Splunk para obtener información sobre cómo configurar el HEC de Splunk. El HEC de Splunk se ejecuta en el servicio de Splunk Cloud Platform Splunk o en tu propia instancia de Splunk Enterprise.
2. En Splunk, después de crear un token de HEC de Splunk, copia el valor del token.
3. En Cloud Shell, guarda el valor del token del HEC de Splunk en un archivo temporal llamado splunk-hec-token-plaintext.txt.

Nota: Para obtener alta disponibilidad y aprender a escalar con el tráfico de alto volumen, consulta los documentos de Splunk en cómo escalar el HEC mediante la distribución de la carga a varios nodos con un balanceador de cargas HTTP(S).

Almacena el token HEC de Splunk en Secret Manager

En este paso, crearás un secreto y una sola versión de secreto subyacente en la que se almacenará el valor del token del HEC de Splunk.

Nota: Secret Manager es compatible a partir de la versión de laplantilla de Dataflow de Pub/Sub a Splunk2022- 03-14-00_RC00. Esta arquitectura de referencia usa la última versión de esta plantilla.

1. En Cloud Shell, crea un secreto para que contenga tu token del HEC de Splunk:

   gcloud secrets create hec-token \
    --replication-policy="automatic"
   

   Para obtener más información sobre las políticas de replicación de los secretos, consulta Elige una política de replicación.

2. Agrega el token como una versión del secreto con el contenido del archivo splunk-hec-token-plaintext.txt:

   gcloud secrets versions add hec-token \
    --data-file="./splunk-hec-token-plaintext.txt"
   

3. Borra el archivo splunk-hec-token-plaintext.txt, ya que ya no es necesario.

Configura la capacidad de canalización de Dataflow

Nota: Antes de continuar, asegúrate de tener suficiente cuota de CPU e IP en la región elegida para aprovisionar la cantidad máxima posible de VMs de Dataflow (configurada con la --max-workers). Para obtener más información sobre cómo verificar y solicitar un aumento de cuotas, consulta Cuotas de asignación.

En la siguiente tabla, se resumen las prácticas recomendadas generales para configurar la capacidad de canalización de Dataflow:

Parámetro de configuración	Prácticas recomendadas generales
Marca --worker-machine-type	Configurarlo como tamaño de máquina de referencia n1-standard-4 para obtener el mejor rendimiento en relación con el costo
Marca --max-workers	Configurarlo como la cantidad máxima de trabajadores necesarios para manejar el EPS estimado previsto según tus cálculos
Parámetro parallelism	Configúralo en 2 × CPUs virtuales/trabajador × la cantidad máxima de trabajadores para maximizar la cantidad de conexiones de HEC paralelas de Splunk
batchCount parámetro	Configurarlo como 10 a 50 eventos o solicitudes para registros, siempre que la demora máxima de almacenamiento en búfer de dos segundos sea aceptable

Recuerda usar tus propios valores y cálculos únicos cuando implementes esta arquitectura de referencia en el entorno.

1. Establece los valores para el tipo y la cantidad de máquinas. Si deseas calcular los valores apropiados para tu entorno de nube, consulta las secciones Tipo de máquina y Recuento de máquinas de la arquitectura de referencia.

   DATAFLOW_MACHINE_TYPE
   DATAFLOW_MACHINE_COUNT
   

2. Establece los valores para el paralelismo de Dataflow y el recuento de lotes. Para calcular los valores apropiados para tu entorno de nube, consulta las secciones Paralelismo y Recuento por lotes de la arquitectura de referencia.

   JOB_PARALLELISM
   JOB_BATCH_COUNT
   

Para obtener más información sobre cómo calcular los parámetros de capacidad de canalización de Dataflow, consulta la sección Consideraciones sobre el diseño de optimización de costos y el rendimiento de la arquitectura de referencia.

Exporta registros mediante la canalización de Dataflow

En esta sección, implementarás la canalización de Dataflow con los siguientes pasos:

• Crea un bucket de Cloud Storage y una cuenta de servicio de trabajador de Dataflow.
• Otorga roles y acceso a la cuenta de servicio de trabajador de Dataflow.
• Implementa la canalización de Dataflow.
• Visualiza registros en Splunk.

La canalización entrega mensajes de registro de Google Cloud al HEC de Splunk.

Crea un bucket de Cloud Storage y una cuenta de servicio de trabajador de Dataflow

1. En Cloud Shell, crea un bucket nuevo de Cloud Storage con una configuración de acceso uniforme a nivel de bucket:

   gsutil mb -b on gs://PROJECT_ID-dataflow/
   

   El bucket de Cloud Storage que acabas de crear es donde el trabajo de Dataflow almacena en etapa intermedia los archivos temporales.

2. En Cloud Shell, crea una cuenta de servicio para los trabajadores de Dataflow:

   gcloud iam service-accounts create WORKER_SERVICE_ACCOUNT \
      --description="Worker service account to run Splunk Dataflow jobs" \
      --display-name="Splunk Dataflow Worker SA"
   

   Reemplaza WORKER_SERVICE_ACCOUNT por el nombre que deseas usar para la cuenta de servicio de trabajador de Dataflow.

Otorga roles y acceso a la cuenta de servicio de trabajador de Dataflow

En esta sección, otorga los roles necesarios a la cuenta de servicio de trabajador de Dataflow como se muestra en la siguiente tabla.

Rol	Ruta de acceso	Objetivo
Administrador de Dataflow	roles/dataflow.worker	Habilita la cuenta de servicio para que actúe como administrador de Dataflow.
Trabajador de Dataflow	roles/dataflow.worker	Habilita la cuenta de servicio para que actúe como un trabajador de Dataflow.
Administrador de objetos de Storage	roles/storage.objectAdmin	Habilita la cuenta de servicio para acceder al bucket de Cloud Storage que usa Dataflow para los archivos de etapa de pruebas.
Publicador de Pub/Sub	roles/pubsub.publisher	Habilita la cuenta de servicio para publicar mensajes con errores en el tema de mensajes no entregados de Pub/Sub.
Suscriptor de Pub/Sub	roles/pubsub.subscriber	Habilita la cuenta de servicio para acceder a la suscripción de entrada.
Visualizador de Pub/Sub	roles/pubsub.viewer	Habilita la cuenta de servicio para ver la suscripción.
Usuario con acceso a secretos de Secret Manager	roles/secretmanager.secretAccessor	Habilita la cuenta de servicio para acceder al secreto que contiene el token de HEC de Splunk.

1. En Cloud Shell, otorga a la cuenta de servicio de trabajador de Dataflow los roles de administrador de Dataflow y trabajador de Dataflow que necesita esta cuenta para ejecutar las operaciones de trabajo de Dataflow y las tareas de administración:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/dataflow.admin"
   

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/dataflow.worker"
   

2. Otorga a la cuenta de servicio del trabajador de Dataflow acceso para ver y consumir mensajes de la suscripción de entrada de Pub/Sub:

   gcloud pubsub subscriptions add-iam-policy-binding INPUT_SUBSCRIPTION_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.subscriber"
   

   gcloud pubsub subscriptions add-iam-policy-binding INPUT_SUBSCRIPTION_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.viewer"
   

3. Otorga a la cuenta de servicio de trabajador de Dataflow acceso para publicar cualquier mensaje con errores en el tema de Pub/Sub sin procesar:

   gcloud pubsub topics add-iam-policy-binding DEAD_LETTER_TOPIC_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.publisher"
   

4. Otorga a la cuenta de servicio de trabajador de Dataflow acceso al secreto de token del HEC de Splunk en Secret Manager:

   gcloud secrets add-iam-policy-binding hec-token \
   --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
   --role="roles/secretmanager.secretAccessor"
   

5. Otorga a la cuenta de servicio de trabajador de Dataflow acceso de lectura y escritura al bucket de Cloud Storage que usará el trabajo de Dataflow para los archivos de etapa de pruebas:

   gcloud storage buckets add-iam-policy-binding gs://PROJECT_ID-dataflow/ \
   --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com"
   --role=”roles/storage.objectAdmin”
   

Implementa la canalización de Dataflow

1. En Cloud Shell, configura la siguiente variable de entorno para la URL de HEC de Splunk:

   export SPLUNK_HEC_URL=SPLUNK_HEC_URL
   

   Reemplaza la variable SPLUNK_HEC_URL con el formato protocol://host[:port], en el que se muestra lo siguiente:

   • protocol es http o https.
   • host es el nombre de dominio completamente calificado (FQDN) o la dirección IP de tu instancia de HEC de Splunk o, si tienes varias instancias de HEC, el balanceador de cargas HTTP(S) asociado (o basado en DNS).
   • port es el número de puerto HEC. Es opcional y depende de la configuración del extremo del HEC de Splunk.

   Un ejemplo de una entrada de URL de HEC válida de Splunk es https://splunk-hec.example.com:8088. Si envías datos a HEC en Splunk Cloud Platform, consulta Enviar datos a HEC en Splunk Cloud para determinar las partes anteriores host y port de tu URL específica de HEC de Splunk.

   Precaución: Si no se hace coincidir el formato de URL de HEC de Splunk descrito en este paso, se producirán errores de validación de entrada de Dataflow y los datos no se entregarán a Splunk Extremo HEC. En su lugar, los registros de transmisión se enviarán al tema no procesado.

   La URL de HEC de Splunk no debe incluir la ruta de acceso del extremo HEC, por ejemplo, /services/collector. Por el momento, la plantilla de Dataflow de Pub/Sub a Splunk solo admite el extremo /services/collector para eventos con formato JSON y agrega de forma automática esa ruta a la entrada de URL de HEC de Splunk. Para obtener más información sobre ese extremo del HEC, consulta la documentación de Splunk para services/collector endpoint.

2. Implementa la canalización de Dataflow con la plantilla de Dataflow de Pub/Sub a Splunk:

   gcloud beta dataflow jobs run JOB_NAME \
   --gcs-location=gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
   --staging-location=gs://PROJECT_ID-dataflow/temp/ \
   --worker-machine-type=DATAFLOW_MACHINE_TYPE \
   --max-workers=DATAFLOW_MACHINE_COUNT \
   --region=REGION \
   --network=NETWORK_NAME \
   --subnetwork=regions/REGION/subnetworks/SUBNET_NAME \
   --disable-public-ips \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/INPUT_SUBSCRIPTION_NAME,\
   outputDeadletterTopic=projects/PROJECT_ID/topics/DEAD_LETTER_TOPIC_NAME,\
   url=SPLUNK_HEC_URL,\
   tokenSource=SECRET_MANAGER, \
   tokenSecretId=projects/PROJECT_ID/secrets/hec-token/versions/1, \
   batchCount=JOB_BATCH_COUNT,\
   parallelism=JOB_PARALLELISM,\
   javascriptTextTransformGcsPath=gs://splk-public/js/dataflow_udf_messages_replay.js,\
   javascriptTextTransformFunctionName=process
   

   Reemplaza JOB_NAME con el formato de nombre pubsub-to-splunk-date+"%Y%m%d-%H%M%S".

   Los parámetros opcionales javascriptTextTransformGcsPath y javascriptTextTransformFunctionName especifican una UDF de muestra disponible de forma pública: gs://splk-public/js/dataflow_udf_messages_replay.js. La UDF de muestra incluye ejemplos de código para la transformación de eventos y la lógica de decodificación que usas para volver a reproducir entregas con errores. Para obtener más información sobre la UDF, consulta Transforma eventos en tránsito con UDF.

3. Una vez que se complete el trabajo de canalización, busca el ID del trabajo nuevo en el resultado, copia el ID del trabajo y guárdalo. Ingresarás este ID de trabajo en un paso posterior.

Visualiza registros en Splunk

Los trabajadores de la canalización de Dataflow tardan unos minutos en aprovisionarse y estar listos para entregar los registros al HEC de Splunk. Puedes confirmar que los registros se reciben y se indexan correctamente en la interfaz de búsqueda de Splunk Enterprise o Splunk Cloud Platform. Para ver la cantidad de registros por tipo de recurso supervisado, sigue estos pasos:

1. En Splunk, abre Informes y búsqueda de Splunk.

2. Ejecuta el index=[MY_INDEX] | stats count by resource.type de búsqueda donde se configura el índice MY_INDEX para tu token del HEC de Splunk:

   

3. Si no ves ningún evento, consulta Controla los errores en la entrega.

Transforma eventos en tránsito con UDF

La plantilla de Dataflow de Pub/Sub a Splunk admite una UDF de JavaScript para la transformación de eventos personalizados, como agregar campos nuevos o configurar metadatos de HEC de Splunk según el evento. La canalización que implementaste usa esta UDF de muestra.

En esta sección, editarás primero la función UDF de muestra para agregar un nuevo campo de evento. En este campo nuevo, se especifica el valor de la suscripción de Pub/Sub de origen como información contextual adicional. Luego, actualiza la canalización de Dataflow con la UDF modificada.

Modifica la UDF de muestra

1. En Cloud Shell, descarga el archivo JavaScript que contiene la función UDF de muestra:

     wget https://storage.googleapis.com/splk-public/js/dataflow_udf_messages_replay.js
     

2. En el editor de texto que elijas, abre el archivo JavaScript, ubica el campo event.inputSubscription, quita los comentarios de esa línea y reemplaza splunk-dataflow-pipeline por INPUT_SUBSCRIPTION_NAME:

   event.inputSubscription = "INPUT_SUBSCRIPTION_NAME";
   

3. Guarda el archivo.

4. Sube el archivo al bucket de Cloud Storage.

   gsutil cp ./dataflow_udf_messages_replay.js gs://PROJECT_ID-dataflow/js/
   

Actualiza la canalización de Dataflow con la UDF nueva

1. En Cloud Shell, detén la canalización con la Opción de desvío para asegurarte de que no se pierdan los registros que ya se extrajeron de Pub/Sub:

   gcloud dataflow jobs drain JOB_ID --region=REGION
   

2. Ejecuta el trabajo de canalización de Dataflow con la UDF actualizada.

   gcloud beta dataflow jobs run JOB_NAME \
   --gcs-location=gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
   --worker-machine-type=DATAFLOW_MACHINE_TYPE \
   --max-workers=DATAFLOW_MACHINE_COUNT \
   --region=REGION \
   --network=NETWORK_NAME \
   --subnetwork=regions/REGION/subnetworks/SUBNET_NAME \
   --disable-public-ips \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/INPUT_SUBSCRIPTION_NAME,\
   outputDeadletterTopic=projects/PROJECT_ID/topics/DEAD_LETTER_TOPIC_NAME,\
   url=SPLUNK_HEC_URL,\
   tokenSource=SECRET_MANAGER, \
   tokenSecretId=projects/PROJECT_ID/secrets/hec-token/versions/1, \
   batchCount=JOB_BATCH_COUNT,\
   parallelism=JOB_PARALLELISM,\
   javascriptTextTransformGcsPath=gs://PROJECT_ID-dataflow/js/dataflow_udf_messages_replay.js,\
   javascriptTextTransformFunctionName=process
   

   Reemplaza JOB_NAME con el formato de nombre pubsub-to-splunk-date+"%Y%m%d-%H%M%S".

Controla los errores en la entrega

Los errores en la entrega pueden ocurrir debido a errores en el procesamiento de eventos o la conexión con el HEC de Splunk. En esta sección, ingresarás una falla de entrega para demostrar el flujo de trabajo de manejo de errores. También aprenderás a ver y activar la entrega de los mensajes con errores a Splunk.

Activa errores en la entrega

Para ingresar una falla de entrega de forma manual en Splunk, realiza una de las siguientes acciones:

• Si ejecutas una sola instancia, detén el servidor de Splunk para causar errores de conexión.
• Inhabilita el token de HEC correspondiente de tu configuración de entrada de Splunk.

Solución de problemas de los mensajes con errores

Para investigar un mensaje con errores, puedes usar la consola de Google Cloud:

1. En la consola de Google Cloud, ve a la página Suscripciones de Pub/Sub.

   Ir a Suscripciones de Pub/Sub

2. Haz clic en la suscripción no procesada que creaste. Si usaste el ejemplo anterior, el nombre de la suscripción es: projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME.

3. Para abrir el visualizador de mensajes, haz clic en Ver mensajes.

4. Para ver los mensajes, haz clic en Extraer y asegúrate de dejar en blanco la opción Habilitar mensajes de confirmación.

5. Inspecciona los mensajes con errores. Presta atención a lo siguiente:

   • La carga útil del evento de Splunk en la columna Message body.
   • El mensaje de error en la columna attribute.errorMessage.
   • La marca de tiempo del error en la columna attribute.timestamp.

En la siguiente captura de pantalla, se muestra un ejemplo de un mensaje de error que recibes si el extremo del HEC de Splunk está fuera de servicio temporalmente o no se puede acceder a él. Ten en cuenta que el texto del atributo errorMessage lee The target server failed to respond. El mensaje también muestra la marca de tiempo asociada con cada falla. Puedes usar esta marca de tiempo para solucionar la causa raíz de la falla.

Vuelve a reproducir mensajes con errores

En esta sección, debes reiniciar el servidor de Splunk o habilitar el extremo del HEC de Splunk para corregir el error de entrega. Luego, puedes volver a reproducir los mensajes no procesados.

1. En Splunk, usa uno de los siguientes métodos para restablecer la conexión a Google Cloud:

   • Si detuviste el servidor de Splunk, reinicia el servidor.
   • Si inhabilitaste el extremo del HEC de Splunk en la sección Activa errores en la entrega, verifica que el extremo del HEC de Splunk ahora funcione.

2. En Cloud Shell, toma una instantánea de la suscripción no procesada antes de volver a procesar los mensajes de esta suscripción. La instantánea evita la pérdida de mensajes si hay un error de configuración inesperado.

   gcloud pubsub snapshots create SNAPSHOT_NAME \
   --subscription=DEAD_LETTER_SUBSCRIPTION_NAME
   

   Reemplaza SNAPSHOT_NAME por un nombre que te ayude a identificar la instantánea, como dead-letter-snapshot-date+"%Y%m%d-%H%M%S.

3. Usa la plantilla de Pub/Sub a Splunk Dataflow para crear una canalización de Pub/Sub a Pub/Sub. La canalización usa otro trabajo de Dataflow para transferir los mensajes de la suscripción no procesada al tema de entrada.

   DATAFLOW_INPUT_TOPIC="INPUT_TOPIC_NAME"
   DATAFLOW_DEADLETTER_SUB="DEAD_LETTER_SUBSCRIPTION_NAME"
   JOB_NAME=splunk-dataflow-replay-date +"%Y%m%d-%H%M%S"
   gcloud dataflow jobs run JOB_NAME \
   --gcs-location= gs://dataflow-templates/latest/Cloud_PubSub_to_Cloud_PubSub \
   --worker-machine-type=n1-standard-2 \
   --max-workers=1 \
   --region=REGION \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME,\
   outputTopic=projects/PROJECT_ID/topics/INPUT_TOPIC_NAME
   

4. Copia el ID del trabajo de Dataflow desde el resultado del comando y guárdalo para usarlo más adelante. Ingresarás este ID de trabajo como REPLAY_JOB_ID cuando desvíes tu trabajo de Dataflow.

5. En la consola de Google Cloud, ve a la página Suscripciones de Pub/Sub.

   Ir a Suscripciones de Pub/Sub

6. Selecciona la suscripción no procesada. Confirma que el gráfico Recuento de mensajes sin confirmación sea 0, como se muestra en la siguiente captura de pantalla.

   

7. En Cloud Shell, desvía el trabajo de Dataflow que creaste:

   gcloud dataflow jobs drain REPLAY_JOB_ID --region=REGION
   

   Reemplaza REPLAY_JOB_ID por el ID de trabajo de Dataflow que guardaste antes.

Cuando los mensajes se transfieren de vuelta al tema de entrada original, la canalización principal de Dataflow recoge de forma automática los mensajes con errores y los vuelve a entregar a Splunk.

Confirma mensajes en Splunk

1. Para confirmar que los mensajes se volvieron a entregar, en Splunk abre Informes y búsqueda de Splunk

2. Realiza una búsqueda de delivery_attempts > 1. Este es un campo especial que la UDF de muestra agrega a cada evento para realizar un seguimiento de la cantidad de intentos de entrega. Asegúrate de expandir el intervalo de tiempo de búsqueda para incluir eventos que pueden haber ocurrido antes, ya que la marca de tiempo del evento es la hora original de creación, no la hora de la indexación.

En la siguiente captura de pantalla, los dos mensajes que originalmente fallaron se entregaron y se indexaron de forma correcta en Splunk con la marca de tiempo correcta.

Ten en cuenta que el valor del campo insertId es el mismo que el valor que aparece en los mensajes con errores cuando ves la suscripción no procesada. El campo insertId es un identificador único que Cloud Logging asigna a la entrada de registro original. insertId también aparece en el cuerpo del mensaje de Pub/Sub.

Limpia

Para evitar que se apliquen cargos a su cuenta de Google Cloud por los recursos usados en esta arquitectura de referencia, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra el receptor a nivel de organización

• Usa el siguiente comando para borrar el receptor de registros a nivel de la organización:

  gcloud logging sinks delete ORGANIZATION_SINK_NAME --organization=ORGANIZATION_ID
  

Borra el proyecto

Con el receptor de registros borrado, puedes continuar con la eliminación de recursos creados para recibir y exportar registros. La forma más fácil es borrar el proyecto que creaste para la arquitectura de referencia.

Precaución: Borrar un proyecto tiene las siguientes consecuencias:
• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

¿Qué sigue?

• Para obtener una lista completa de los parámetros de la plantilla de Dataflow de Pub/Sub a Splunk, consulta la documentación de Pub/Sub a Splunk Dataflow.
• Para que las plantillas de Terraform correspondientes te ayuden a implementar esta arquitectura de referencia, consulta el repositorio de GitHub terraform-splunk-log-export. Incluye un panel de Cloud Monitoring compilado con anterioridad para supervisar tu canalización de Splunk Dataflow.
• Para obtener más información sobre las métricas personalizadas y el registro de Dataflow de Splunk para ayudarte a supervisar y solucionar problemas de las canalizaciones de Dataflow de Splunk, consulta este blog Nuevas funciones de observabilidad para las canalizaciones de transmisión de Splunk Dataflow.
• Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.