- Logstash 1
-¿Como puedo perfeccionar la eficacia de este output y de este Logstash en realidad?
-¿Cuál es la configuración de tópics más eficiente¿ (Actualmente, para las versiones más grandes, nos planteamos la posibilidad de 2 tópics, un grupo de productores y uno de consumidores por cliente).
Aqui puedes encontrar informacion generica sobre esto: Just Enough Kafka for the Elastic Stack, Part 1 | Elastic Blog
- Logstash 2
-¿Cómo podría llevar al máximo a este Logstash para verificar la velocidad a la que es capaz de asimilar logs (obviando su integración con Kafka quizas)?
Utilizando el Generator plugin input y ver hasta que cantidad de mensajes por segundo Logstash puede enviar. Tambien sino creando documentos fakes en Kafka y viendo hasta donde se mantiene de forma buena el pipeline.
-¿Cómo puedo perfeccionar esos plugins de entrada de Kafka?, porque es aquí donde más problemas le veo al SIEM...
Por que ves problemas con esto? No entiendo bien esta consulta
Elasticsearch
Dos dudas:
-¿Cuál sería la configuración optima aquí para rentabilizar al máximo, tanto el tiempo de búsqueda como el almacenamiento, He de encontrar una buena relación de equilibrios en ambas, sobre todo para entornos AllInOne.
-¿Dispondríais de una relación índices-tipos-shards -> velocidad -> tamaño-almacenamiento? A pesar de todo lo que he leído, ando bastante confuso al respecto...
Esto es algo que tienen que probar. Para distintos casos, distinta necesidad de configuracion por shards/indices. Generalmente el default (5/1) NO FUNCIONA correctamente ni es el ideal. Asi que pensando en indexing-rate y query-rate y entendiendo donde estan los shards/indices (en que nodos) pueden entender cuales nodos estan haciendo el trabajo, y que tanto pueden escalar de esa forma.
- Respecto al número de datos agregados.
He leído debido a que no se pueden realizar joins en Elasticsearch, se deben realizar las búsquedas que impliquen varios documentos, (usuarios con mayor número de logins fallidos en todo nuestro sistema) de dos en dos, buscando primero al usuario X en nuestro índices de usuarios, y luego el número de logins que ha realizado. Y que la única forma de aumentar la eficiencia de búsqueda consistiría en añadir campos para evitar realizar este tipo de joins.
-¿Esto como maltrataría el tamaño del índice?
Los joins no funcionan en Elasticsearch. No entiendo porque maltrataria al indice el tamaño si agregas campos. Simplemente como una DB lo que sucederia es que en cuanto mas grandes documentos/datos, mas grande los indices y el disco queopan.
-¿De cuánto coste aproximado estaríamos hablando? es correcto, positivo ( y sobre todo asumible) aumentar el tamaño de los documentos indexados agregando datos de otros documentos para facilitar estas búsquedas multidocumentales?
Esto es correcto, y es un patron generalmente utilizado.
- Respecto a la compresión de los datos indexados.
Cuanto se estima que pueda pesar un índice de unos 100.000 millones de eventos (recogidos durante dos años), indexados por tres o cuatro campos, sin agregaciones de datos y comprimidos con "index.codec: best_compression".
Esta pregunta, se que es difícil de responder con un dato exacto, pero es que ahora mismo no se ni dar un numero estimado.
-¿Se podrían realizar re-indexaciones y re-compresiones para aligerar el índice?
No te podria decir, depende nuevamente del caso y que se este haciendo. Se me es imposible decirte como va a funcionar esto. Tendrian que probarlo. Tenemos un blog tambien a cerca de esto: Store compression in Lucene and Elasticsearch | Elastic Blog. Tambien sobre storage en Elasticsearch: Part 2.0: The true story behind Elasticsearch storage requirements | Elastic Blog. Si bien son blogs viejos, siguen vigentes al dia de hoy.
Espero que esta info te sea de ayuda. Cualquier cosa a las ordenes.
Saludos!
--Gabriel