BLOG IT

No solo de Splunk vive el hombre! Otra de las herramientas con las que llevo bastante tiempo trabajando es Qlik Sense , una de las herramientas TOP dentro del mundo BI. Aunque la parte de visualización es muy potente, y a los usuarios finales les suele gustar mucho, para mi sin duda, su punto estrella es su posibilidad de ejercer de ETL, y la parte del script de carga, donde podemos programar recargas y hacer transformaciones de datos para luego presentárselas forma impecable al usuario. Pero bueno, vamos al grano, hace unos días me encontré con una problemática en un proyecto de Qlik Sense . Tenia que descargarme de varias web unos JSON para realizar unos dashboards, en principio la cosa no parecía muy complicada, salvo por la complejidad de como trata Qlik la descarga de los JSON, y la estructura que le da a estos, ademas estas descargas tenían que ser exactamente iguales, pero cambiando los credenciales, ya que en función del usuario, los datos eran diferentes, la verdad que...

El otro día encontré un articulo en el blog de Splunk titulado " Splunk Validated Architectures " el cual me pareció muy interesante, ya que explicaba los pasos a seguir a la hora de desplegar una arquitectura de Splunk , y las consideraciones que deberíamos de tomar a la hora de diseñar nuestra arquitectura... Una cosa ademas que me gusto mucho, fue el uso de códigos para definir el tipo de arquitectura por capa (SHC, single node...) os lo adjunto la URL .

Uno de los mayores problemas de Splunk es el control de versiones de una App o un dashboard , hablando siempre de la parte de presentación, ya que la parte de indexación apenas suele tener cambios. Esto se complica cuando ademas tenemos sobre una misma App a varias personas creando dashboards o reports. Splunk por desgracia no dispone de un sistema nativo de control de versiones. Hace unos meses, pusieron en Splunk base la siguiente App , la cual nos permite llevar un control de versiones, yo no la he podido probar aún, pero si alguno la probáis, podéis poner vuestros comentarios. Hace tiempo, cuando me encontré con este problema, después de buscar, encontré la  esta solución , esta muy bien si tenemos un Deployment Server, en caso de no disponer de uno, podemos intentar adaptarlo a nuestro entorno, desplegando directamente sobre el SH, o nuestro entorno StandAlone

Cuando empezamos a trabajar con una tecnología nueva, nos encontramos con problemas que no sabemos muy bien como solucionar, donde encontrarlo los logs, como hacer debug... Muchas veces nos lanzamos a leer la doc oficial del fabricante, blog, google... un día navegando encontré este enlace  el cual me parece muy útil. De todas formas sigo pensando que lo mejor es buena formación

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...

Con las Apps de Splunk podemos tener parametrizados unos tipos de datos de entrada, alarmas, dashboards... Nosotros podemos crear nuestras propias Apps , pero también podemos descargarlas del propio repositorio de Splunk , Splunk Base . Básicamente existen dos tipo de Apps, las gratuitas y las premiun . Las gratuitas las podemos descargar e instalar en nuestro entorno, alguna están desarrolladas por la comunidad, otras por la propia Splunk y otras por fabricantes. Muchas de ellas disponen de documentación donde explican como desplegarlas en un nuestro entorno, versiones soportadas... Algunas gratuitas destacadas Cisco Security Suite DB Connect Palo Alto Networks Alert Manager Ademas de estas gratuitas, también existen las llamadas premium, las cuales tendremos que licenciar de manera adicional, estas son pocas, pero muy potentes Splunk App for VMware Splunk App for PCI Compliance Splunk App for Microsoft Exchange Splunk Enterprise Security   Cuando vamos a aña...