BLOG IT

  Cuando tenemos que diseñar una arquitectura de Splunk , una de las cosas claves a tener en cuenta son los puertos y protocolos de comunicación. Aquí os dejo un diagrama muy útil donde se explica. NOTA: Existen algunas otras versiones más extensas, con algún detalle más, googleando con este mismo titulo se encuentran sin problemas.

SHC e Indexers Siguiendo con el anterior post , en este vamos a hablar de la arquitectura en alta disponibilidad o cluster de Splunk . A la hora de “clusterizar” nuestro entorno de Splunk, podemos dar alta disponibilidad a las siguientes capas: Search Head Cluster (SHC): Aquí damos alta disponibilidad a la capa de acceso de usuarios, bquesquedas, cuadros de mando… Clusters de indexación: Con esta configuración damos alta disponibilidad a la parte de almacenado e indexación de los eventos. Multi Site Cluster: Esta cofiguracion nos permite tener nuestro cluster (del tipo que sea) distribuido varias localizaciones. Cualquier tipo de ellas combinadas   Cluster MultiSite  Algunos nuevos elementos que vamos a necesitar para ello son: Search Head Deployer : esta instancia es la encargada de desplegar las App a los miembros de nuestro SHC y otras configuraciones Index Cluster Master : Desde esta instancia desplegaremos las App a nuestos indexers, además gestiona la replicación ent

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: Standalone : Este s

Después de la anterior entrada,  Visualizaciones Splunk Capitulo 1 , continuo en esta explicando algunos trucos que uso a la hora de realizar cuadros de mando o informes en  Splunk . Algo sencillo pero que en ocasiones suele funcionar muy bien es activar el " dark theme "  Por supuesto podemos usar  visualizaciones externas , creadas por terceros, pero con cuidado de problemas de compatibilidad, actualizaciones... Existen dos fuentes muy buenas, que yo consulto casi a diario, son,  Splunk Base   y el  Blog de Splunk , , Splunk Apps En lo que se refiere a tomar ideas, o incluso saber cómo hacer ciertos indicadores, drilldowns... una app básica que uso desde hace años  Splunk Dashboard Example s Otra App que no es tan veterana, de hecho se encuentra en Beta, pero que esta genial para  hacer Dashboards de forma "más sencilla" es  Splunk Dashboards App (Beta) ,  yo la he usado muy poco, solo para trastear, creo

Una de las grandes bondades de Splunk es la posibilidad de crear cuadros de mando o informes . En algunas ocasiones, como puede ser un POC , con hacer unos simples gráficos de tarta, barras y unas tablas, puede servirnos, para demostrar la potencia de Splunk. Pero en otras ocasiones nos podemos enfrentar grandes a proyectos de visualización de datos, donde se tiene que hilar muy fino en el tipo de gráfico, colores, orden de los gráficos... Nos podemos encontrar con dos perfiles de empresas: Empresas que llevan tiempo trabajando en proyectos similares, y tienen gente con las ideas muy claras, por lo que suele ser mas facil abordar algunas tareas. Empresas que están empezando y además no tienen mucha gente especializada en el campo de la presentación de datos, o no tienen tiempo para dedicarle al proyecto. Si estamos en este segundo caso, desde mi experiencia, yo siempre parto de las siguientes premisas: Personalizar al máximo la apariencia de S

                                                                    Hace ya tiempo hice un   post , sobre los  Data Model , pero me deje una cosa en el tintero, y creo que viene perfecto para poder hacer un post, y explicar uno de los grandes beneficios de los Data Model , la  normalización . Creo que es uno de los puntos clave cuando nos encontramos un entorno con varias fuentes, por ejemplo dos fabricantes distintos de  firewall  (F1 y F2 en este caso) y nuestro  LDAP , nos podemos encontrar diferentes campos con el mismo significado pero diferente nombre, por ejemplo, puede que el campo usuario se llame  user_name  en el F1  user_n  en el F2 y en el LDAP sea  account_name . Todo esto Splunk lo tiene más que pensado, y para ello dispone de una App llamada  CIM , la cual dispone de una estructura de campos bastante grande, donde podemos apoyarnos para esta  normalización , además dispone de una  documentación  bastante completa, donde nos muestra el nombr