Transmite registros de Google Cloud a Splunk

Last reviewed 2024-10-24 UTC

En este documento, se describe una arquitectura de referencia que te ayuda a crear un mecanismo de exportación de registros listo para la producción, escalable y tolerante a errores que transmite registros y eventos de tus recursos en Google Cloud a Splunk. Splunk es una herramienta de análisis popular que ofrece una plataforma unificada de seguridad y observabilidad. De hecho, puedes exportar los datos de registro a Splunk Enterprise o a Splunk Cloud Platform. Si eres administrador, también puedes usar esta arquitectura para operaciones de TI o casos de uso de seguridad. Para implementar esta arquitectura de referencia, consulta Implementa la transmisión de registros de Google Cloud a Splunk.

En esta arquitectura de referencia, se da por sentado que una jerarquía de recursos es similar al siguiente diagrama. Todos los Google Cloud registros de recursos de los niveles de organización, carpeta y proyecto se recopilan en un receptor agregado. Luego, el receptor agregado envía estos registros a una canalización de exportación de registros, que los procesa y los exporta a Splunk.

Receptor de registros agregado a nivel de la organización para la exportación a Splunk.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de referencia que debes usar cuando implementas esta solución. En este diagrama, se muestra cómo fluyen los datos de registro deGoogle Cloud a Splunk.

Flujo de registros de Google Cloud a Splunk.

Esta arquitectura incluye los siguientes componentes:

  • Cloud Logging: para iniciar el proceso, recopila los registros en un receptor de registros agregado a nivel de la organización y envía los registros a Pub/Sub.
  • Pub/Sub: Luego, el servicio de Pub/Sub crea un solo tema y una suscripción para los registros y los reenvía a la canalización principal de Dataflow.
  • Dataflow: Hay dos canalizaciones de Dataflow en esta arquitectura de referencia:
    • Canalización primaria de Dataflow: En el centro del proceso, 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 envía a Splunk.
    • Canalización secundaria de Dataflow: paralela a la canalización de Dataflow principal, la canalización de Dataflow secundaria es una canalización de transmisión de Pub/Sub a Pub/Sub para volver a reproducir mensajes si falla una entrega.
  • Splunk: Al final del proceso, Splunk Enterprise o Splunk Cloud Platform actúan como un recopilador de eventos HTTP (HEC) y reciben los registros para un análisis más detallado. Puedes implementar Splunk de forma local, en Google Cloud como SaaS o con un enfoque híbrido.

Caso de uso

En esta arquitectura de referencia, se usa un enfoque basado en la nube y en la publicación. En este método basado en envíos, usas la plantilla de Dataflow de Pub/Sub a Splunk para transmitir registros a un recopilador de eventos HTTP de Splunk (HEC). La arquitectura de referencia también se analiza la planificación de la capacidad de canalización de Dataflow y cómo manejar las posibles fallas de entrega cuando hay problemas transitorios de las redes o de los servidores.

Si bien esta arquitectura de referencia se enfoca en los Google Cloud registros, se puede usar la misma arquitectura para exportar otros Google Cloud datos, como los cambios de recursos en tiempo real y los hallazgos de seguridad. Si integras los registros de Cloud Logging, puedes continuar usando los servicios de socios existentes, como Splunk, como solución de estadísticas de registros unificada.

