ELK-RabbitMQ-Architektur – Protokollverwaltung für große IT-Infrastrukturen / Sudo Null IT News

So erstellen Sie mit dem AMQP RabbitMQ-Broker eine fehlertolerante Architektur mit minimalem Verlust von Protokolldaten bei Ausfällen.

Der Verlust von Logs bei der Verwaltung einer großen Infrastruktur eines Hosting-Unternehmens kann zu Image- und finanziellen Einbußen führen. Gleichzeitig weckt eine große Menge an kontrollierter Ausrüstung nicht den Wunsch, Systeme zu erstellen, in denen die Protokolle dupliziert werden und sich in eine riesige und schwer zu verwaltende Informationssammlung verwandeln.

Wir sind im Unternehmen Host-Schlüssel haben das Rad nicht neu erfunden und unser System darauf aufgebaut offeneDistribution. In diesem Artikel werden wir über die Architektur dieser Lösung sprechen, die dank der Verwendung des AMQP RabbitMQ-Brokers Fehlertoleranz und minimalen Verlust von Protokolldaten bei Ausfällen bietet.

Meistens ist das System zum Verarbeiten und Speichern von Protokollen ungefähr nach folgendem Schema organisiert:

Die Anwendung zum Sammeln von Protokollen übergibt sie direkt über das Syslog-Protokoll an die Datenverarbeitungspipeline logstash. Von dort gelangen die Daten in die Datenbank. elastische Suche und weiter vom Datenvisualisierungspanel verwendet Kibana.

Alle ELK-Elemente unterstützen Fehlertoleranz, und das direkte Interaktionsschema ist ziemlich robust. Mit dem Wachstum des Systems ist es jedoch notwendig, die Leistung des Protokollverarbeitungssystems linear zu steigern, da Logstash ein Punkt zum Empfangen von Protokollen und gleichzeitig ein System zum Analysieren dieser Protokolle ist. Bei Bursts in der Anzahl von Nachrichten ist eine lineare Steigerung der Systemleistung erforderlich, dh der Empfänger sollte nicht mit Nachrichten “erstickt” werden, sondern im Gegenteil, er sollte bei einem Ausfall konsistent Informationen liefern, ohne Nachrichten zu verlieren. Dementsprechend ist es notwendig, Ressourcen für die erwarteten Bursts vorab zuzuweisen.

In einem der vorherigen Artikel haben wir darüber gesprochen, wie das Hardware-Management bei Hostkey funktioniert und welche Rolle das Message Broker Cluster (RabbitMQ) in unserer Infrastruktur spielt. Ein Merkmal von RabbitMQ ist die hohe Zuverlässigkeit und die Fähigkeit, große Nachrichtenmengen mit minimalem Ressourcenverbrauch zu verarbeiten. Dies ist möglich, weil Rabbit Nachrichten nicht verarbeitet, sondern nur speichert und zustellt.

Wir entschieden uns, das Verarbeitungssystem zu verfeinern und RabbitMQ als Warteschlangenpuffer hinzuzufügen.

Diese Entscheidung ermöglichte es, die Fehlertoleranz des Systems zu erhöhen: Wenn in einer der Phasen der Verarbeitung und Speicherung von Protokollen etwas schief geht, bleiben sie in Rabbit AMQP. Ein weiterer Vorteil unserer Lösung ist die zusätzliche Variabilität bei der Arbeit mit Protokollen – wir können beispielsweise zusätzliche Analysatoren hinzufügen und ähnliche Aktionen ausführen, um Protokolle zu verwalten und zu verarbeiten.

* Nginx verwenden wir als Proxy für Kibana

Infolgedessen ruft Logstash Informationen aus Ausgabewarteschlangen ab, da es Nachrichten verarbeiten kann. Rabbit spielt hier die Rolle eines Caches, der offensichtlich um ein Vielfaches mehr Informationen aufnehmen kann als Logstash.

Im Notfall können auch einzelne Meldungen über Rabbit eingesehen werden. Darüber hinaus ist die Rabbit-Warteschlange ein Überwachungspunkt, die Anhäufung von Nachrichten in der Warteschlange ist ein direkter Hinweis auf erhebliche (Ausbruch der Anzahl der Protokolle) oder private (ELK-Systemausfall) Probleme in der Infrastruktur.

Logstash-Client-Agent-Konfiguration:

destination d_ampqp {amqp( vhost(“/”) host(“HOST_IP”) port(5672) exchange(“****”) exchange-type(“direct”) routing-key(“****”) body (“$(format-json –scope nv_pairs –pair category=\”infra.ru\” –pair source=$source –pair customendpoint=\” \” –pair tags=\”infra.ru\ “)”) persistent(ja) Benutzername(“”) Passwort(“”) } }

