Hola Alberto! La respuesta a esta pregunta da para escribir un libro :). Voy a intentar tocar brevemente algunos puntos que creo que pueden ser clave:
No intentes añadir todas las fuentes de datos desde el principio. Mi impresión por el mensaje es que vais a comenzar a usar el stack de Elastic ahora, por lo que imagino que no tenéis mucha experiencia todavía. Lo ideal es que empieces con una de las fuentes de datos a modo de POC, para que os familiaricéis con el stack, cómo procesar la información... Una de las ventajas del stack es que es fácil escalar, así que lo más sencillo es empezar por una fuente de datos, "dominarla" y entender mejor el stack a través de la práctica, y entonces comenzar a añadir las demás - posiblemente añadiendo en el proceso más máquinas para adecuar el cluster al tamaño del proyecto.
Capacity planning: por lo que entiendo, este proyecto va a manejar una gran cantidad de datos. Es importante evaluar cual es el tamaño ideal de shard para el cual los tiempos de búsqueda e indexación están dentro de las expectativas. Con ese tamaño, puedes decidir cuantos nodos necesitas en tu cluster, etc.
Un tema a considerar aquí es que los logs son de naturaleza temporal, i.e, día a día. En este caso, si la decisión en el tamaño de los shards no fuese la adecuada, simplemente lo cambiamos para los siguientes días. Este blog contiene buen material respecto a shards, etc.
Políticas de retención. Es importante mantener una política de retención estricta - la cantidad de datos no puede crecer indefinidamente. Esto se puede automatizar con Curator.
Arquitecturas hot-warm. Cuando tenemos un proyecto que va a manejar muchos datos de naturaleza temporal es típico que los datos más recientes sean los más utilizados, mientras que los menos recientes son más bien históricos - no se actualizan, no se consultan habitualmente. En este sentido es típico tener máquinas con discos rápidos para los datos frescos, y máquinas con discos más lentos pero con mayor capacidad de almacenamiento para los datos antiguos; por ejemplo, mantener en máquinas que responden rápido 3 días de datos, y en máquinas que responden más lento 3 meses.
Procesado de datos. Aquí entran en juego los diferentes tipos de datos que tienes como origen. Si los datos no necesitan procesamiento (o no necesitan procesamiento complejo), es habitual usar Beats, que son aplicaciones stand-alone escritas en Go. Si se requiere algún procesado extra, Logstash puede ser usado (con o sin Beats), ya que nos va a permitir realizar procesado de la información (por ejemplo, separar líneas de logs en campos, etc). Otra alternativa cuando requerimos algún tipo de procesado es utilizar Ingest nodes.
Como ves, es un tema muy amplio :D. Espero que estos puntos te sirvan para comenzar un proyecto exitoso! Como decía, empieza con un POC pequeño, y luego ya es más sencillo adaptar la arquitectura a hot-warm si es necesario, etc.