El método basado en envíos para transmitir Google Cloud datos a Splunk tiene las siguientes ventajas:

  • Servicio administrado. Como servicio administrado, Dataflow mantiene los recursos necesarios en Google Cloud para tareas de procesamiento de datos, como la exportación de registros.
  • Carga de trabajo distribuida. Este método te permite distribuir cargas de trabajo entre varios trabajadores para el procesamiento en paralelo, de modo que no haya un solo punto de falla.
  • Seguridad. Debido a que Google Cloud envía tus datos a Splunk HEC, no existe la carga de mantenimiento y seguridad asociada con la creación y administración de claves de cuentas de servicio.
  • Ajuste de escala automático. El servicio de Dataflow ajusta de forma automática la cantidad de trabajadores en respuesta a las variaciones en el volumen de registros entrante y en las tareas pendientes.
  • Tolerancia a errores. ​​Si hay problemas temporales con las redes o los servidores, el método basado en notificaciones push intenta volver a enviar los datos al HEC de Splunk automáticamente. Este método también admite temas no procesados (también conocidos como temas de mensajes no entregados) para cualquier mensaje de registro que no se pueda entregar para evitar la pérdida de datos.
  • Simplicidad. Evitas la sobrecarga de administración y el costo de ejecutar uno o más servidores de reenvío pesados en Splunk.

Esta arquitectura de referencia se aplica a empresas en muchas industrias verticales, incluidas las reguladas, como los servicios farmacéuticos y financieros. Cuando eliges exportar tus Google Cloud datos a Splunk, puedes hacerlo por los siguientes motivos:

  • Análisis empresariales
  • Operaciones de TI
  • Supervisión del rendimiento de las aplicaciones
  • Operaciones de seguridad
  • Cumplimiento

Alternativas de diseño

Un método alternativo para exportar registros a Splunk es extraer registros deGoogle Cloud. En este método basado en extracciones, debes usar las APIs de Google Cloud para recuperar los datos a través del complemento de Splunk paraGoogle Cloud. Puedes optar por usar el método basado en la extracción en las siguientes situaciones:

  • Tu implementación de Splunk no ofrece un extremo de HEC de Splunk.
  • Tu volumen de registros es bajo.
  • Quieres exportar y analizar métricas de Cloud Monitoring, objetos de Cloud Storage, metadatos de la API de Cloud Resource Manager, datos de Facturación de Cloud o registros de bajo volumen.
  • Ya administras uno o más servidores de reenvío pesados en Splunk.
  • Usas el administrador de datos de entrada para Splunk Cloud alojado.

Además, ten en cuenta las consideraciones adicionales que surgen cuando usas este método basado en la extracción:

  • Un solo trabajador controla la carga de trabajo de transferencia de datos, que no ofrece capacidades de escalamiento automático.
  • En Splunk, el uso de un servidor de reenvío pesado para extraer datos puede causar un punto único de fallo.
  • El método basado en extracciones requiere que crees y administres las claves de cuenta de servicio que usas para configurar el complemento de Splunk para Google Cloud.

Antes de usar el complemento de Splunk, las entradas de registro deben enrutarse a Pub/Sub con un receptor de registros. Para crear un receptor de registros con el tema de Pub/Sub como destino, sigue estos pasos. Asegúrate de otorgar el rol de publicador de Pub/Sub (roles/pubsub.publisher) a la identidad de escritor del receptor en ese destino de tema de Pub/Sub. Para obtener más información sobre la configuración de permisos de destino de sink, consulta Configura permisos de destino.

Para habilitar el complemento de Splunk, sigue estos pasos:

  1. En Splunk, sigue las instrucciones de Splunk para instalar el complemento de Splunk para Google Cloud.
  2. Crea una suscripción de extracción de Pub/Sub para el tema de Pub/Sub al que se enrutan los registros, si aún no tienes una.
  3. Crea una cuenta de servicio.
  4. Crea una clave de cuenta de servicio para la cuenta de servicio que acabas de crear.
  5. Otorga los roles de visualizador de Pub/Sub (roles/pubsub.viewer) y suscriptor de Pub/Sub (roles/pubsub.subscriber) a la cuenta de servicio para permitir que la cuenta reciba mensajes de la suscripción a Pub/Sub.
  6. En Splunk, sigue las instrucciones de Splunk para configurar una entrada de Pub/Sub nueva en el complemento de Splunk para Google Cloud.

    Los mensajes de Pub/Sub de la exportación de registros aparecerán en Splunk.