Logstash-Indexer-Agent-Konfiguration:

input { rabbitmq { host => “HOST_IP” queue => “syslog” heartbeat => 30 persistent => true password => “****” user => “****” } } filter { # Ihre Filter hier } Ausgabe { Elasticsearch { Hosts => [”
hosts => ”
manage_template => false
user => “admin”
password => “****”
ssl => false
ssl_certificate_verification => false
index => “%{[@metadata][syslog]}-%{+YYYY.MM.dd}” document_type => “%{[@metadata][type]}” } }

System-Clients

Nachdem wir die allgemeine Idee betrachtet haben, gehen wir zur Implementierung über. Zunächst haben wir die Clients des Protokollerfassungssystems in vertrauenswürdige und nicht vertrauenswürdige Clients unterteilt. Vertrauenswürdige Anwendungen / Hosts haben die Möglichkeit, sich anzumelden und in die Nachrichtenwarteschlange zu schreiben (direkt oder über einen Vermittler, auf den wir später noch eingehen werden). Nicht vertrauenswürdig – Anwendungen, die keinen direkten Zugriff auf RabbitMQ haben.

Lassen Sie es uns anhand eines Beispiels erklären:

  • Ein vertrauenswürdiger Client ist der Standardinfrastrukturhost eines Unternehmens.

  • Ein nicht vertrauenswürdiger Client ist eine LiveCD, die das Betriebssystem auf dem Client-Host installiert (der Client kann möglicherweise den Prozess stören und Zugriff auf die RabbitMQ-Infrastruktur erhalten).

Als nächstes musste das Problem eines transparenten (für Anwendungen) Übergangs vom Syslog-Protokoll zu AMQP gelöst werden. syslog-ng eignet sich hervorragend zum Konvertieren von Syslog-Datenverkehr in AMQP. Unsere Hauptbetriebssysteme, die in der Infrastruktur verwendet werden, sind CentOS7 und 8. Für die siebte Version des Betriebssystems müssen Sie ein Paket mit einer neuen Version des Servers erstellen, da die Version aus dem regulären Repository AMQP nicht unterstützt. Bei der Acht gibt es solche Probleme nicht. Als nächstes müssen Sie bei (vertrauenswürdigen) Infrastrukturinstallationen das Standard-rsyslog durch syslog-ng ersetzen und die Interaktion mit dem Rabbit-Cluster konfigurieren:

destination d_ampqp { amqp( vhost(“/”) host(“AMQP_HOST”) port(5672) exchange(“eventtask”) exchange-type(“direct”) routing-key(“eventtask”) body(“$(format- json –scope core)”) persistent(yes) username(“RABBIT_USERNAME”) password(“RABBIT_PASSWORD”) ); };

Für nicht vertrauenswürdige Hosts oder Hosts, auf denen syslog-ng nicht installiert werden kann, ist ein externer syslog-ng-Listener erforderlich.

Wir haben uns entschieden, einen solchen Listener direkt auf den RabbitMQ-Hosts zu platzieren, um unnötigen Dienstverkehr zu minimieren, aber dies ist keine Regel – eine Gruppe von Syslog-ng-Hosts kann durchaus getrennt vom Broker arbeiten. Wir haben die Anzahl der Empfänger gleich der Anzahl der Hosts des Rabbit-Clusters gemacht, die Auswahl des Hosts erfolgt über DNS-RoundRobin. Ein solches Schema hat den Nachteil eines möglichen Nachrichtenverlusts, wenn einer der Hosts ausfällt. Dieses Problem lässt sich ganz einfach lösen, indem die Empfänger-Hosts über ein Pacemaker/Corosync-Bundle auf eine geclusterte IP verschoben werden (dies ist ein einfach zu verwendender Mechanismus, über den wir in einem separaten Artikel sprechen können).

Vorteile des endgültigen Systems:

  • Fehlertoleranz – Das System ist in der Lage, große Nachrichtenströme verlustfrei zu verarbeiten und widersteht dem Ausfall eines einzelnen Hosts, der den Dienst bereitstellt.

  • Flexibilität – die Systemleistung lässt sich leicht steigern, das System kann Nachrichten von jedem Syslog-Client empfangen: von fortgeschritten (syslog-ng) bis zu den konservativsten (Microsoft usw.).

  • Rentabilität – Das System ermöglicht es Ihnen, keine überschüssigen Ressourcen für die Verarbeitung von Protokollen bereitzustellen. “Sturm” von Nachrichten führt nicht zu deren Verlust.

BEI unser Blog auf hostkey.ru finden Sie weitere interessante Publikationen.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *