Buenos días, pruebo a postear en Castellano porque las dudas que tengo ahora son mucho más abstractas y desconfío de mi capacidad de expresión en inglés.
Necesito contestarme a unas ciertas dudas que tengo acerca del comportamiento de un par cosas. ¿Podríais ayudarme por favor?
Logstash-Kafka-Logstash.
-
Logstash 1
Para las maquinas que no permitan la comunicación con Kafka tengo un Logstash que realiza esta comunicación, esto funciona perfectamente. Envía a una buena velocidad, y se traga los picos con relativa tranquilidad.-¿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). -
Logstash 2
El segundo Logstash, es quien realizaría todos los mapeos y tendría RAM y procesador de sobra, pero tarda muchísimo en consumir los eventos almacenados en Kafka, incluso sin llevar acabo ningún mapeo ni filtro.
He modificado el input, optando como hizo LinkedIn por el plugin pipe con el comando del consumidor de Kafka, y subiendo el autocommit a 1 minuto para que suba su rendimiento, pero incluso con recursos de sobra, no va al ritmo que desearía... y deja demasiados eventos en Kafka.-¿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)?
-¿Cómo puedo perfeccionar esos plugins de entrada de Kafka?, porque es aquí donde más problemas le veo al SIEM...
Elasticsearch
El clúster con el que estoy practicando dispone de tres nodos maestros, tres de datos, y dos de cliente (para redundar Kibana). Funciona perfecto todo, pero tengo varias dudas al respecto:
- Respecto al número de índices, tipos, shards y replicas.
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...
- 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?
-¿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?
- 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? (Pero tienen que seguir pudiéndose realizar búsquedas sobre estos datos, aunque sean más costosas).
y no puedo aceptar ese comportamiento de forma habitual, porque para eso, enchufo directamente con los beats a Elasticsearch y los flujos por logstash y aborto kafka... pero no me gustaría perder Kafka...
