Nuestro problema original
El año pasado tuvimos un problema en el que un software malicioso en un servidor enviaba spam a nuestro servidor Graylog central con tantos mensajes que causaba problemas a otras aplicaciones.
El principal problema era que los mensajes útiles más antiguos de otras aplicaciones se eliminaban antes de lo normal y el índice se llenaba con mensajes inútiles de la aplicación maliciosa.
Mi solución sugerida fue darle a cada aplicación su propio índice, de modo que ninguna aplicación pudiera privar a otra aplicación de espacio de almacenamiento de registros. Esto no necesitaría ningún cambio en las aplicaciones en sí y solo requeriría cambios dentro de Graylog. Sin embargo, no se hizo nada, ya que se estaba planificando una nueva solución Graylog basada en Kubernetes.
La solución que nos ofrecieron.
Un avance rápido hasta ahora, y ahora estamos en el proceso de poner en funcionamiento nuestro sistema Graylog de reemplazo.
Inicialmente, nos dijeron que cada aplicación tendría su propio servidor Graylog independiente (equilibrador de carga, puntos finales gelf, nodos Graylog, clúster de búsqueda elástica) y un sitio web frontal de Graylog.
El problema es que existe una relación compleja entre diferentes aplicaciones y tener que ir a diferentes servidores web de Graylog para obtener registros de diferentes aplicaciones (graylog-application1.site para registros de la aplicación1 y graylog-application2.site para registros de la aplicación2, en lugar de que simplemente ir a graylog.site) iba a hacer que las búsquedas entre aplicaciones fueran realmente difíciles.
La solución revisada
Después de señalar esto, se propuso una solución para agrupar aplicaciones según la probabilidad de que sea necesario buscarlas juntas, por lo que ahora esperamos tener servidores Graylog separados por grupo (grupo-aplicación-a.sitio para la aplicación). 1 y 3, y application-group-b.site para las aplicaciones 2, 4 y 5, etc.).
Pero me pregunto si esto es necesario o suficiente.
Significará que muchas búsquedas probables entre aplicaciones serán fáciles de realizar, pero algunos de los problemas de soporte más difíciles de resolver son aquellos que cruzan los límites de las aplicaciones que son menos obvios, y estas búsquedas ya no serán tan fáciles (y de hecho pueden imposible si no se sabe de qué aplicación se trata).
Se ha argumentado que el simple hecho de tener índices separados en un único servidor central de Graylog no proporciona suficiente aislamiento entre los grupos de aplicaciones. Quieren estar seguros de que la entrada de mensajes de una aplicación nunca pueda interferir con la entrada de mensajes de otras aplicaciones, por lo que quieren un aislamiento completo entre grupos.
Mi problema con esto es que no ayudaría si una aplicación dentro de un grupo se vuelve deshonesta y envía spam al servidor Graylog del grupo. Si podemos encontrar una solución que evite la denegación de servicio dentro de un grupo, también tendríamos una solución para un único servicio Graylog centralizado.
Yo diría que escalar un único servicio central horizontalmente con nodos Graylog con carga más equilibrada, nodos de búsqueda más elásticos, más puntos finales GELF, etc., sería una mejor solución que tener docenas de servidores Graylog.
Preguntas
¿Los servidores Graylog separados realmente proporcionarían el nivel de aislamiento (mitigación de denegación de servicio) que la gente parece querer, cuando todo está alojado en el mismo clúster de Kubernetes?
¿Podemos proporcionar un nivel de aislamiento similar o mejor con un único servidor Graylog central que con servidores Graylog de grupos separados?
¿Usan otras organizaciones Graylog de esta manera, con muchos sitios web front-end, o se esperaría un único sitio web central para acceder a todos los registros?
Básicamente, busco convencerme de que no me preocupo por nada y de que esta solución es común; o argumentos para convencer a la gente de que lo que estamos considerando es contrario a las mejores prácticas y que realmente no deberíamos estar haciendo esto.
Realmente me gustaría encontrar una solución que funcione para todos, pero en este momento me parece que con la solución que proponemos actualmente preferimos tirar el bebé junto con el agua de la bañera.
Respuesta1
Sus inquietudes y preguntas sobre la arquitectura de su configuración Graylog son bastante válidas. Es importante encontrar una solución que equilibre la necesidad de aislamiento y gestión de recursos con facilidad de uso y capacidad de gestión. ¡Vamos a analizarlo como Kris Kross!
1. ¿Los servidores Graylog separados realmente proporcionarían el nivel de aislamiento (mitigación de denegación de servicio) que la gente parece querer, cuando todo está alojado en el mismo clúster de Kubernetes?
Los servidores Graylog separados que se ejecutan en el mismo clúster de Kubernetes pueden proporcionar cierto nivel de aislamiento, pero es importante comprender que todavía comparten recursos a nivel del clúster, incluido el ancho de banda de la red, el almacenamiento y, potencialmente, la CPU y la memoria. Si una aplicación dentro de un grupo se vuelve deshonesta y comienza a enviar mensajes no deseados, puede afectar potencialmente el rendimiento de otros servidores Graylog en el mismo clúster debido a la contención de recursos. Si bien Kubernetes ofrece capacidades de gestión de recursos, no es una solución milagrosa para prevenir problemas relacionados con los recursos.
2. ¿Podemos proporcionar un nivel de aislamiento similar o mejor con un único servidor Graylog central que con servidores Graylog de grupos separados?
Un único servidor Graylog central puede proporcionar aislamiento entre aplicaciones utilizando índices separados, pero como mencionó, es posible que no evite que una aplicación no autorizada sobrecargue el servidor y cause problemas a otras aplicaciones. Para mitigar esto, puede considerar implementar políticas de limitación y aceleración de velocidad más estrictas en las entradas o fuentes que generan mensajes de registro. Además, puede escalar el servidor Graylog central horizontalmente para manejar una mayor carga, lo que puede ser más rentable que administrar varios servidores separados.
3. ¿Usan otras organizaciones Graylog de esta manera, con muchos sitios web front-end, o se esperaría un único sitio web central para acceder a todos los registros?
La elección de tener varios sitios web front-end para diferentes instancias de Graylog o un único sitio web central depende de las necesidades y preferencias específicas de la organización. Ambos enfoques son válidos y tienen sus propias ventajas y compensaciones.
Múltiples sitios web front-end: este enfoque es adecuado cuando diferentes equipos o aplicaciones requieren instancias Graylog separadas para un mejor aislamiento, control y organización. Puede simplificar el control de acceso y proporcionar autonomía a diferentes equipos. Sin embargo, puede requerir que los usuarios cambien entre diferentes interfaces para realizar búsquedas entre aplicaciones.
Sitio web central único: un sitio web central único para acceder a todos los registros proporciona una vista unificada de toda la infraestructura de registros, lo que facilita las búsquedas entre aplicaciones. Este enfoque simplifica el acceso de los usuarios, pero puede requerir un control de acceso y una gestión de permisos más sólidos para garantizar la separación de datos entre diferentes equipos o aplicaciones.
En última instancia, la elección entre estos enfoques depende de las prioridades de su organización con respecto al aislamiento, la facilidad de uso, la gestión de recursos y los requisitos específicos de sus aplicaciones y equipos.
Para encontrar una solución equilibrada que funcione para todos, considere lo siguiente:
- Implemente políticas estrictas de limitación y aceleración de velocidad dentro de cada instancia de Graylog para evitar que aplicaciones no autorizadas abrumen el sistema.
- Supervise y alerte sobre el uso y el rendimiento de los recursos en todas las instancias de Graylog para detectar y abordar problemas de forma proactiva.
- Documente y comunique las mejores prácticas para la gestión y el uso de registros a todos los equipos.
- Continúe explorando la posibilidad de una solución Graylog centralizada con mecanismos adecuados de control de acceso y escalamiento de recursos.
Considerándolo todo, el mejor enfoque puede implicar una combinación. Es posible que se encuentre utilizando instancias de Graylog separadas para grupos lógicos de aplicaciones mientras implementa prácticas sólidas de administración y monitoreo de recursos para garantizar la estabilidad general de su infraestructura de administración de registros. También es importante involucrar a las partes interesadas de diferentes equipos en el proceso de toma de decisiones para garantizar que la solución elegida se alinee con sus necesidades y expectativas, solo una sugerencia para evitar problemas, ¿sabes? ;)
Respuesta2
La gran ventaja que ofrece Graylog (y productos similares) no es el almacenamiento de registros de forma aislada, sino lacorrelación entre diferentes fuentes de registros y eventos registrados.Al utilizar varios servidores Graylog independientes, cada uno de los cuales recopila fuentes diferentes, la correlación entre fuentes múltiples se vuelve mucho más difícil.
Sugeriría usar un único servidor Graylog (o una configuración de múltiples nodos en clúster, si un solo nodo no es suficiente) y múltiples índices específicos, con políticas de rotación diferentes (y apropiadas). Puede enrutar el tráfico a estos índices a través deReglas de transmisión(y seleccionando "Eliminar coincidencias de la transmisión predeterminada").