Para verificar que el complemento funcione, sigue estos pasos:

  1. En Cloud Monitoring, abre el Explorador de métricas.
  2. En el menú Recursos, selecciona pubsub_subscription.
  3. En las categorías Métrica, selecciona pubsub/subscription/pull_message_operation_count.
  4. Supervisa la cantidad de operaciones de extracción de mensajes durante uno o dos minutos.

Consideraciones del diseño

Los siguientes lineamientos pueden ayudarte a desarrollar una arquitectura que cumpla con los requisitos de seguridad, privacidad, cumplimiento, eficiencia operativa, confiabilidad, tolerancia a errores, rendimiento y optimización de costos de la organización.

Seguridad, privacidad y cumplimiento

En las siguientes secciones, se describen las consideraciones de seguridad para esta arquitectura de referencia:

Usa direcciones IP privadas para proteger las VMs que admiten la canalización de Dataflow

Debes restringir el acceso a las VMs de trabajador que se usan en la canalización de Dataflow. Para restringir el acceso, implementa estas VMs con direcciones IP privadas. Sin embargo, estas VMs también deben poder usar HTTPS para transmitir los registros exportados a Splunk y acceder a Internet. Para proporcionar este acceso HTTPS, necesitas una puerta de enlace de Cloud NAT que asigne automáticamente direcciones IP de Cloud NAT a las VMs que las necesitan. Asegúrate de asignar la subred que contiene las VMs a la puerta de enlace de Cloud NAT.

Habilite el Acceso privado a Google

Cuando creas una puerta de enlace de Cloud NAT, el Acceso privado a Google se habilita de forma automática. Sin embargo, para permitir que los trabajadores de Dataflow con direcciones IP privadas accedan a las direcciones IP externas que usan las APIs y los servicios de Google Cloud, también debes habilitar de forma manual el Acceso privado a Google para la subred.

Restringe el tráfico de entrada de HEC de Splunk a las direcciones IP conocidas que usa Cloud NAT

Si deseas restringir el tráfico de HEC de Splunk a un subconjunto de direcciones IP conocidas, puedes reservar direcciones IP estáticas y asignarlas manualmente a la puerta de enlace de Cloud NAT. Según tu implementación de Splunk, puedes configurar las reglas de firewall de entrada de Splunk HEC con estas direcciones IP estáticas. Para obtener más información sobre Cloud NAT, consulta Configura y administra la traducción de direcciones de red con Cloud NAT.

Almacena el token HEC de Splunk en Secret Manager

Cuando implementes la canalización de Dataflow, puedes pasar el valor del token de una de las siguientes maneras:

  • Texto simple
  • Cifrado encriptado con una clave de Cloud Key Management Service
  • Versión del secreto encriptada y administrada por Secret Manager

En esta arquitectura de referencia, usas la opción de Secret Manager porque esta opción ofrece la forma menos compleja y más eficiente de proteger tu token de HEC de Splunk. Esta opción también evita que se filtre el token del HEC de Splunk desde la consola de Dataflow o los detalles del trabajo.

Un secreto de Secret Manager contiene una colección de versiones de secretos. Cada versión de secreto almacena los datos secretos reales, como el token HEC de Splunk. Si luego eliges rotar tu token de HEC de Splunk como medida de seguridad adicional, puedes agregar el token nuevo como una versión nueva del secreto a este secreto. Para obtener información general sobre la rotación de secretos, consulta Acerca de los programas de rotación.

Crea una cuenta de servicio de trabajador personalizada de Dataflow para seguir las prácticas recomendadas sobre privilegios mínimos

Los trabajadores de la canalización de Dataflow usan la cuenta de servicio de trabajador de Dataflow para acceder a los recursos y ejecutar operaciones. De forma predeterminada, los trabajadores usan la cuenta de servicio predeterminada de Compute Engine del proyecto como la cuenta de servicio de trabajador, lo que les otorga permisos amplios a todos los recursos de tu proyecto. Sin embargo, para ejecutar trabajos de Dataflow en producción, te recomendamos que crees una cuenta de servicio personalizada con un conjunto mínimo de roles y permisos. Luego, puedes asignar esta cuenta de servicio personalizada a los trabajadores de tu canalización de Dataflow.

