BLOG IT

Uno de los mayores problemas que nos podemos encontrar para hacer pruebas de tiempo real o demos, es la falta de alguna fuente que nos provea de estos eventos. Splunk ya pensó en esto hace tiempo, y tiene una App , la cual nos genera estos eventos en tiempo real, con la que podemos hacer infinidad de pruebas, o incluso podemos llevar a una demo. En este enlace se nos explica con detalle todo el detalle de instalación, configuración...

Los " Data Model " de Splunk   nos pueden servir de gran ayuda en muchos proyectos, en el caso de tener un gran cantidad de registros (miles de millones). Aunque esta es una novedad introducida hace tiempo, aún existen despliegues donde no se usan, es bastante habitual verlo en las App de seguridad, como por ejemplo Palo Alto Algunas de las ventajas de disponer de nuestro Data Model Nos permite crear modelos de datos acelerados, podemos elegir por ejemplo disponer de los últimos 30 días acelerados. Además, poder crear campos ad hoc, crear extracciones, enriquecer la información con lookups..., y todo esto mantenerlo en un modelo aparte a los datos raw. Con esta información enriquecida, podemos usar los Pivot , estos nos permite dar acceso a usuarios a construirse sus propios informes, de una manera muy sencilla y visual, sin tener que conocer SPL, aquí os dejo un par de links Doc oficial   Video De esta manera podemos conseguir acceder a nuestra información d...

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