BLOG IT

Voy a crear una serie artículos explicando los diferentes tipos de arquitecturas de Splunk y sus componentes. De forma rápida, los principales componentes de Splunk: Search Head (SH):  Es el encargado de realizar las búsquedas sobre los datos, ejecutar alarmas, contiene cuadros de mandos, login de usuarios. Suele demandar muchas CPUs Indexador (IDX):  Es donde se almacena toda la información, y donde nuestros SH irán a buscarla. Aquí debemos disponer de almacenamiento. Lo normal es disponer de un almacenamiento lo mas rápido posible para datos recientes, y otro "normal" para los datos históricos. Forwarder:  El encargado de recoger y envinar la información a nuestro IDX, en estos dos artículos ya hable de ellos  Splunk Forwarder   y   Forwarder VS Heavy Forwarder Ya veremos más adelante que pueden existir otros componentes. Todos estos componentes, se pueden agrupar o distribuir de la siguiente forma: ...

Una duda típica a la hora de recoger/enviar eventos a los indexadores, es que tipo de forwarder usar. Como norma general lo ideal es usar siempre Universal Forwarder (UF) ,  este es un agente muy ligero, que apenas consume recursos del host donde se instala, incluso existe una versión para Raspberry Pi, aquí . Existe otro tipo, llamado  Heavy Forwarder (HF),  este es mas pesado, pero dispone de funcionalidades adicionales, como: Posibilidad de filtrar/descartar eventos Posibilidad de conectarte a varias DB a través de la App DB Connect Realizar enrutado de información compleja. Esto son grandes ventajas, pero a cambio, el envío de información es mas pesado, y puede sobrecargar la red, ya que el HF parsea los eventos, y esto hace que incrementen su tamaño. Por esto, siempre es recomendable usar UF, salvo que no que nos encontremos en alguno de los tres casos anteriores. Aquí is dejo un enlace del blog de Splunk donde lo explican en detalle,  Universa...

Un componente casi imprescindible, pero no obligatorio en casi cualquier despliegue de Splunk es el F orwarder (FW). Este componente es el encargado de recolectar, enrutar, filtrar información... sobre nuestros datos, se puede instalar en maquinas Windows y Unix, puede recoger información de una BBDD o de una web, vía REST API, por ejemplo, y enviarlo directamente a nuestro indexador o incluso a otro FW. Por supuesto puede enviar la información cifrada, comprobar si ha llegado al destino, dispone de una cache que puede retener los datos (muy útil cuando trabajamos con eventos enviados por un router, firewall o dispositivo IOT) y muchas otras funcionalidades que lo hacen tan interesante, pero lo que no pueden hacer, es indexar información En nuestra arquitectura podemos tener cientos de FW desplegados, en este caso lo ideal es montar un Deploytment Server , el cual se encarga de enviar configuraciones a nuestros FW, y así nos evitamos tener que ir uno a uno. Si hablamos de FW, d...