En el siguiente diagrama, se enumeran los roles obligatorios que debes asignar a una cuenta de servicio para permitir que los trabajadores de Dataflow ejecuten un trabajo de Dataflow de forma correcta.

Roles necesarios para asignar a una cuenta de servicio de trabajador de Dataflow.

Como se muestra en el diagrama, debes asignar los siguientes roles a la cuenta de servicio para tu trabajador de Dataflow:

  • Administrador de Dataflow
  • Trabajador de Dataflow
  • Administrador de objetos de Storage
  • Suscriptor de Pub/Sub
  • Visualizador de Pub/Sub
  • Publicador de Pub/Sub
  • Descriptor de acceso a secretos

Para obtener más detalles sobre los roles que debes asignar a la cuenta de servicio de trabajador de Dataflow, consulta la sección Otorga roles y acceso a la cuenta de servicio de trabajador de Dataflow en la guía de implementación.

Configura la validación SSL con un certificado de CA raíz interno si usas una CA privada

De forma predeterminada, la canalización de Dataflow usa el almacén de confianza predeterminado del trabajador de Dataflow para validar el certificado SSL para el extremo del HEC de Splunk. Si usas una autoridad certificadora (CA) privada para firmar un certificado SSL que usa el extremo del HEC de Splunk, puedes importar tu certificado de CA raíz interno al almacén de confianza. Luego, los trabajadores de Dataflow pueden usar el certificado importado para la validación de certificados SSL.

Puedes usar e importar tu propio certificado de CA raíz para las implementaciones de Splunk con certificados autofirmados o firmados de forma privada. También puedes inhabilitar la validación de SSL por completo solo para fines de desarrollo y pruebas internos. Este método de AC raíz interno funciona mejor para las implementaciones internas de Splunk que no están orientadas a Internet.

Para obtener más información, consulta los parámetros de la plantilla de Pub/Sub a Splunk Dataflow rootCaCertificatePath y disableCertificateValidation.

Eficiencia operativa

En las secciones siguientes, se describen las consideraciones de eficiencia operativa para esta arquitectura de referencia:

Usa UDF para transformar registros o eventos en tránsito

La plantilla de Pub/Sub a Splunk Dataflow admite funciones definidas por el usuario (UDF) para la transformación de eventos personalizados. Los casos de uso de ejemplo incluyen enriquecer registros con campos adicionales, ocultar algunos campos sensibles o filtrar registros no deseados. UDF te permite cambiar el formato de salida de la canalización de Dataflow sin tener que volver a compilar ni mantener el código de la plantilla. En esta arquitectura de referencia, se usa una UDF para controlar los mensajes que la canalización no puede entregar a Splunk.

Vuelve a reproducir mensajes no procesados

A veces, la canalización recibe errores de entrega y no intenta volver a entregar el mensaje. En este caso, Dataflow envía estos mensajes no procesados a un tema no procesado, como se muestra en el siguiente diagrama. Después de corregir la causa raíz de la falla de entrega, puedes volver a reproducir los mensajes no procesados.

Manejo de errores cuando se exportan registros a Splunk.

En los siguientes pasos, se describe el proceso que se muestra en el diagrama anterior:

  1. La canalización de entrega principal de Pub/Sub a Splunk reenvía automáticamente mensajes que no se pueden entregar al tema no procesado para la investigación del usuario.
  2. El operador o ingeniero de confiabilidad de sitios (SRE) investiga los mensajes con errores en la suscripción no procesada. El operador soluciona los problemas y corrige la causa raíz de la falla de entrega. Por ejemplo, corregir una configuración incorrecta del token del HEC podría permitir que se entreguen los mensajes.

  3. El operador activa la canalización de mensajes de repetición con errores. Esta canalización de Pub/Sub a Pub/Sub (destacada en la sección punteada del diagrama anterior) es una canalización temporal que mueve los mensajes con errores de la suscripción no procesada al tema del receptor de registros original.

  4. La canalización principal de entrega vuelve a procesar los mensajes con errores anteriores. Este paso requiere que la canalización use la UDF de muestra para la detección y decodificación correctas de las cargas útiles de mensajes con errores. En el siguiente código, se muestra la parte de la función que implementa esta lógica de decodificación condicional, incluido un recuento de intentos de entrega con fines de seguimiento:

    // If the message has already been converted to a Splunk HEC object
    // with a stringified obj.event JSON payload, then it's a replay of
    // a previously failed delivery.
    // Unnest and parse the obj.event. Drop the previously injected
    // obj.attributes such as errorMessage and timestamp
    if (obj.event) {
     try {
       event = JSON.parse(obj.event);
       redelivery = true;
     } catch(e) {
       event = obj;
     }
    } else {
     event = obj;
    }
    
    // Keep a tally of delivery attempts
    event.delivery_attempt = event.delivery_attempt || 1;
    if (redelivery) {
     event.delivery_attempt += 1;
    }
    

Confiabilidad y tolerancia a errores

En cuanto a la confiabilidad y la tolerancia a errores, la siguiente tabla, Tabla 1, enumera algunos posibles errores de entrega de Splunk. En la tabla, también se enumeran los atributos errorMessage correspondientes que la canalización registra con cada mensaje antes de reenviar estos mensajes al tema no procesado.

Tabla 1: Tipos de errores de entrega de Splunk

Tipo de error de entrega ¿La canalización se reintenta de forma automática? Atributo de ejemplo errorMessage

Error de red transitorio

Read timed out

o

Connection reset

Error 5xx del servidor de Splunk

Splunk write status code: 503

Error 4xx del servidor de Splunk

No

Splunk write status code: 403

El servidor de Splunk está fuera de servicio

No

The target server failed to respond

El certificado SSL de Splunk no es válido

No.

Host name X does not match the certificate

Error de sintaxis de JavaScript en la función definida por el usuario (UDF)

No.

ReferenceError: X is not defined

En algunos casos, la canalización aplica una retirada exponencial y intenta volver a entregar el mensaje automáticamente. Por ejemplo, cuando el servidor de Splunk genera un código de error 5xx, la canalización debe volver a entregar el mensaje. Estos códigos de error se producen cuando el extremo del HEC de Splunk está sobrecargado.

De manera alternativa, podría haber un problema persistente que impida que se envíe un mensaje al extremo de HEC. En el caso de estos problemas persistentes, la canalización no intenta volver a entregar el mensaje. A continuación, se muestran ejemplos de problemas persistentes:

  • Un error de sintaxis en la función UDF.
  • Un token de HEC no válido que hace que el servidor de Splunk genere una respuesta de servidor “Prohibido” 4xx.

Rendimiento y optimización de costos

Con respecto al rendimiento y la optimización de costos, debes determinar el tamaño máximo y la capacidad de procesamiento de tu canalización de Dataflow. Debes calcular el valor correcto y los valores de capacidad de procesamiento para que tu canalización pueda controlar el volumen máximo de registros diarios (GB por día) y la tasa de mensajes de registro (eventos por segundo, o EPS) desde la suscripción Pub/Sub ascendente.

Debes seleccionar los valores de tamaño y rendimiento para que el sistema no tenga ninguno de los siguientes problemas:

  • Demoras causadas por la acumulación de mensajes o la regulación de mensajes.
  • Costos adicionales por aprovisionamiento excesivo de una canalización

Después de realizar los cálculos de tamaño y capacidad de procesamiento, puedes usar los resultados para configurar una canalización óptima que equilibre el rendimiento y el costo. Para configurar la capacidad de tu canalización, usa la siguiente configuración:

En las siguientes secciones, se proporciona una explicación de estos parámetros de configuración. Cuando corresponda, estas secciones también proporcionan fórmulas y cálculos de ejemplo que usan cada fórmula. En estos cálculos de ejemplo y los valores resultantes, se supone una organización con las siguientes características:

  • Genera 1 TB de registros por día.
  • Tiene un tamaño promedio de mensajes de 1 KB.
  • Tiene una tasa de mensajes máxima y constante dos veces la tasa promedio.

Debido a que tu entorno de Dataflow es único, reemplaza los valores de ejemplo por valores de tu propia organización a medida que avanzas con los pasos.

Tipo de máquina

Práctica recomendada: Establece la marca --worker-machine-type en n2-standard-4 para seleccionar un tamaño de máquina que proporcione la mejor relación entre rendimiento y costo.

Debido a que el tipo de máquina n2-standard-4 puede manejar 12,000 EPS, te recomendamos que uses este tipo de máquina como modelo de referencia para todos los trabajadores de Dataflow.

Para esta arquitectura de referencia, establece la marca --worker-machine-type en un valor de n2-standard-4.

Cantidad de máquinas

Práctica recomendada: Configura la marca --max-workers para controlar la cantidad máxima de trabajadores necesarios para controlar los EPS esperados.

El ajuste de escala automático de Dataflow permite que el servicio cambie de forma adaptativa la cantidad de trabajadores que se usan para ejecutar tu canalización de transmisión cuando hay cambios en el uso de recursos y la carga. Para evitar el aprovisionamiento excesivo durante el ajuste de escala automático, te recomendamos que definas siempre la cantidad máxima de máquinas virtuales que se usan como trabajadores de Dataflow. Cuando implementas la canalización de Dataflow, defines la cantidad máxima de máquinas virtuales con la marca --max-workers.

Dataflow aprovisiona de forma estática el componente de almacenamiento de la siguiente manera:

  • Una canalización de ajuste de escala automático implementa un disco persistente de datos para cada trabajador de transmisión potencial. El tamaño del disco persistente predeterminado es de 400 GB, y debes establecer la cantidad máxima de trabajadores con la marca --max-workers. Los discos se activan en los trabajadores en ejecución en cualquier momento, incluido el inicio.

  • Debido a que cada instancia de trabajador tiene un límite de 15 discos persistentes, la cantidad mínima de trabajadores iniciales es de ⌈--max-workers/15⌉. Por lo tanto, si el valor predeterminado es --max-workers=20, el uso (y el costo) de la canalización es el siguiente:

    • Almacenamiento: estático con 20 discos persistentes.
    • Procesamiento: dinámico con un mínimo de dos instancias de trabajador (⌈20/15⌉ = 2) y un máximo de 20.

    Este valor es equivalente a 8 TB de un disco persistente. Este tamaño de disco persistente podría generar un costo innecesario si los discos no se usan por completo, en especial si uno o dos trabajadores se ejecutan la mayoría del tiempo.

Para determinar la cantidad máxima de trabajadores que necesitas para tu canalización, usa las siguientes fórmulas en secuencia:

  1. Determina los eventos promedio por segundo (EPS) con la siguiente fórmula:

    AverageEventsPerSecondTotalDailyLogsInTBAverageMessageSizeInKB×10924×3600

    Cálculo de ejemplo: Dados los valores de ejemplo de 1 TB de registros por día con un tamaño de mensaje promedio de 1 KB, esta fórmula genera un valor EPS promedio de 11.5 KB de EPS.

  2. Determina el EPS máximo continuo con la siguiente fórmula, en la que el multiplicador N representa la naturaleza inestable del registro:

    PeakEventsPerSecond=N× AverageEventsPerSecond

    Cálculo de ejemplo: Con un valor de ejemplo de N=2 y un valor promedio de EPS de 11.5k que calculaste en el paso anterior, esta fórmula genera un valor máximo de EPS continuo de 23,000 EPS.

  3. Determina la cantidad máxima de CPU virtuales requeridas con la siguiente fórmula:

    maxCPUs=PeakEventsPerSecond/3k

    Cálculo de ejemplo: Con el valor máximo de EPS continuo de 23,000 que calculaste en el paso anterior, esta fórmula genera un máximo de ⌈23 / 3⌉ = 8 núcleos de CPU virtual.

  4. Determina la cantidad máxima de trabajadores de Dataflow con la siguiente fórmula:

    maxNumWorkers=maxCPUs/4

    Ejemplo de cálculo: Con el valor máximo de CPUs virtuales de ejemplo de 8 que se calculó en el paso anterior, esta fórmula [8/4] genera un número máximo de 2 para unn2-standard-4 tipo de máquina.

