Unser ursprüngliches Problem
Letztes Jahr hatten wir ein Problem, bei dem eine betrügerische Software auf einem Server unseren zentralen Graylog-Server mit so vielen Nachrichten spammte, dass es Probleme für andere Anwendungen verursachte.
Das Hauptproblem bestand darin, dass ältere, nützliche Nachrichten von anderen Anwendungen früher als üblich gelöscht wurden und der Index mit den nutzlosen Nachrichten der betrügerischen Anwendung aufgefüllt wurde.
Mein Lösungsvorschlag bestand darin, jeder Anwendung einen eigenen Index zuzuweisen, sodass keine Anwendung einer anderen Anwendung den Speicherplatz für Protokolle rauben kann. Dies würde keine Änderungen an den Anwendungen selbst erfordern, sondern nur Änderungen innerhalb von Graylog. Es wurde jedoch nichts unternommen, da eine neue, auf Kubernetes basierende Graylog-Lösung geplant war.
Die Lösung, die uns angeboten wurde
Schneller Vorlauf bis heute: Wir sind gerade dabei, unser Ersatzsystem Graylog in Betrieb zu nehmen.
Anfangs wurde uns gesagt, dass jede Anwendung ihren eigenen unabhängigen Graylog-Server (Load Balancer, Gelf-Endpunkte, Graylog-Knoten, Elastic Search Cluster) und ihre Graylog-Frontend-Website haben würde.
Das Problem besteht darin, dass zwischen den verschiedenen Anwendungen eine komplexe Beziehung besteht und dass die anwendungsübergreifende Suche sehr schwierig werden würde, wenn man für Protokolle aus unterschiedlichen Anwendungen auf unterschiedliche Graylog-Webserver zugreifen müsste (graylog-application1.site für Protokolle von Anwendung1 und graylog-application2.site für Protokolle von Anwendung2, statt einfach auf graylog.site zu gehen).
Die überarbeitete Lösung
Nachdem dies aufgezeigt wurde, wurde eine Lösung vorgeschlagen, bei der die Anwendungen danach gruppiert werden, wie wahrscheinlich es ist, dass sie gemeinsam durchsucht werden müssen. Daher erwarten wir nun, dass uns pro Gruppe separate Graylog-Server zugewiesen werden (application-group-a.site für Anwendung 1 und 3 und application-group-b.site für Anwendung 2, 4 und 5 usw.).
Ich frage mich jedoch, ob dies notwendig oder ausreichend ist.
Dies bedeutet, dass viele wahrscheinlich anwendungsübergreifende Suchvorgänge einfach durchzuführen sein werden. Am schwierigsten zu lösende Supportprobleme sind jedoch solche, die Anwendungsgrenzen überschreiten und weniger offensichtlich sind. Diese Suchvorgänge werden nicht mehr so einfach sein (und können sogar unmöglich sein, wenn Sie nicht wissen, um welche Anwendung es sich handelt).
Manche argumentieren, dass separate Indizes auf einem einzigen zentralen Graylog-Server keine ausreichende Isolierung zwischen Anwendungsgruppen bieten. Sie wollen sicher sein, dass eingehende Nachrichten von einer Anwendung niemals mit eingehenden Nachrichten von anderen Anwendungen in Konflikt geraten können, also wollen sie eine vollständige Isolierung zwischen Gruppen.
Mein Problem dabei ist, dass es nicht helfen würde, wenn eine Anwendung innerhalb einer Gruppe außer Kontrolle gerät und den Graylog-Server der Gruppe mit Spam überflutet. Wenn wir eine Lösung finden, die Denial-of-Service-Angriffe innerhalb einer Gruppe verhindert, hätten wir auch eine Lösung für einen einzelnen zentralisierten Graylog-Dienst.
Ich würde argumentieren, dass die horizontale Skalierung eines einzelnen zentralen Dienstes mit mehr lastausgeglichenen Graylog-Knoten, mehr elastischen Suchknoten, mehr GELF-Endpunkten usw. eine bessere Lösung wäre, als Dutzende von Graylog-Servern zu haben.
Fragen
Würden separate Graylog-Server tatsächlich den Grad an Isolation (Minderung von Denial-of-Service-Angriffen) bieten, den sich die Leute offenbar wünschen, wenn alles auf demselben Kubernetes-Cluster gehostet wird?
Können wir mit einem einzigen zentralen Graylog-Server ein ähnliches oder besseres Maß an Isolation erreichen als mit separaten Graylog-Gruppenservern?
Verwenden andere Organisationen Graylog auf diese Weise, mit vielen Front-End-Websites, oder wäre eine einzige zentrale Website für den Zugriff auf alle Protokolle zu erwarten?
Im Grunde versuche ich entweder, mich selbst davon zu überzeugen, dass ich mir umsonst Sorgen mache und dass diese Lösung weit verbreitet ist. Oder ich versuche, die Leute mit Argumenten davon zu überzeugen, dass unsere Überlegungen im Widerspruch zu bewährten Verfahren stehen und wir es wirklich nicht tun sollten.
Ich würde zwar sehr gerne eine Lösung finden, mit der alle zusammenarbeiten, aber im Moment scheint es mir so, als würden wir mit unserem derzeit vorgeschlagenen Lösungsvorschlag eher das Kind mit dem Bade ausschütten.
Antwort1
Ihre Bedenken und Fragen zur Architektur Ihres Graylog-Setups sind durchaus berechtigt. Es ist wichtig, eine Lösung zu finden, die den Bedarf an Isolation und Ressourcenverwaltung mit Benutzerfreundlichkeit und Verwaltbarkeit in Einklang bringt. Lassen Sie es uns wie Kris Kross aufschlüsseln!
1. Würden separate Graylog-Server tatsächlich den Grad an Isolation (Minderung von Denial-of-Service-Angriffen) bieten, den die Leute sich offenbar wünschen, wenn alles auf demselben Kubernetes-Cluster gehostet wird?
Separate Graylog-Server, die auf demselben Kubernetes-Cluster laufen, können ein gewisses Maß an Isolation bieten, aber es ist wichtig zu verstehen, dass sie immer noch Ressourcen auf Clusterebene teilen, darunter Netzwerkbandbreite, Speicher und möglicherweise CPU und Arbeitsspeicher. Wenn eine Anwendung innerhalb einer Gruppe abtrünnig wird und beginnt, Nachrichten zu spammen, kann dies aufgrund von Ressourcenkonflikten möglicherweise die Leistung anderer Graylog-Server auf demselben Cluster beeinträchtigen. Obwohl Kubernetes Ressourcenverwaltungsfunktionen bietet, ist es kein Allheilmittel zur Vermeidung ressourcenbezogener Probleme.
2. Können wir mit einem einzelnen zentralen Graylog-Server ein ähnliches oder besseres Maß an Isolation erreichen als mit separaten Graylog-Gruppenservern?
Ein einzelner zentraler Graylog-Server kann mithilfe separater Indizes eine Isolierung zwischen Anwendungen gewährleisten, kann aber, wie bereits erwähnt, nicht verhindern, dass eine nicht autorisierte Anwendung den Server überlastet und Probleme für andere Anwendungen verursacht. Um dies zu verhindern, können Sie strengere Richtlinien zur Ratenbegrenzung und Drosselung für die Eingaben oder Quellen implementieren, die Protokollnachrichten generieren. Darüber hinaus können Sie den zentralen Graylog-Server horizontal skalieren, um eine erhöhte Last zu bewältigen, was kostengünstiger sein kann als die Verwaltung mehrerer separater Server.
3. Verwenden andere Organisationen Graylog auf diese Weise, mit vielen Front-End-Websites, oder wäre eine einzige zentrale Website für den Zugriff auf alle Protokolle zu erwarten?
Die Entscheidung, ob mehrere Front-End-Websites für verschiedene Graylog-Instanzen oder eine einzige zentrale Website verwendet werden sollen, hängt von den spezifischen Anforderungen und Präferenzen der Organisation ab. Beide Ansätze sind gültig und haben ihre eigenen Vorteile und Nachteile.
Mehrere Front-End-Websites: Dieser Ansatz eignet sich, wenn verschiedene Teams oder Anwendungen separate Graylog-Instanzen für eine bessere Isolierung, Kontrolle und Organisation benötigen. Dies kann die Zugriffskontrolle vereinfachen und verschiedenen Teams Autonomie verleihen. Allerdings kann es erforderlich sein, dass Benutzer für anwendungsübergreifende Suchvorgänge zwischen verschiedenen Schnittstellen wechseln müssen.
Eine zentrale Website: Eine zentrale Website für den Zugriff auf alle Protokolle bietet eine einheitliche Ansicht der gesamten Protokollinfrastruktur und erleichtert so die anwendungsübergreifende Suche. Dieser Ansatz vereinfacht den Benutzerzugriff, erfordert jedoch möglicherweise eine robustere Zugriffskontrolle und Berechtigungsverwaltung, um die Datentrennung zwischen verschiedenen Teams oder Anwendungen sicherzustellen.
Letztendlich hängt die Wahl zwischen diesen Ansätzen von den Prioritäten Ihres Unternehmens in Bezug auf Isolierung, Benutzerfreundlichkeit, Ressourcenverwaltung und die spezifischen Anforderungen Ihrer Anwendungen und Teams ab.
Um eine ausgewogene Lösung zu finden, die für alle funktioniert, beachten Sie Folgendes:
- Implementieren Sie strenge Richtlinien zur Ratenbegrenzung und Drosselung innerhalb jeder Graylog-Instanz, um zu verhindern, dass betrügerische Anwendungen das System überlasten.
- Überwachen Sie die Ressourcennutzung und Leistung aller Graylog-Instanzen und geben Sie Warnmeldungen aus, um Probleme proaktiv zu erkennen und zu beheben.
- Dokumentieren und kommunizieren Sie Best Practices für die Protokollverwaltung und -nutzung an alle Teams.
- Erkunden Sie weiterhin die Möglichkeit einer zentralisierten Graylog-Lösung mit entsprechender Ressourcenskalierung und Zugriffskontrollmechanismen.
Alles in allem ist eine Kombination der beste Ansatz. Sie verwenden möglicherweise separate Graylog-Instanzen für logische Anwendungsgruppen und implementieren gleichzeitig robuste Ressourcenverwaltungs- und Überwachungspraktiken, um die allgemeine Stabilität Ihrer Protokollverwaltungsinfrastruktur sicherzustellen. Es ist auch wichtig, Stakeholder aus verschiedenen Teams in den Entscheidungsprozess einzubeziehen, um sicherzustellen, dass die gewählte Lösung ihren Anforderungen und Erwartungen entspricht. Nur ein Vorschlag, um wilde Probleme zu vermeiden, wissen Sie? ;)
Antwort2
Der große Vorteil von Graylog (und ähnlichen Produkten) ist nicht die isolierte Speicherung von Protokollen, sondern dieKorrelation zwischen verschiedenen Protokollquellen und aufgezeichneten Ereignissen.Durch die Verwendung mehrerer separater Graylog-Server, die jeweils unterschiedliche Quellen erfassen, wird die Korrelation mehrerer Quellen wesentlich schwieriger.
Ich würde vorschlagen, einen einzelnen Graylog-Server (oder ein Cluster-Setup mit mehreren Knoten, wenn ein einzelner Knoten nicht ausreicht) und mehrere spezifische Indizes mit unterschiedlichen (und geeigneten) Rotationsrichtlinien zu verwenden. Sie können den Verkehr zu diesen Indizes über geeigneteStream-Regeln(und „Übereinstimmungen aus Standard-Stream entfernen“ auswählen).