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 estadísticas popular que ofrece una plataforma unificada de seguridad y observabilidad. De hecho, tienes la opción de exportar los datos de registro a Splunk Enterprise o 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 registros de recursos de Google Cloud 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 procesa los registros y los exporta 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 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 suscripción para los registros y reenvía los registros 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 el recopilador HTTP de eventos (HEC) y reciben los registros para un análisis más detallado. Puedes implementar Splunk de forma local, en Google Cloud como SaaS o mediante un enfoque híbrido.
Caso de uso
Esta arquitectura de referencia usa un enfoque basado en envíos en la nube. 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 centra en los registros de Google Cloud, se puede usar la misma arquitectura para exportar otros datos de Google Cloud, como cambios de recursos en tiempo real y resultados 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 datos de Google Cloud a Splunk tiene las siguientes ventajas:
- Servicio administrado. Como un 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 en varios trabajadores para su procesamiento en paralelo, por lo que no hay un punto único de fallo.
- Seguridad. Debido a que Google Cloud envía tus datos al HEC de Splunk, 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 la red o el servidor, el método basado en envíos intenta reenviar de forma automática los datos al HEC de Splunk. 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 elijas exportar tus datos de Google Cloud a Splunk, es posible que lo hagas 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 el que usas para extraer registros de Google 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 para Google Cloud. Puedes elegir usar el método basado en extracciones en las siguientes situaciones:
- Tu implementación de Splunk no ofrece un extremo de HEC de Splunk.
- Tu volumen de registros es bajo.
- Deseas analizar métricas de Cloud Monitoring, objetos de Cloud Storage, metadatos de la API de Cloud Resource Manager o registros de bajo volumen.
- Ya administras uno o más servidores de reenvío pesados en Splunk.
- Usa el administrador de datos de entrada para la nube de Splunk alojada.
Además, ten en cuenta las consideraciones adicionales que surgen cuando usas este método basado en extracciones:
- Un solo trabajador maneja la carga de trabajo de transferencia de datos, que no ofrece capacidades de ajuste de escala automático.
- En Splunk, el uso de un servidor de reenvío pesado para extraer datos puede provocar un punto único de fallo.
- El método basado en extracciones requiere crear y administrar las claves de la cuenta de servicio que usas para configurar el complemento de Splunk para Google Cloud.
Para habilitar el complemento de Splunk, sigue estos pasos:
- En Splunk, sigue las instrucciones de Splunk para instalar el complemento de Splunk para Google Cloud.
- En Google Cloud, crea un tema de Pub/Sub para exportar los datos de registro.
- Crea una suscripción de extracción de Pub/Sub para este tema.
- Crea una cuenta de servicio.
- Crea una clave de cuenta de servicio para la cuenta de servicio que acabas de crear.
- 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. 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 aparecen en Splunk.
Para verificar que el complemento funcione, sigue estos pasos:
- En Cloud Monitoring, abre el Explorador de métricas.
- En el menú Recursos, selecciona
pubsub_subscription. - En las categorías Métricas, selecciona
pubsub/subscription/pull_message_operation_count. - 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
- Habilite el Acceso privado a Google
- Restringe el tráfico de entrada de HEC de Splunk a las direcciones IP conocidas que usa Cloud NAT
- Almacena el token HEC de Splunk en Secret Manager
- Crea una cuenta de servicio de trabajador personalizada de Dataflow para seguir las prácticas recomendadas sobre privilegios mínimos
- Configura la validación de SSL para un certificado de CA raíz interno si usas una CA privada
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 la implementación de Splunk, puedes configurar las reglas de firewall de entrada de HEC de Splunk mediante 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 implementas la canalización de Dataflow, puedes pasar el valor del token de una de las siguientes maneras:
- Texto simple
- Algoritmo de 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, debes usar la opción de Secret Manager porque esta opción ofrece la forma menos compleja y eficiente de proteger el token HEC de Splunk. Esta opción también evita la filtración del token de HEC de Splunk desde la consola de Dataflow o los detalles del trabajo.
Un secreto en Secret Manager contiene una colección de versiones de secretos. Cada versión del secreto almacena los datos reales del secreto, como el token HEC de Splunk. Si luego eliges rotar el token de HEC de Splunk como una medida de seguridad adicional, puedes agregar el token nuevo como una versión de secreto nueva a este secreto. Para obtener información general sobre la rotación de los 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 en 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 del trabajador, lo que les otorga permisos amplios para todos los recursos del 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 tus trabajadores de canalización de Dataflow.
En el siguiente diagrama, se enumeran los roles necesarios que debes asignar a una cuenta de servicio para permitir que los trabajadores de Dataflow ejecuten un trabajo de Dataflow de forma correcta.
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. Los trabajadores de Dataflow pueden usar el certificado importado para la validación del certificado 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 solo para fines de desarrollo y pruebas internas. Este método de CA raíz interno funciona mejor para implementaciones internas de Splunk no 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 es compatible con 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. Esta arquitectura de referencia usa una UDF para manejar 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 entregar el mensaje de nuevo. En este caso, Dataflow envía estos mensajes no procesados a un tema sin procesar, como se muestra en el diagrama siguiente. Después de corregir la causa raíz de la falla de entrega, puedes volver a reproducir los mensajes no procesados.
En los siguientes pasos, se describe el proceso que se muestra en el diagrama anterior:
- La canalización de entrega principal de Pub/Sub a Splunk reenvía automáticamente los mensajes que no se pueden entregar al tema no procesado para la investigación del usuario.
El operador o el ingeniero de confiabilidad de sitios (SRE) investiga los mensajes con errores en la suscripción no procesada. El operador soluciona los problemas de la causa raíz de la falla de entrega y la corrige. Por ejemplo, corregir una configuración incorrecta del token HEC podría permitir que se entreguen los mensajes.
El operador activa la canalización de mensajes de error de repetición. 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.
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 |
Sí |
o
|
Error 5xx del servidor de Splunk |
Sí |
|
Error 4xx del servidor de Splunk |
No |
|
El servidor de Splunk está fuera de servicio |
No |
|
El certificado SSL de Splunk no es válido |
No. |
|
Error de sintaxis de JavaScript en la función definida por el usuario (UDF) |
No. |
|
En algunos casos, la canalización aplica la retirada exponencial y trata de entregar el mensaje de nuevo de forma automática. 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 del HEC. Para estos problemas persistentes, la canalización no intenta entregar el mensaje de nuevo. 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 capacidad de procesamiento para que el sistema no genere ninguno de los siguientes problemas:
- Demoras debido a la acumulación de mensajes o a 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:
- Las marcas Tipo de máquina yCantidad de máquinas son parte del comando de gcloud que implementa el trabajo de Dataflow. Estas marcas te permiten definir el tipo y la cantidad de VMs que se usarán.
- Los parámetros Paralelismo yRecuento de lotes son parte de la plantilla de Dataflow de Pub/Sub a Splunk. Estos parámetros son importantes para aumentar los EPS y evitar abrumar el extremo del HEC de Splunk.
En las secciones siguientes, se proporciona una explicación de esta 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 que una organización tiene 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, sustituye los valores de ejemplo por valores de tu propia organización a medida que trabajas con los pasos.
Tipo de máquina
Práctica recomendada: Configura la marca --worker-machine-type en n1-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 n1-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, configura la marca --worker-machine-type en un valor de n1-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 y la carga de recursos. 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. Define la cantidad máxima de máquinas virtuales con la marca --max-workers cuando implementes la canalización de Dataflow.
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 en tu canalización, usa las siguientes fórmulas en secuencia:
Determina los eventos promedio por segundo (EPS) con la siguiente fórmula:
\( {AverageEventsPerSecond}\simeq\frac{TotalDailyLogsInTB}{AverageMessageSizeInKB}\times\frac{10^9}{24\times3600} \)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.
Determina el EPS continuo con la siguiente fórmula, en la que el multiplicador N representa la naturaleza inestable del registro:
\( {PeakEventsPerSecond = N \times\ 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.
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 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.
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 un
n1-standard-4tipo de máquina.
Para este ejemplo, debes establecer 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 valores y cálculos únicos cuando implementes esta arquitectura de referencia en el 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 de HEC de Splunk paralelas, lo que, a su vez, maximiza la tasa de EPS para tu canalización.
El valor predeterminado parallelism de 1 inhabilita el paralelismo y limita la tasa de salida. Debes anular esta configuración predeterminada para dar cuenta de entre 2 y 4 conexiones paralelas por CPU virtual, con la cantidad máxima de trabajadores implementados. Como regla general, debes calcular el valor de anulación para esta configuración mediante la multiplicación de 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:
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.
Para este ejemplo, debes establecer el parámetro parallelism en un valor de 16 según el cálculo de ejemplo anterior. Sin embargo, recuerda usar tus propios valores y cálculos únicos cuando implementes esta arquitectura de referencia en el 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
La configuración del recuento por lotes ayuda a aumentar la EPS y reducir la carga en el extremo del HEC de Splunk. Esta configuración combina varios eventos en un solo lote para lograr un procesamiento más eficiente. Te recomendamos que establezcas el parámetro batchCount en un valor de entre 10 y 50 eventos o solicitudes para los registros, siempre que la demora máxima del almacenamiento en búfer de dos segundos sea aceptable.
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. Para este ejemplo, debes establecer el parámetro batchCount en un valor de 10. Sin embargo, recuerda usar tus propios valores y cálculos únicos cuando implementes esta arquitectura de referencia en el entorno.
Para obtener más información sobre estas recomendaciones de rendimiento y optimización de costos, 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?
- 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.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.