En este ejemplo, configurarías la marca --max-workers en un valor de 2 según el conjunto anterior de cálculos de ejemplo. Sin embargo, recuerda usar tus propios cálculos y valores únicos cuando implementes esta arquitectura de referencia en tu entorno.

Paralelismo

Práctica recomendada: Configura el parámetro parallelism en la plantilla de Pub/Sub a Splunk Dataflow para que sea el doble de la cantidad de CPUs virtuales que usa la cantidad máxima de trabajadores de Dataflow.

El parámetro parallelism ayuda a maximizar la cantidad de conexiones paralelas de HEC de Splunk, lo que, a su vez, maximiza la tasa de EPS de tu canalización.

El valor predeterminado parallelism de 1 inhabilita el paralelismo y limita la tasa de salida. Debes anular este parámetro de configuración predeterminado para dar cuenta de las conexiones paralelas de 2 a 4 por CPU virtual, con la cantidad máxima de trabajadores implementados. Como regla, para calcular el valor de anulación de este parámetro de configuración, debes multiplicar la cantidad máxima de trabajadores de Dataflow por la cantidad de CPU virtuales por trabajador y, luego, duplicar este valor.

Para determinar la cantidad total de conexiones paralelas al HEC de Splunk en todos los trabajadores de Dataflow, usa la siguiente fórmula:

parallelism=maxCPUs2

Cálculo de ejemplo: con el ejemplo de CPUs virtuales de 8 que se calculó antes para el recuento de máquinas, esta fórmula genera la cantidad de conexiones paralelas para que sean 8 x 2 = 16.

En este ejemplo, establecerías el parámetro parallelism en un valor de 16 según el cálculo del ejemplo anterior. Sin embargo, recuerda usar tus propios cálculos y valores únicos cuando implementes esta arquitectura de referencia en tu entorno.

Recuento de lotes

Práctica recomendada: Para permitir que el HEC de Splunk procese eventos en lotes en lugar de uno a la vez, establece el parámetro batchCount en un valor entre 10 y 50 eventos o solicitudes para registros

Configurar el recuento por lotes ayuda a aumentar los EPS y reducir la carga en el extremo del HEC de Splunk. La configuración combina varios eventos en un solo lote para un procesamiento más eficiente. Te recomendamos que establezcas el parámetro batchCount en un valor entre 10 y 50 eventos o solicitudes para registros, siempre que la demora máxima del almacenamiento en búfer de dos segundos sea aceptable.

batchCount>=10

Debido a que el tamaño promedio del mensaje de registro es de 1 KB en este ejemplo, te recomendamos que agrupes al menos 10 eventos por solicitud. En este ejemplo, configurarías el parámetro batchCount en un valor de 10. Sin embargo, recuerda usar tus propios cálculos y valores únicos cuando implementes esta arquitectura de referencia en tu entorno.

Para obtener más información sobre estas recomendaciones de optimización de costos y rendimiento, consulta Planifica tu canalización de Dataflow.

Implementación

Para implementar esta arquitectura de referencia, consulta Implementa la transmisión de registros de Google Cloud a Splunk.

¿Qué sigue?