SEAL SIEM Monster – Hauptkomponenten ELK (Elasticsearch, Logstash, Kibana)

vPierre Automation, AWS (Amazon Web Services), Cloud, Cloud Computing, Compliance, DevOps, DevSecOps, Microsoft Azure, SEAL Kit, SEAL SIEM Monster, Sicherheit / Security, vSphere

ELK STACK

 

Was ist der ELK Stack?

Der ELK Stack ist eine Sammlung von drei Open-Source-Produkten – Elasticsearch, Logstash und Kibana -, die alle von Elastic entwickelt, verwaltet und organisiert werden. Elasticsearch ist eine NoSQL-Datenbank, die auf der Lucene-Suchmaschine basiert. Logstash ist ein Protokoll-Pipeline-Tool, das Eingaben aus verschiedenen Quellen akzeptiert, verschiedene Transformationen ausführt und die Daten in verschiedene Ziele exportiert. Kibana ist eine Visualisierungsebene, die auf Elasticsearch basiert.

Der Stack enthält auch eine Familie von Protokollversendern, die als Beats bezeichnet wird. Daher hat Elastic ELK in Elastic Stack umbenannt.

Zusammen werden diese verschiedenen Open-Source-Produkte am häufigsten für die zentrale Protokollierung in IT-Umgebungen verwendet (obwohl es viele weitere Anwendungsfälle für den ELK-Stack gibt, einschließlich Business Intelligence, Sicherheit und Compliance sowie Webanalyse). Logstash sammelt und analysiert die Protokolle, dann indiziert Elasticsearch die Informationen und speichert sie. Kibana präsentiert die Daten dann in Visualisierungen, die umsetzbare Einblicke in die eigene Umgebung bieten.

 

Warum ist ELK so beliebt?

Der ELK-Stack ist beliebt, da er eine Anforderung im Bereich der Log-Analyse erfüllt. Splunk’s Unternehmenssoftware ist seit langem Marktführer, aber seine zahlreichen Funktionen sind den teuren Preis immer weniger wert – insbesondere für kleinere Unternehmen wie SaaS-Unternehmen und Tech-Startups.

Aus diesem Grund hat Splunk die zuvor erwähnte geringe Anzahl von Kunden, während ELK in einem Monat öfter heruntergeladen wird, als Splunk Kunden hat – und das um ein Vielfaches. ELK verfügt möglicherweise nicht über alle Funktionen von Splunk, benötigt jedoch auch nicht diese analytischen Glocken und Trillerpfeifen. ELK ist eine einfache, aber robuste Protokollanalyseplattform, die einen Bruchteil des Preises kostet.

Das größere Bild: IT-Organisationen bevorzugen seit langem generell Open-Source-Produkte. Aus diesem Grund könnten neuere proprietäre Software-Plattformen für die Protokollanalyse wie Sumo Logic, die nur 1000 Kunden selbst meldet, heutzutage Schwierigkeiten haben, sich zu etablieren.

Wie überwachen Netflix, Facebook, Microsoft, LinkedIn und Cisco ihre Protokolle? Mit ELK.

Warum wird die Loganalyse immer wichtiger?

Da sich immer mehr IT-Infrastrukturen in öffentliche Clouds wie Amazon Web Services, Microsoft Azure und Google Cloud verlagern, werden Public-Cloud-Sicherheitstools und Protokollierungsplattformen immer wichtiger.

In Cloud-basierten Infrastrukturen ist die Isolation der Leistung äußerst schwierig – insbesondere, wenn Systeme stark ausgelastet sind. Die Leistung von virtuellen Maschinen in der Cloud kann abhängig von den spezifischen Lasten, Infrastrukturservern, Umgebungen und der Anzahl der aktiven Benutzer stark schwanken. Infolgedessen können Zuverlässigkeit und Knotenfehler zu erheblichen Problemen werden.

Protokollverwaltungsplattformen können alle diese Infrastrukturprobleme überwachen sowie Betriebssystemprotokolle, NGINX– und IIS-Serverprotokolle für technische SEO- und Web-Traffic-Analyse, Anwendungsprotokolle und ELB- und S3-Protokolle in AWS verarbeiten.

In all diesen Kontexten können DevOps-Ingenieure, Systemadministratoren, Seiten-Zuverlässigkeitsingenieure und Entwickler alle Protokolle verwenden, um bessere Entscheidungen zu treffen, die auf Daten beruhen (und nicht, wie Adam Mosseri von Facebook sagt, „datengesteuert“). Denn „Big Data Analytics“ wird aus verschiedenen Gründen immer wichtiger – vor allem in Bezug auf die Cloud.

„Der zukünftige Zustand von Big Data wird eine Mischung aus lokalen und Cloud-Umgebungen sein“, sagte Brian Hopkins, Analyst bei Forrester Research, gegenüber Computer World. Hier nur einige Beispiele aus dieser Analyse:

  • Hadoop, ein Framework für die Verarbeitung extrem großer Datenmengen, arbeitet jetzt in der Cloud und nicht nur auf physischen Maschinen
  • Intuit hat sich in Richtung Cloud Analytics entwickelt, da es eine „sichere, stabile und überprüfbare Umgebung“ benötigt.
  • Durch die günstigere Rechenleistung können Ingenieure Algorithmen zum maschinellen Lernen entwickeln, die prädiktive Analysen in der Cloud durchführen

So verwenden Sie den ELK-Stack für die Protokollanalyse

Wie ich bereits erwähnt habe, wird der ELK-Stack am häufigsten für die zentrale Protokollierung verwendet. Die Implementierung und Wartung eines ELK-Stacks in Produktionsqualität erfordert jedoch viel zusätzlichen Aufwand und viele zusätzliche Produkte. Weitere Informationen zum Installieren und Bereitstellen von ELK finden Sie in einem anderen Abschnitt dieses Handbuchs.

ELK-Stack-Architektur

Die verschiedenen Komponenten des ELK-Stacks wurden so konzipiert, dass sie ohne zu viele Konfigurationen gut miteinander interagieren und zusammen spielen können. Wie Sie am Ende jedoch den Stack erstellen, hängt stark von der Umgebung und dem jeweiligen Anwendungsfall ab. Für eine kleine Entwicklungsumgebung sieht die klassische Architektur folgendermaßen aus:

Um jedoch komplexere Pipelines für die Verarbeitung großer Datenmengen in der Produktion handhaben zu können, werden Ihrer Protokollierungsarchitektur wahrscheinlich zusätzliche Komponenten hinzugefügt, um die Ausfallsicherheit (Kafka, RabbitMQ (in SEAL SIEM Monster und Redis verwendet)) und Sicherheit (nginx) zu gewährleisten:

 

ELK IN DER PRODUKTION

 

Die Protokollverwaltung ist für jedes Unternehmen ein Muss, um Probleme zu lösen und um sicherzustellen, dass Anwendungen ordnungsgemäß ausgeführt werden. Daher ist die Protokollverwaltung im Wesentlichen zu einem unternehmenskritischen System geworden.

Wenn Sie ein Produktionsproblem beheben oder versuchen, ein Sicherheitsrisiko zu ermitteln, muss das System rund um die Uhr laufen. Andernfalls können Sie auftretende Probleme nicht beheben oder lösen. Dies kann zu Leistungseinbußen, Ausfallzeiten oder Sicherheitsverletzungen führen. Ein Protokollanalysesystem, das kontinuierlich ausgeführt wird, kann Ihr Unternehmen mit den Mitteln ausstatten, die spezifischen Probleme zu ermitteln und zu lokalisieren, die in Ihrem System Verwüstungen verursachen.

In diesem Artikel werde ich unsere Erfahrungen beim Bau von Logz.io teilen. Ich werde einige der Herausforderungen vorstellen und einige verwandte Richtlinien beim Aufbau einer ELK-Bereitstellung in Produktionsqualität anbieten.

  1. Im Allgemeinen muss eine ELK-Implementierung für die Produktion Folgendes tun: Speichern und indizieren aller empfangenen Protokolldateien (klingt offensichtlich, richtig?)
  2. Betrieb, wenn das Produktionssystem überlastet ist oder sogar ausfällt (da in diesem Moment die meisten Probleme auftreten)
  3. Schutz der Protokolldaten vor unbefugtem Zugriff
  4. Verwaltbare Ansätze für Datenaufbewahrungsrichtlinien, Upgrades und mehr bieten

Wie kann das erreicht werden?

Protokolldaten nicht verlieren

Wenn Sie ein Problem beheben und eine Reihe von Ereignissen durchgehen, braucht es nur eine fehlende Logline, um falsche Ergebnisse zu erhalten. Jedes Protokollereignis muss erfasst werden. Beispielsweise zeigen Sie eine Reihe von Ereignissen in MySQL an, die mit einer Datenbankausnahme enden. Wenn Sie eines dieser Ereignisse verlieren, kann es unmöglich sein, die Ursache des Problems zu ermitteln.

Die empfohlene Methode zur Sicherstellung einer ausfallsicheren Datenpipeline ist das Platzieren eines Puffers vor Logstash, der als Einstiegspunkt für alle Protokollereignisse dient, die an Ihr System gesendet werden. Anschließend werden die Daten zwischengespeichert, bis die Downstream-Komponenten über genügend Ressourcen zum Indizieren verfügen.

Übliche Puffer sind Redis oder Kafka, obwohl in diesem Zusammenhang auch RabbitMQ verwendet werden kann.

Elasticsearch ist der Motor im Herzen von ELK. Das Laden ist sehr anfällig, was bedeutet, dass Sie beim Indizieren und Erhöhen Ihrer Dokumentenmenge äußerst vorsichtig sein müssen. Wenn Elasticsearch beschäftigt ist, arbeitet Logstash langsamer als normal – hier kommt Ihr Puffer ins Spiel und sammelt mehr Dokumente, die dann an Elasticsearch übertragen werden können. Dies ist wichtig, um Protokollereignisse nicht zu verlieren.

Logstash-/Elasticsearch-Ausnahmen überwachen

Logstash schlägt möglicherweise fehl, wenn versucht wird, Protokolle in Elasticsearch zu indizieren, die nicht in das automatisch generierte Mapping passen.

Angenommen, Sie haben einen Protokolleintrag, der wie folgt aussieht:

1 timestamp=time,type=my_app,error=3,….

Später generiert Ihr System jedoch ein ähnliches Protokoll, das wie folgt aussieht:

1 timestamp=time,type=my_app,error=”Error”….

Im ersten Fall wird für das Fehlerfeldeine Nummer verwendet. Im zweiten Fall wird eine Zeichenfolge verwendet. Infolgedessen wird das Dokument von Elasticsearch NICHT indiziert. Es wird lediglich eine Fehlernachricht zurückgegeben, und das Protokoll wird gelöscht.

Um sicherzustellen, dass solche Protokolle noch indiziert sind, müssen Sie:

  1. 32. Mit Entwicklern zusammenarbeiten, um sicherzustellen, dass die Protokollformate konsistent bleiben. Wenn eine Änderung des Protokollschemas erforderlich ist, ändern Sie einfach den Index entsprechend dem Protokolltyp.
  2. Stellen Sie sicher, dass Logstash konsistent mit Informationen versorgt wird, und überwachen Sie die Ausnahmen von Elasticsearch, um sicherzustellen, dass Protokolle nicht in den falschen Formaten versandt werden. Die Verwendung eines festen und weniger dynamischen Mappings ist hier wahrscheinlich die einzige solide Lösung (Sie müssen nicht mit dem Coden beginnen).

Bei Logz.io lösen wir dieses Problem, indem wir eine Pipeline erstellen, um Mapping-Ausnahmen zu behandeln, die diese Dokumente schließlich auf eine Weise indizieren, die nicht mit der vorhandenen Mapping kollidiert.

Hinken Sie Wachstum und Ausbrüchen nicht hinterher

Wenn Ihr Unternehmen erfolgreich ist und wächst, werden es auch Ihre Daten. Maschinen häufen sich an, Umgebungen variieren und Protokolldateien folgen. Beim Skalieren mit mehr Produkten, Anwendungen, Funktionen, Entwicklern und Vorgängen sammeln Sie auch mehr Protokolle an. Dies erfordert eine gewisse Menge an Rechenressourcen und Speicherkapazität, damit Ihr System alle verarbeiten kann.

Im Allgemeinen benötigen Protokollverwaltungslösungen große Mengen an CPU, Speicher und Speicherplatz. Log-Systeme sind von Natur aus manchmal aus allen Nähten platzend, und sporadische Stöße sind typisch. Wenn eine Datei aus Ihrer Datenbank gelöscht wird, kann die Häufigkeit der Protokolle, die Sie erhalten, 100 bis 200 bis gar 100.000 Protokolle pro Sekunde betragen.

Daher müssen Sie bis zu zehnmal mehr Kapazität als normal zuweisen. Wenn es ein echtes Produktionsproblem gibt, melden viele Systeme im Allgemeinen Fehler oder Verbindungsabbrüche, was dazu führt, dass viel mehr Protokolle erstellt werden. Dies ist tatsächlich der Fall, wenn Protokollverwaltungssysteme mehr denn je benötigt werden.

ELK-ELASTIZITÄT

Eine der größten Herausforderungen beim Aufbau einer ELK-Bereitstellung ist die Skalierbarkeit.

Nehmen wir an, Sie haben eine E-Commerce-Site und erleben in einer bestimmten Jahreszeit eine zunehmende Anzahl eingehender Protokolldateien. Um sicherzustellen, dass dieser Zufluss von Protokolldaten nicht zu einem Engpass wird, müssen Sie sicherstellen, dass sich Ihre Umgebung problemlos skalieren lässt. Dazu müssen Sie an allen Fronten skalieren – von Redis (oder Kafka) über Logstash bis hin zu Elasticsearch – was in mehrfacher Hinsicht eine Herausforderung darstellt.

Unabhängig davon, wo Sie Ihren ELK-Stack einsetzen, sei es auf AWS, GCP oder in Ihrem eigenen Rechenzentrum. Wir empfehlen, einen Cluster von Elasticsearch-Knoten zu haben, die in verschiedenen Verfügbarkeitszonen oder in verschiedenen Segmenten eines Rechenzentrums mit hoher Verfügbarkeit laufen.

Schauen wir uns einige der Komponenten an, die für eine skalierbare ELK-Bereitstellung erforderlich sind.

Optional Kafka

Wie oben erwähnt, ist das Ablegen eines Puffers vor dem Indexierungsmechanismus für die Behandlung unerwarteter Ereignisse von entscheidender Bedeutung. Es können Konflikte, Aktualisierungsprobleme, Hardwareprobleme oder plötzliche Erhöhungen des Protokollvolumens auftreten. Was auch immer die Ursache ist, Sie benötigen einen Überlaufmechanismus, und hier kommt Kafka ins Spiel.

Kafka fungiert als Puffer für zu indizierende Protokolle und muss Ihre Protokolle in mindestens 2 Replikaten aufbewahren. Ihre Daten (auch wenn sie bereits von Logstash verwendet wurden) müssen mindestens 1-2 Tage aufbewahrt werden.

Dies widerspricht der Planung des lokalen Speichers, der für Kafka verfügbar ist, sowie der Netzbandbreite, die den Kafka-Maklern zur Verfügung gestellt wird. Denken Sie daran, große Spitzen im ankommenden Protokollverkehr zu berücksichtigen (zehnmal häufiger als „normal“), da in diesen Fällen Ihre Protokolle am dringendsten benötigt werden.

Überlegen Sie sich, wie viel Arbeitskräfte Sie für die Behebung von Problemen in Ihrer Infrastruktur einsetzen müssen, wenn Sie die Aufbewahrungskapazität in Kafka planen.

Ein weiterer wichtiger Aspekt ist der ZooKeeper-Verwaltungscluster – er hat seine eigenen Anforderungen. Übersehen Sie nicht die Festplatten-Leistungsanforderungen für ZooKeeper sowie die Verfügbarkeit dieses Clusters. Verwenden Sie einen Cluster mit drei oder fünf Knoten, der sich auf Racks/Verfügbarkeitszonen (aber keine Regionen) erstreckt.

Eines der wichtigsten Dinge an Kafka ist das darauf implementierte Monitoring. Sie sollten Ihren Protokollverbrauch (auch als „Lag“ bezeichnet) immer in Bezug auf die Zeit betrachten, die von der Veröffentlichung einer Protokollnachricht an Kafka bis zur Indexierung in Elasticsearch und zur Suche zur Verfügung steht.

Kafka bietet außerdem eine Fülle von operativen Metriken, von denen einige für die Überwachung äußerst wichtig sind: Netzbandbreite, Thread-Leerlauf-Prozentsatz, unterreplizierte Partitionen und mehr. Wenn Sie den Konsum von Kafka und die Indizierung in Betracht ziehen, sollten Sie überlegen, welchen Grad an Parallelität Sie implementieren müssen (schließlich ist Logstash nicht sehr schnell). Dies ist wichtig, um das Verbrauchsparadigma zu verstehen und die Anzahl der Partitionen, die Sie in Ihren Kafka-Themen verwenden, entsprechend zu planen.

Logstash

Zu wissen, wie viele Logstash-Instanzen ausgeführt werden müssen, ist eine Kunst für sich. Die Antwort hängt von vielen Faktoren ab: Datenmenge, Anzahl der Pipelines, Größe des Elasticsearch-Clusters, Puffergröße, akzeptierte Latenzzeit – um nur einige zu nennen.
Stellen Sie einen skalierbaren Warteschlangenmechanismus mit verschiedenen skalierbaren Mitarbeitern bereit. Wenn eine Warteschlange zu beschäftigt ist, skalieren Sie zusätzliche Mitarbeiter, um sie in Elasticsearch einzulesen.
Wenn Sie die Anzahl der erforderlichen Logstash-Instanzen ermittelt haben, führen Sie jede davon in einem anderen AZ (unter AWS) aus. Dies ist aufgrund der Datenübertragung mit Kosten verbunden, garantiert jedoch eine widerstandsfähigere Datenpipeline.
Sie sollten Logstash und Elasticsearch auch voneinander trennen, indem Sie verschiedene Maschinen dafür verwenden. Dies ist kritisch, da beide als JVMs ausgeführt werden und sehr viel Speicher verbrauchen, sodass sie nicht effektiv auf derselben Maschine ausgeführt werden können.
Die Hardwarespezifikationen variieren, es wird jedoch empfohlen, für jeden Computer maximal 30 GB oder die Hälfte des Speichers für Logstash zu reservieren. In einigen Szenarien ist es jedoch auch empfehlenswert, Platz für Caches und Puffer zu schaffen.

Elasticsearch Cluster

Elasticsearch besteht aus einer Reihe verschiedener Knotentypen, von denen zwei die wichtigsten sind: die Masterknoten und die Datenknoten. Die Masterknoten sind für das Cluster-Management verantwortlich, während die Datenknoten, wie der Name sagt, für die Daten zuständig sind (weitere Informationen zum Einrichten eines Elasticsearch-Clusters finden Sie hier).

Wir empfehlen den Aufbau eines Elasticsearch-Clusters, das aus mindestens drei Masterknoten besteht, da Split Brain häufig vorkommt. Dies ist im Wesentlichen ein Streit zwischen zwei Knoten, von denen einer der Master ist.

Was die Datenknoten betrifft, empfehlen wir mindestens zwei Datenknoten, damit Ihre Daten mindestens einmal repliziert werden. Dies führt zu einem Minimum von fünf Knoten: Die drei Master-Knoten können kleine Maschinen sein, und die beiden Datenknoten müssen auf soliden Maschinen mit sehr schnellem Speicher und großer Speicherkapazität skaliert werden.

Ausführen in verschiedenen AZs (aber nicht in verschiedenen Regionen)

Wir empfehlen, dass Ihre Elasticsearch-Knoten in verschiedenen Verfügbarkeitszonen oder in verschiedenen Segmenten eines Rechenzentrums ausgeführt werden, um eine hohe Verfügbarkeit sicherzustellen. Dies kann über eine Elasticsearch-Einstellung erfolgen, mit der Sie jedes Dokument so konfigurieren können, dass es zwischen verschiedenen AZs repliziert wird. Wie bei Logstash können die durch diese Bereitstellung entstehenden Kosten aufgrund der Datenübertragung ziemlich steil ansteigen.

ANWENDUNGSFÄLLE

Der ELK-Stack wird am häufigsten als Protokollanalyse-Tool verwendet. Seine Beliebtheit liegt in der Tatsache, dass es eine zuverlässige und relativ skalierbare Möglichkeit bietet, Daten aus mehreren Quellen zusammenzufassen, zu speichern und zu analysieren. Daher wird der Stack für eine Vielzahl unterschiedlicher Anwendungsfälle und -zwecke verwendet, von der Entwicklung über die Überwachung bis hin zur Sicherheit und Einhaltung von Vorschriften sowie für SEO und BI.

Bevor Sie sich entscheiden, den Stack einzurichten, müssen Sie zunächst Ihren spezifischen Anwendungsfall verstehen. Dies wirkt sich direkt auf alle Schritte aus, die auf dem Weg implementiert wurden – wo und wie der Stack installiert wird, wie der Elasticsearch-Cluster konfiguriert wird und welche Ressourcen ihm zugewiesen werden müssen, wie Datenpipelines erstellt werden und wie die Installation gesichert wird – die Liste ist schier endlos.

Also, wofür werden Sie ELK einsetzen?

Entwicklung und Fehlerbehebung

Protokolle sind dafür bekannt, in Krisenzeiten von Nutzen zu sein. Wenn ein Problem auftritt, schaut man als erstes in die Fehlerprotokolle und Ausnahmen. Protokolle sind jedoch viel früher im Lebenszyklus einer Anwendung hilfreich.

Wir glauben fest an die loggetriebene Entwicklung, bei der die Protokollierung bereits bei der ersten geschriebenen Funktion beginnt und anschließend in der gesamten Anwendung instrumentalisiert wird. Durch die Implementierung der Protokollierung in Ihren Code wird Ihren Anwendungen ein gewisses Maß an Beobachtbarkeit verliehen, was bei der Problembehandlung hilfreich ist.

Unabhängig davon, ob Sie einen Monolithen- oder Mikrodienst entwickeln, der ELK-Stack bietet sich frühzeitig als Mittel an, damit Entwickler Fehler und Ausnahmen korrelieren, identifizieren und beheben können, vorzugsweise beim Testen oder Staging, bevor der Code in Produktion geht. Über eine Vielzahl verschiedener Appender, Frameworks, Bibliotheken und Versender werden Protokollnachrichten zur zentralen Verwaltung und Analyse in den ELK-Stack verschoben.

Sobald es in die Produktion geht werden Kibana-Dashboards zur Überwachung des allgemeinen Zustands von Anwendungen und bestimmten Diensten verwendet. Wenn ein Problem auftritt und die Protokollierung auf strukturierte Weise instrumentalisiert wurde, können alle Protokolldaten an einem zentralen Ort gespeichert werden, was die Analyse und Fehlerbehebung zu einem effizienteren und schnelleren Prozess macht.

Cloud-Betrieb

Moderne IT-Umgebungen sind vielschichtig und von Natur aus weit gefächert. Dies stellt eine große Herausforderung für die verantwortlichen Teams dar, die sie bedienen und überwachen. Die Überwachung aller Systeme und Komponenten, die die Architektur der Anwendung umfasst, ist äußerst zeit- und ressourcenintensiv.

Um den Status und den allgemeinen Zustand einer Umgebung genau einschätzen und überwachen zu können, müssen die Teams von DevOps und IT Operations die folgenden wichtigen Überlegungen berücksichtigen: Zugriff auf die einzelnen Computer, Erfassen der Daten und Hinzufügen von Kontext zum Daten und verarbeiten sie, wo sie gespeichert werden und wie lange sie gespeichert werden sollen, wie sie analysiert werden, wie sie gesichert werden und wie Backups erfolgen.

Der ELK-Stack hilft, indem er Organisationen die Möglichkeit bietet, diese Fragen zu lösen, indem sie eine nahezu All-in-One-Lösung bieten. Beats können auf Maschinen bereitgestellt werden, um als Agenten zu fungieren, die Protokolldaten an Logstash-Instanzen weiterleiten. Logstash kann so konfiguriert werden, dass die Daten zusammengefasst und verarbeitet werden, bevor die Daten in Elasticsearch indiziert werden. Kibana wird dann verwendet, um die Daten zu analysieren, Anomalien zu erkennen, eine Ursachenanalyse durchzuführen und hübsche Überwachungs-Dashboards zu erstellen.

Und es sind nicht nur die Protokolle. Während Elasticsearch ursprünglich für die Volltextsuche und -analyse entwickelt wurde, wird es zunehmend auch für die Metrikanalyse verwendet. Das Überwachen von Leistungsmesswerten für jede Komponente in Ihrer Architektur ist der Schlüssel, um die Sichtbarkeit von Vorgängen zu verbessern. Die Erfassung dieser Metriken kann mithilfe von Drittanbieter-Überwachungs- oder -Überwachungsagenten oder sogar mithilfe einiger verfügbarer Beats (z. B. Metricbeat, Packetbeat) durchgeführt werden. Kibana wird jetzt mit neuen Visualisierungstypen ausgeliefert, die zur Analyse von Zeitreihen (Timelion, Visual Builder) beitragen.

Sicherheit und Compliance

Sicherheit war schon immer für Organisationen von entscheidender Bedeutung. In den letzten Jahren wurde der Einsatz von Sicherheitsmechanismen und -standards zu einer der wichtigsten Prioritäten, da sowohl die Häufigkeit der Angriffe als auch die Compliance-Anforderungen (HIPAA, PCI, SOC, FISMA usw.) zunahmen.

Da Protokolldaten eine Fülle an wertvollen Informationen darüber enthalten, was in Echtzeit in laufenden Prozessen tatsächlich abläuft, sollte es nicht überraschen, dass Sicherheit schnell zu einem starken Anwendungsfall für den ELK-Stack wird.

Trotz der Tatsache, dass ELK als eigenständiger Stack nicht mit integrierten Sicherheitsfunktionen ausgestattet ist, hat die Tatsache, dass Sie es verwenden können, um die Protokollierung von Ihrer Umgebung zu zentralisieren und Überwachungs- und sicherheitsorientierte Dashboards zu erstellen, zur Integration des Stacks mit einigen prominenten Sicherheitsstandards geführt.

Hier zwei Beispiele, wie der ELK-Stack als Teil einer Security-First-Bereitstellung implementiert werden kann.

Sicherheit

Da Protokolle vertrauliche Daten enthalten können, ist es wichtig zu schützen, wer was sehen kann. Wie können Sie den Zugriff auf bestimmte Dashboards, Visualisierungen oder Daten in Ihrer Protokollanalyseplattform einschränken? Es gibt keine einfache Möglichkeit, dies im ELK-Stack zu tun.

Eine Option ist die Verwendung des nginx-Reverseproxys für den Zugriff auf Ihr Kibana-Dashboard. Dies erfordert eine einfache nginx-Konfiguration, die denjenigen, die auf das Dashboard zugreifen möchten, einen Benutzernamen und ein Kennwort zuteilt. Dadurch wird der Zugriff auf Ihre Kibana-Konsole schnell blockiert.

Eine Herausforderung besteht hier, wenn Sie den Zugriff auf eine detailliertere Ebene beschränken möchten. Dies wird derzeit in Open Source ELK nicht standardmäßig unterstützt. Es gibt einige Open-Source-Lösungen, die helfen können (z. B. SearchGuard). Sie können auch das X-Pack von Elastic verwenden und die Sicherheit von Elasticsearch auf den Stack aufbauen. Bei Logz.io verfolgen wir einen anderen Ansatz, der einen rollenbasierten Zugriff ermöglicht.

Nicht zuletzt sollten Sie bei der Exposition von Elasticsearch vorsichtig sein, da es sehr anfällig für Angriffe ist. Es gibt einige grundlegende Schritte, die Sie dabei unterstützen werden, Ihre Elasticsearch-Instanzen abzusichern.

WARTBARKEIT

Protokolldatenkonsistenz

Logstash verarbeitet und analysiert Protokolle gemäß einem durch Filter-Plugins definierten Regelwerk. Wenn Sie über ein Zugriffsprotokoll von nginx verfügen, möchten Sie daher die Möglichkeit haben, jedes Feld anzuzeigen und Visualisierungen und Dashboards zu erstellen, die auf bestimmten Feldern basieren. Sie müssen die entsprechenden Analysefähigkeiten auf Logstash anwenden – was sich als große Herausforderung erwiesen hat, insbesondere beim Erstellen von Groks, beim Debuggen und beim Parsen von Protokollen, um die relevanten Felder für Elasticsearch und Kibana zu erhalten.

Es ist letztendlich sehr einfach, mit Logstash Fehler zu machen. Aus diesem Grund sollten Sie alle Protokollkonfigurationen mithilfe der Versionskontrolle sorgfältig testen und verwalten. Auf diese Weise können Sie, während Sie mit nginx und MySQL arbeiten können, während des Wachstums benutzerdefinierte Anwendungen integrieren, die zu großen und schwer zu verwaltenden Protokolldateien führen. Die Community hat eine Vielzahl von Lösungen zu diesem Thema generiert, aber Trial and Error sind bei Open Source-Tools äußerst wichtig, bevor sie in der Produktion eingesetzt werden.

Vorratsdatenspeicherung

Bei überschüssigen Indizes kommt ein weiterer Aspekt der Wartbarkeit zum Tragen. Je nachdem, wie lange Sie Daten aufbewahren möchten, müssen Sie einen Prozess einrichten, der alte Indizes automatisch löscht. Andernfalls stehen Ihnen zu viele Daten zur Verfügung, und Ihre Elasticsearch stürzt ab, was zu Datenverlust führt.

Um dies zu verhindern, können Sie mit Elasticsearch Curator Indizes löschen. Es wird empfohlen, einen Cron-Job zu verwenden, der automatisch Curator mit den relevanten Parametern erzeugt, um alte Indizes zu löschen, um sicherzustellen, dass nicht zu viele Daten gespeichert werden. In der Regel ist es erforderlich, Protokolle in S3 in einem Bucket zu speichern, um die Kompatibilität zu gewährleisten. Daher sollten Sie sicher sein, dass eine Kopie der Protokolle in ihrem ursprünglichen Format vorliegt.

ELASTICSEARCH

Was ist Elasticsearch?

Elasticsearch ist das lebendige Herzstück der heute beliebtesten Log-Analyse-Plattform – des ELK-Stacks (Elasticsearch, Logstash und Kibana). Die Rolle, die Elasticsearch spielt, ist so zentral, dass es mit dem Namen des Stacks selbst synonym wurde. Elasticsearch wird hauptsächlich für Such- und Protokollanalysen verwendet und ist heute eines der beliebtesten Datenbanksysteme, die derzeit verfügbar sind.

Elasticsearch ist eine moderne Such- und Analyse-Engine, die auf Apache Lucene basiert. Elasticsearch ist vollständig Open Source und mit Java erstellt und wird als NoSQL-Datenbank kategorisiert. Elasticsearch speichert Daten unstrukturiert. Bis vor kurzem konnten Sie die Daten nicht mit SQL abfragen. Das neue Elasticsearch-SQL-Projekt ermöglicht jedoch die Verwendung von SQL-Anweisungen zur Interaktion mit den Daten. Mehr dazu in zukünftigen Beiträgen.

Im Gegensatz zu den meisten NoSQL-Datenbanken legt Elasticsearch einen starken Fokus auf Suchfunktionen und -funktionen. So einfach, dass der einfachste Weg, um Daten von Elasticsearch zu erhalten, darin besteht, sie mithilfe der umfangreichen REST-API zu suchen.

Im Rahmen der Datenanalyse wird Elasticsearch zusammen mit den anderen Komponenten des ELK-Stacks, Logstash und Kibana verwendet und übernimmt die Rolle der Datenindizierung und -speicherung.

Weitere Informationen zum Installieren und Verwenden von Elasticsearch finden Sie in unserem Elasticsearch-Tutorial.

Grundlegende Konzepte von Elasticsearch

Elasticsearch ist ein umfangreiches und komplexes System. Das Detaillieren und Eintauchen in den Kern ist daher unmöglich. Es gibt jedoch einige grundlegende Konzepte und Begriffe, die jeder Benutzer von Elasticsearch lernen und kennen lernen sollte. Nachfolgend sind die fünf „must-know“-Konzepte aufgeführt.

Unterlagen

Dokumente sind JSON-Objekte, die in einem Elasticsearch-Index gespeichert sind und als Basiseinheit des Speichers gelten. In der Welt relationaler Datenbanken können Dokumente mit einer Zeile in einer Tabelle verglichen werden.

Nehmen wir beispielsweise an, dass Sie eine E-Commerce-Anwendung ausführen. Sie können ein Dokument pro Produkt oder ein Dokument pro Bestellung haben. Die Anzahl der Dokumente, die Sie in einem bestimmten Index speichern können, ist unbegrenzt.

Daten in Dokumenten werden mit Feldern definiert, die aus Schlüsseln und Werten bestehen. Ein Schlüssel ist der Name des Felds. Ein Wert kann ein Element mit vielen verschiedenen Typen sein, z. B. eine Zeichenfolge, eine Zahl, ein boolescher Ausdruck, ein anderes Objekt oder ein Wertefeld.

Dokumente enthalten auch reservierte Felder, die die Dokumentmetadaten bilden, z. B._index, _type und _id.

Typen

Elasticsearch-Typen werden in Dokumenten verwendet, um ähnliche Datentypen zu unterteilen, wobei jeder Typ eine eindeutige Klasse von Dokumenten darstellt. Typen bestehen aus einem Namen und einem Mapping (siehe unten) und werden durch Hinzufügen des Felds _typeverwendet. Dieses Feld kann dann zum Filtern verwendet werden, wenn ein bestimmter Typ abgefragt wird.

Ab Elasticsearch 6 kann ein Index nur einen Zuordnungstyp haben. Diese Funktion wird in zukünftigen Versionen schrittweise entfernt.

Mapping

Wie ein Schema in der Welt relationaler Datenbanken definiert das Mapping die verschiedenen Typen, die sich in einem Index befinden. Es definiert die Felder für Dokumente eines bestimmten Typs – den Datentyp (z. B. Zeichenfolge und Ganzzahl) und wie die Felder in Elasticsearch indiziert und gespeichert werden sollen.

Ein Mapping kann explizit definiert oder automatisch generiert werden, wenn ein Dokument mithilfe von Vorlagen indiziert wird. (Vorlagen enthalten Einstellungen und Zuordnungen, die automatisch auf einen neuen Index angewendet werden können.)

Index

Elasticsearch-Indizes sind logische Partitionen von Dokumenten und können mit einer Datenbank in der Welt relationaler Datenbanken verglichen werden.

Wenn Sie unser E-Commerce-App-Beispiel fortsetzen, können Sie einen Index mit allen Daten zu den Produkten und einen weiteren mit allen Daten zu den Kunden haben.

Sie können in Elasticsearch so viele Indizes definieren, wie Sie möchten. Dies kann sich jedoch auf die Leistung auswirken. Diese enthalten wiederum Dokumente, die für jeden Index eindeutig sind.

Indizes werden durch Kleinbuchstaben identifiziert, die beim Ausführen verschiedener Aktionen (z. B. Suchen und Löschen) für die Dokumente in jedem Index verwendet werden.

Shards

Die Indexgröße ist eine häufige Ursache für Abstürze von Elasticsearch. Da die Anzahl der Dokumente, die Sie in jedem Index speichern können, unbegrenzt ist, beansprucht ein Index möglicherweise Speicherplatz, der die Grenzen des Hosting-Servers überschreitet. Sobald sich ein Index dieser Grenze nähert, beginnt die Indexierung zu versagen.

Eine Möglichkeit, diesem Problem entgegenzuwirken, ist die horizontale Aufteilung von Indizes in Teile, die als Shards bezeichnet werden. Dadurch können Sie Vorgänge auf Shards und Knoten verteilen, um die Leistung zu verbessern.

Elasticsearch-Abfragen

Elasticsearch basiert auf Apache Lucene und stellt die Abfragesyntax von Lucene bereit. Wenn Sie sich mit der Syntax und den verschiedenen Operatoren vertraut machen, können Sie Elasticsearch abfragen.

Boolesche Operatoren

Wie bei den meisten Computersprachen unterstützt Elasticsearch die Operatoren AND, OR und NOT:

  • jack AND jillGibtEreignisse zurück, die sowohl jack als auch jill enthalten
  • ahab NICHT mobyGibtEreignisse zurück, die ahab enthalten, aber nicht moby
  • tom OR jerryGibtEreignisse zurück, die tom oder jerry oder beides enthalten

 

Felder

Möglicherweise suchen Sie nach Ereignissen, bei denen ein bestimmtes Feld bestimmte Begriffe enthält. Sie geben das wie folgt an:

  • Name: „Ned Stark“

Bereiche

Sie können nach Feldern in einem bestimmten Bereich suchen. Verwenden Sie dazu eckige Klammern für die Inklusivbereichssuche und geschweifte Klammern für die Exklusivbereichssuche:

  • age:[3 TO 10]– Gibt Ereignisse mit einem Alter zwischen 3 und 10 Jahren zurück
  • price:{100 TO 400}– Gibt Ereignisse mit Preisen zwischen 101 und 399 zurück
  • name:[Adam TO Ziggy]– Gibt Namen zwischen und einschließlich Adam und Ziggy zurück

 

Wildcards, Regexes und Fuzzy-Suche

Eine Suche wäre keine Suche ohne Wildcards. Sie können das Zeichen * für mehrere Wildcards verwenden oder das ? Zeichen für Wildcards für einzelne Zeichen.

URI-Suche

Der einfachste Weg zum Durchsuchen Ihres Elasticsearch-Clusters ist die URI-Suche. Sie können eine einfache Abfrage mit dem Abfrageparameter q an Elasticsearch übergeben.

Elasticsearch REST API

Das Tolle an Elasticsearch ist die umfassende REST API, mit der Sie die indizierten Daten auf unzählige Arten integrieren, verwalten und abfragen können. Beispiele für die Verwendung dieser API zur Integration von Elasticsearch-Daten sind reichlich vorhanden und beziehen sich auf verschiedene Unternehmen und Anwendungsfälle.

Die Interaktion mit der API ist einfach – Sie können jeden HTTP-Client verwenden, aber Kibana verfügt über ein integriertes Tool namens Console, das für diesen Zweck verwendet werden kann.

So umfangreich die Elasticsearch-REST-APIs sind, es gibt eine Lernkurve. Lesen Sie zunächst die API-Konventionen, lernen Sie die verschiedenen Optionen kennen, die auf die Aufrufe angewendet werden können, das Erstellen der APIs und das Filtern von Antworten. Es ist zu beachten, dass sich einige APIs von Version zu Version ändern und veralten. Es empfiehlt sich, die wichtigsten Änderungen im Auge zu behalten.

Elasticsearch Dokument-API

Diese Kategorie von APIs wird für die Handhabung von Dokumenten in Elasticsearch verwendet. Mit diesen APIs können Sie beispielsweise Dokumente in einem Index erstellen, aktualisieren, in einen anderen Index verschieben oder entfernen.

Elasticsearch Such-API

Wie der Name schon sagt, können diese API-Aufrufe verwendet werden, um indizierte Daten nach bestimmten Informationen abzufragen. Such-APIs können global, über alle verfügbaren Indizes und Typen oder genauer innerhalb eines Index angewendet werden. Die Antworten enthalten Übereinstimmungen mit der jeweiligen Abfrage.

Elasticsearch Indizes-API

Mit dieser Art von Elasticsearch-API können Benutzer Indizes, Zuordnungen und Vorlagen verwalten. Mit dieser API können Sie beispielsweise einen neuen Index erstellen oder löschen, prüfen, ob ein bestimmter Index vorhanden ist oder nicht, und ein neues Mapping für einen Index definieren.

Elasticsearch Cluster-API

Hierbei handelt es sich um cluster-spezifische API-Aufrufe, mit denen Sie Ihren Elasticsearch-Cluster verwalten und überwachen können. Bei den meisten APIs können Sie definieren, welcher Elasticsearch-Knoten entweder über die interne Knoten-ID, den Namen oder die Adresse aufgerufen werden soll.

ELASTICSEARCH PLUGINS

Elasticsearch-Plugins werden verwendet, um die grundlegenden Funktionen von Elasticsearch auf verschiedene, spezifische Arten zu erweitern. Es gibt Typen, die zum Beispiel Sicherheitsfunktionen, Erkennungsmechanismen und Analysefunktionen zu Elasticsearch hinzufügen.

Unabhängig von den hinzugefügten Funktionalitäten gehören Elasticsearch-Plugins zu einer der beiden folgenden Kategorien: Core-Plugins oder Community-Plugins. Ersteres wird als Teil des Elasticsearch-Pakets geliefert und vom Elastic-Team gepflegt, während letzteres von der Community entwickelt wird und somit separate Einheiten mit eigenen Versions- und Entwicklungszyklen sind.

Das Installieren von Core-Plugins ist einfach. Im folgenden Beispiel werde ich das X-Pack-Plugin installieren. X-Pack erweitert Elasticsearch, indem es Shield, Watcher und Marvel einfügt – drei Plugins, die vor Elasticsearch 5.x separate Entitäten waren, die jeweils separate Installation und Einrichtung erfordern (die Befehle gelten für die DEB/RPM-Installation):

1

2

cd/usr/share/elasticsearch

sudo bin/elasticsearchplugin install xpack

Plugins müssen auf jedem Knoten im Cluster installiert werden, und jeder Knoten muss nach der Installation neu gestartet werden.

Community-Plugins sind etwas unterschiedlich, da für jedes eine andere Installationsanleitung gilt.

Einige Community-Plugins werden auf die gleiche Weise wie Core-Plugins installiert, erfordern jedoch zusätzliche Konfigurationsschritte für Elasticsearch.

LOGSTASH

Was ist Logstash?

Im ELK-Stack (Elasticsearch, Logstash und Kibana) wird die entscheidende Aufgabe beim Analysieren von Daten dem „L“ im Stack – Logstash – zugewiesen.

Logstash war ein Open-Source-Tool, das für das Streaming einer großen Menge von Protokolldaten aus mehreren Quellen entwickelt wurde. Nachdem es in den ELK-Stack integriert wurde, entwickelte es sich zum Arbeitspferd des Stacks. Es ist auch für die Verarbeitung der Protokollnachrichten verantwortlich, verbessert sie, massiert sie und sendet sie an einen definierten Speicherort (Einlagerung).

Dank eines großen Plug-In-Ökosystems kann Logstash zum Sammeln, Anreichern und Umwandeln einer Vielzahl unterschiedlicher Datentypen verwendet werden. Es gibt über 200 verschiedene Plugins für Logstash, wobei eine große Community die erweiterbaren Funktionen nutzt.

Für Logstash war die Reise nicht immer reibungslos. Aufgrund einiger inhärenter Leistungsprobleme und Konstruktionsfehler hat Logstash im Laufe der Jahre zahlreiche Beschwerden von Benutzern erhalten. Es wurden Nebenprojekte entwickelt, um einige dieser Probleme zu lösen (z. B. Lumberjack, Logstash-Forwarder, Beats). Alternative Log-Aggregatoren begannen mit Logstash zu konkurrieren.

Trotz dieser Mängel ist Logstash nach wie vor ein entscheidender Bestandteil des Stacks. Es wurden große Schritte unternommen, um diese Wehwehchen durch die Einführung von Beats und Verbesserungen in Logstash selbst zu verringern und letztendlich die Protokollierung mit ELK wesentlich zuverlässiger zu gestalten, als dies bisher der Fall war.

Weitere Informationen zum Installieren und Verwenden von Logstash finden Sie in unserem Logstash-Tutorial.

Logstash-Konfiguration

Ereignisse, die von Logstash aggregiert und verarbeitet werden, durchlaufen drei Phasen: Erfassung, Verarbeitung und Versand. Welche Daten gesammelt werden, wie sie verarbeitet werden und wohin sie gesendet werden, wird in einer Logstash-Konfigurationsdatei definiert, die die Pipeline definiert.

Jede dieser Stufen ist in der Logstash-Konfigurationsdatei mit sogenannten Plugins definiert – „Input“ -Plugins für die Datenerfassungsphase, „Filter“ -Plugins für die Verarbeitungsstufe und „Output“ -Plugins für die Dispositionsstufe. Sowohl das Eingabe- als auch das Ausgabe-Plug-In unterstützen Codecs, mit denen Sie Ihre Daten kodieren oder dekodieren können (z. B. Json, Multiline, Plain).

Eingabe-Plugins

Logstash ist so leistungsfähig, dass es Protokolle und Ereignisse aus verschiedenen Quellen zusammenfasst. Mit mehr als 50 Eingabe-Plug-Ins für verschiedene Plattformen, Datenbanken und Anwendungen kann Logstash definiert werden, um Daten aus diesen Quellen zu sammeln und zu verarbeiten und sie zur Speicherung und Analyse an andere Systeme zu senden.

Die am häufigsten verwendeten Eingaben sind: file, beats, syslog, http, tcp, udp, stdin. Sie können jedoch Daten aus zahlreichen anderen Quellen aufnehmen.

Filter-Plugins

Logstash unterstützt eine Reihe äußerst leistungsfähiger Filter-Plugins, mit denen Sie Protokolle erweitern, bearbeiten und verarbeiten können. Diese Filter machen Logstash zu einem sehr vielseitigen und wertvollen Werkzeug für die Analyse von Protokolldaten.

Filter können mit bedingten Anweisungen kombiniert werden, um eine Aktion auszuführen, wenn ein bestimmtes Kriterium erfüllt ist.

Die am häufigsten verwendeten Eingaben sind: grok, date, mutate, drop. Weitere Informationen zu diesen und anderen Themen finden Sie in 5 Logstash Filter Plugins.

Ausgabe-Plugins

Wie die Eingaben unterstützt Logstash eine Reihe von Ausgabe-Plugins, mit denen Sie Ihre Daten an verschiedene Standorte, Dienste und Technologien übertragen können. Sie können Ereignisse mithilfe von Ausgaben wie File, CSV und S3 speichern, mit RabbitMQ und SQS in Nachrichten konvertieren oder an verschiedene Dienste wie HipChat, PagerDuty oder IRC senden. Die Anzahl der Kombinationen von Ein- und Ausgängen in Logstash macht ihn zu einem äußerst vielseitigen Ereignistransformator.

Logstash-Ereignisse können aus mehreren Quellen stammen. Es ist daher wichtig zu prüfen, ob ein Ereignis von einer bestimmten Ausgabe verarbeitet werden soll. Wenn Sie keine Ausgabe definieren, erstellt Logstash automatisch eine Standardausgabe. Ein Ereignis kann mehrere Ausgabe-Plugins passieren.

Logstash-Codecs

Codecs können in Ein- und Ausgängen verwendet werden. Eingabecodecs bieten eine bequeme Möglichkeit, Ihre Daten zu dekodieren, bevor sie in die Eingabe eingegeben werden. Ausgabecodecs bieten eine bequeme Möglichkeit, Ihre Daten zu codieren, bevor sie die Ausgabe verlassen.

Einige gängige Codecs:

  • Der Standard-Codec „plain“ ist für Klartext ohne Begrenzung zwischen Ereignissen
  • Der „json“-Codec dient zum Kodieren von JSON-Ereignissen in Eingaben und zum Dekodieren von JSON-Meldungen in Ausgaben. Beachten Sie, dass er in Klartext umgewandelt wird, wenn die empfangenen Nutzdaten kein gültiges JSON-Format aufweisen
  • Mit dem Codec „json_lines“ können Sie entweder durch \n begrenzte JSON-Ereignisse empfangen und codieren oder JSON-Nachrichten dekodieren, die in den Ausgaben durch \n begrenzt sind
  • Mit dem „Rubydebug“, der beim Debuggen sehr nützlich ist, können Sie Logstash-Ereignisse als Daten-Ruby-Objekte ausgeben

Konfigurationsbeispiel

Logstash verfügt über eine einfache DSL-Konfiguration, mit der Sie die oben beschriebenen Eingaben, Ausgaben und Filter sowie ihre spezifischen Optionen festlegen können. Die Reihenfolge ist wichtig, insbesondere bei Filtern und Ausgängen, da die Konfiguration grundsätzlich in Code umgewandelt und dann ausgeführt wird. Denken Sie daran, wenn Sie Ihre Configs schreiben, und versuchen Sie, sie zu debuggen.

Eingabe

Der Eingabeabschnitt in der Konfigurationsdatei definiert das zu verwendende Eingabe-Plugin. Jedes Plugin verfügt über eigene Konfigurationsoptionen, die Sie vor der Verwendung untersuchen sollten.

Beispiel:

1

2

3

4

5

6

7

8

9

10

11

input {

 

file {

 

path =>„/var/log/apache/access.log“

 

start_position => „beginning“

 

}

 

}

 

Hier verwenden wir das Dateieingabe-Plugin. Wir haben den Pfad zu der Datei eingegeben, die wir sammeln möchten, und als Startposition für die Verarbeitung der Protokolle vom Anfang der Datei aus definiert.

Filter

Der Filterabschnitt in der Konfigurationsdatei definiert, welche Filter-Plugins verwendet werden sollen, d. h. welche Verarbeitung wir auf die Protokolle anwenden möchten. Jedes Plugin verfügt über eigene Konfigurationsoptionen, die Sie vor der Verwendung untersuchen sollten.

Beispiel:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

filter {

 

grok {

 

match => { „message“ =>„%{COMBINEDAPACHELOG}“}

 

}

 

date {

 

match => [ „timestamp“ ,„dd/MMM/yyyy:HH:mm:ss Z“ ]

 

}

 

geoip {

 

source => „clientip“

 

}

 

}

In diesem Beispiel verarbeiten wir, dass Apache-Zugriffsprotokolle angewendet werden:

  • Ein Grok-Filter, der die Protokollzeichenfolge analysiert und das Ereignis mit den relevanten Informationen auffüllt.
  • Ein Datumsfilter zum Analysieren eines Datumsfelds, das eine Zeichenfolge als Zeitmarkenfeld ist (jede Logstash-Pipeline erfordert einen Zeitstempel, daher ist dies ein erforderlicher Filter).
  • Ein Geoip-Filter, um das Clientip-Feld mit geographischen Daten anzureichern. Mit diesem Filter werden dem Ereignis neue Felder (z. B. Landname) basierend auf dem Clientip-Feldhinzugefügt.

 

Ausgabe

Der Ausgabeabschnitt in der Konfigurationsdatei definiert das Ziel, an das die Protokolle gesendet werden sollen. Wie bereits erwähnt verfügt jedes Plugin über eigene Konfigurationsoptionen, die Sie vor der Verwendung untersuchen sollten.

Beispiel:

1

2

3

4

5

6

7

8

9

output {

 

elasticsearch {

 

hosts =>[„localhost:9200“]

 

}

 

}

In diesem Beispiel definieren wir eine lokal installierte Instanz von Elasticsearch.

 

Vollständiges Beispiel

Zusammenfassend sollte die Logstash-Konfigurationsdatei wie folgt aussehen:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

input {

 

file {

 

path =>„/var/log/apache/access.log“

 

start_position => „beginning“

 

}

 

}

 

filter {

 

grok {

 

match => { „message“ => „%{COMBINEDAPACHELOG}“ }

 

}

 

date {

 

match => [ „timestamp“ ,„dd/MMM/yyyy:HH:mm:ss Z“]

 

}

 

geoip {

 

source => „clientip“

 

}

 

}

 

output {

 

elasticsearch {

 

hosts => [„localhost:9200“]

 

}

 

}

 

Logstash-Fallstricke

Logstash weist, wie bereits erwähnt, einige inhärente Probleme auf, die mit seinem Design zusammenhängen. Für Logstash muss JVM ausgeführt werden, und diese Abhängigkeit wurde in Verbindung mit der Implementierung in Ruby zur Hauptursache für erheblichen Speicherbedarf, insbesondere wenn mehrere Pipelines und erweiterte Filterung beteiligt sind.

Die Leistung ist einer der Gründe, warum Benutzer alternative Optionen bevorzugen, und Logstash-Abstürze treten nicht selten auf. Dies kann zu Datenverlust führen, insbesondere wenn Sie kein Sicherheitsnetz eingerichtet haben.

Es gibt verschiedene Möglichkeiten, dieses Sicherheitsnetz einzusetzen, sowohl in Logstash als auch in einigen, bei denen Middleware-Komponenten zu Ihrem Stack hinzugefügt werden:

  • Puffer hinzufügen – Eine empfohlene Methode ist das Hinzufügen einer Warteschlangenschicht zwischen Logstash und dem Ziel. Die beliebtesten Methoden verwenden Kafka, Redis und RabbitMQ.
  • Persistente Warteschlangen – eine integrierte Funktion zur Datenstabilisierung in Logstash, mit der Sie Daten in einer internen Warteschlange auf der Festplatte speichern können. Standardmäßig deaktiviert – Sie müssen die Funktion in der Logstash-Einstellungsdatei aktivieren.
  • Dead-Letter-Warteschlangen – ein Mechanismus zum Speichern von Ereignissen, die nicht auf der Festplatte verarbeitet werden konnten. Standardmäßig deaktiviert – Sie müssen die Funktion in der Logstash-Einstellungsdatei aktivieren.

KIBANA

Was ist Kibana?

Völlig Open Source ist Kibana eine browserbasierte Benutzeroberfläche, mit der die in Elasticsearch-Indizes gespeicherten Daten durchsucht, analysiert und visualisiert werden können (Kibana kann nicht in Verbindung mit anderen Datenbanken verwendet werden). Kibana ist besonders bekannt und beliebt wegen seiner umfangreichen Grafik- und Visualisierungsfunktionen, mit denen Benutzer große Datenmengen erkunden können.

Kibana kann unter Linux, Windows und Mac mit .zip oder tar.gz, Repositorys oder auf Dockern installiert werden. Kibana läuft auf node.js und die Installationspakete werden mit den erforderlichen Binärdateien geliefert. Weitere Informationen zum Einrichten von Kibana finden Sie in unserem Kibana-Tutorial.

Bitte beachten Sie, dass in neueren Versionen Änderungen am Lizenzmodell vorgenommen wurden, einschließlich der Aufnahme grundlegender X-Pack-Funktionen in die Standardinstallationspakete.

Kibana-Suchen

Durchsuchen von Elasticsearch nach bestimmten Protokollnachrichten oder Zeichenfolgen in diesen Nachrichten ist die Spezialität von Kibana. In der Abfrageleiste von Kibana können Sie die Lucene-Abfragesyntax eingeben oder Suchen auf der Basis von Elasticsearch Query DSL durchführen. Nach der Eingabe filtert der Hauptanzeigebereich die angezeigten Daten entsprechend und zeigt Übereinstimmungen in umgekehrter chronologischer Reihenfolge an.

Das Kibana-Abfragen ist eine Kunst für sich, und es gibt verschiedene Methoden, um Ihre Daten zu durchsuchen. Hier sind die häufigsten Suchtypen:

  • Freitextsuchen – für die schnelle Suche nach einer bestimmten Zeichenfolge.
  • Suchen auf Feldebene – Wird für die Suche nach einer Zeichenfolge in einem bestimmten Feld verwendet.
  • Logische Anweisungen – werden verwendet, um Suchen in einer logischen Anweisung zu kombinieren.
  • Annäherungssuche – wird für die Suche nach Begriffen innerhalb einer bestimmten Zeichennähe verwendet.

Eine ausführlichere Erklärung der verschiedenen Suchtypen finden Sie im Kibana-Tutorial.

Spickzettel für Kibana-Suchen

Im Folgenden finden Sie eine Liste einiger Tipps und bewährter Methoden für die Verwendung der oben genannten Suchtypen:

  • Nutzen Sie Freitextsuchen für die schnelle Suche nach einer bestimmten Zeichenfolge. Verwenden Sie doppelte Anführungszeichen („Zeichenfolge“), um nach einer genauen Übereinstimmung zu suchen.
    Beispiel: „USA“
  • Verwenden Sie die Wildcard *, um eine beliebige Anzahl von Zeichen zu ersetzen. Die Wildcard ? hingegen, um nur ein Zeichen zu ersetzen.
  • Verwenden Sie das Präfix _exists_ für ein Feld, um nach Protokollen zu suchen, die dieses Feld enthalten.
    Beispiel: _exists_:response
  • Sie können einen Bereich innerhalb eines Feldes suchen.
    Beispiele: Wenn Sie eckige Klammern [] verwenden, bedeutet dies, dass die Ergebnisse inklusive sind. Wenn Sie geschweifte Klammern {} verwenden, bedeutet dies, dass die Ergebnisse exklusiv sind.
  • Verwenden Sie bei der Verwendung logischer Anweisungen (z. B. AND, OR, TO) innerhalb einer Suche Großbuchstaben. Beispiel: response:[400 TO 500]
  • Benutzen Sie -,! und NOT um negative Begriffe zu definieren.
    Beispiel: response:[400 TO 500] AND NOT response:404
  • Annäherungssuche wird für die Suche nach Begriffen innerhalb einer bestimmten Zeichennähe verwendet. Beispiel: [categovi~2] sucht nach allen Begriffen, die sich innerhalb von zwei Änderungen gegenüber [categovi] befinden. Annäherungssuchen verwenden viele Ressourcen – sinnvoll einsetzen!
  • Die Suche auf Feldebene für nicht analysierte Felder funktioniert anders als die Freitextsuche.
    Beispiel: Wenn der Feldwert Error ist, wird die Suche nach *rror nicht die richtige Antwort zurückgeben.
  • Wenn Sie keinen logischen Operator angeben, lautet der Standardoperator OR.
    Beispiel: Bei der Suche nach Error Exception wird nach Error OR Exception gesucht
  • Die Verwendung von vorangestellten Wildcards ist eine sehr teure Abfrage und sollte nach Möglichkeit vermieden werden.

In Kibana 6.3 vereinfacht eine neue Funktion das Sucherlebnis und bietet Funktionen zum automatischen Vervollständigen. Diese Funktion muss zur Verwendung aktiviert sein und ist derzeit experimentell.

Kibana-Visualisierungen

Wie bereits erwähnt, ist Kibana für seine Visualisierungsfunktionen bekannt. Mit einer Vielzahl von verschiedenen Diagrammen und Tabellen können Sie Ihre Daten nach Belieben schneiden und würfeln. Sie werden feststellen, dass Sie mit Ihren Daten fast alles tun können, was Sie möchten.

Das Erstellen von Visualisierungen ist jedoch nicht immer unkompliziert und kann Zeit in Anspruch nehmen. Der Schlüssel zu diesem Prozess ist das Wissen um Ihre Daten. Je mehr Sie mit den verschiedenen Ecken und Winkeln in Ihren Daten vertraut sind, desto einfacher ist es.

Kibana-Visualisierungen basieren auf Abfragen von Elasticsearch. Mit Elasticsearch-Aggregationen (z. B. Summe, Durchschnitt, Min., Max usw.) können Sie verschiedene Verarbeitungsaktionen ausführen, damit Ihre Visualisierungen Trends in den Daten darstellen.

Visualisierungstypen

Visualisierungen in Kibana sind in fünf verschiedene Visualisierungstypen unterteilt:

  • Grunddiagramme (Bereich, Heat Map, Horizontale Leiste, Linie, Torte, Vertikale Leiste)
  • Daten (Datumstabelle, Messungen, Ziel, Metrik)
  • Karten (Koordinatenkarte, Regionskarte)
  • Zeitreihen (Zeitlinien, Visual Builder)
  • Sonstiges (Steuerelemente, Markdown, Tag Cloud)

In der nachstehenden Tabelle beschreiben wir die Hauptfunktionen jeder Visualisierung und ein Anwendungsbeispiel:

Vertikales Balkendiagramm:Ideal für Zeitreihendaten und zum Aufteilen von Zeilen über Felder URLs im Laufe der Zeit
Kuchendiagramm:Nützlich zum Anzeigen von Teilen eines Ganzen Top 5 Speicherverbrauchende Systemprozeduren
Flächendiagramm:Für Zeitreihendaten und zum Aufteilen von Zeilen über Felder Benutzer im Laufe der Zeit
Heat Map: Zum Anzeigen statistischer Ausreißer, wird häufig für Latenzwerte verwendet Latenz und Ausreißer
Horizontales Balkendiagramm:Gut, um Beziehungen zwischen zwei Feldern zu zeigen URL und Verweis
Liniendiagramm:Eine einfache Möglichkeit, Zeitreihen anzuzeigen, eignet sich zum Aufteilen von Linien, um Anomalien anzuzeigen Durchschnittliche CPU-Zeit pro Host
Datentabelle:Beste Methode, um mehrere Felder auf benutzerdefinierte Weise aufzuteilen Hauptbenutzer, Host, Pod, Container nach Verwendung
Messungen: Eine Möglichkeit, den Status einer bestimmten Metrik mithilfe der von Ihnen definierten Schwellenwerte anzuzeigen Grenzen des Speicherverbrauchs
Metrisch:Nützliche Visualisierung zur Anzeige einer Berechnung als einzelne Zahl Anzahl der laufenden Docker-Container.
Koordinatenkarte & RegionskarteHelfen beim Hinzufügen einer geografischen Dimension zu IP-basierten Protokollen Geografischer Ursprung von Webserveranforderungen.
Timelion und Visual Query Builder: Hiermit können Sie erweiterte Abfragen auf der Grundlage von Zeitreihendaten erstellen Prozentsatz von 500 Fehlern über die Zeit
Markdown: Eine gute Möglichkeit, Ihrem Dashboard basierend auf der Markdown-Syntax eine angepasste text- oder bildbasierte Visualisierung hinzuzufügen Firmenlogo oder eine Beschreibung eines Dashboards
Tag Cloud: Hilft bei der Anzeige von Wortgruppen, die nach ihrer Bedeutung sortiert sind Länder, die Anforderungen an einen Webserver senden

Kibana-Dashboards

Sobald Sie eine Sammlung von Visualisierungen erstellt haben, können Sie sie zu einer umfassenden Visualisierung hinzufügen, die als Dashboard bezeichnet wird. Mithilfe von Dashboards können Sie ein System oder eine Umgebung von einem hohen Standpunkt aus überwachen, um die Korrelation von Ereignissen und die Trendanalyse zu vereinfachen.

Dashboards sind äußerst dynamisch – sie können bearbeitet, geteilt, mit ihnen herumgespielt, in verschiedenen Anzeigemodi geöffnet werden und vieles mehr. Durch Klicken auf ein Feld in einer bestimmten Visualisierung innerhalb eines Dashboards wird das gesamte Dashboard entsprechend gefiltert (oben auf der Seite wird ein Filter hinzugefügt).

Kibana Elasticsearch-Index

Die in Kibana gespeicherten Suchen, Visualisierungen und Dashboards werden als Objekte bezeichnet. Diese Objekte werden in einem dedizierten Elasticsearch-Index (.kibana) für Debugging, gemeinsame Nutzung, wiederholte Verwendung und Sicherung gespeichert.

Der Index wird erstellt, sobald Kibana gestartet wird. Sie können den Namen in der Kibana-Konfigurationsdatei ändern. Der Index enthält die folgenden Dokumente, die jeweils eigene Felder enthalten:

  • Gespeicherte Indexmuster
  • Gespeicherte Suche
  • Gespeicherte Visualisierungen
  • Gespeicherte Dashboards

BEATS

Was sind Beats?

Beats sind eine Sammlung von Open-Source-Protokollversendern, die als Agenten fungieren, die auf den verschiedenen Servern in Ihrer Umgebung zum Erfassen von Protokollen oder Metriken installiert werden. Die in Go geschriebenen Versender wurden so konzipiert, dass sie ein geringes Gewicht haben – sie haben einen geringen Installationsaufwand, sind ressourceneffizient und funktionieren ohne Abhängigkeiten.

Die von den verschiedenen Beats gesammelten Daten variieren – Protokolldateien im Fall von Filebeat, Netzdaten im Falle von Packetbeat, Servermetriken im Fall von Metricbeat usw.  Zusätzlich zu den von Elastic entwickelten und unterstützten Beats gibt es eine wachsende Liste von Beats, die von der Community entwickelt und bereitgestellt werden.

Nach der Erfassung können Sie Ihren Beat so konfigurieren, dass die Daten entweder direkt an Elasticsearch oder an Logstash zur weiteren Verarbeitung gesendet werden.

In unseremBeats-Tutorialerfahren Sie, wie Sie Beats installieren, verwenden und ausführen.

Filebeat

Filebeat dient zum Sammeln und Versenden von Protokolldateien. Filebeat kann auf fast jedem Betriebssystem installiert werden, einschließlich als Docker-Container, und enthält interne Module für bestimmte Plattformen wie Apache, MySQL, Docker und mehr, die Standardkonfigurationen und Kibana-Objekte für diese Plattformen enthalten.

Packetbeat

Packetbeat, der Netzpaketanalysator, wurde als erster Beat eingeführt. Packetbeat erfasst den Netzverkehr zwischen Servern und kann daher für die Anwendungs- und Leistungsüberwachung verwendet werden. Packetbeat kann auf dem überwachten Server oder auf einem eigenen dedizierten Server installiert werden.

Weitere Informationen zur Verwendung von Packetbeat finden Siehier.

Metricbeat

Metricbeat erfasst verschiedene Metriken auf Systemebene für verschiedene Systeme und Plattformen. Wie Filebeat unterstützt Metricbeat auch interne Module zum Erfassen von Statistiken von bestimmten Plattformen. Sie können die Häufigkeit konfigurieren, mit der Metricbeat die Metriken erfasst, und welche spezifischen Metriken mithilfe dieser Module und Untereinstellungen, Metriken genannt, erfasst werden sollen.

Weitere Informationen zur Verwendung von Metricbeat finden Siehier.

Winlogbeat

Winlogbeat ist nur für Windows-Systemadministratoren oder -Entwickler interessant, da es ein Beat ist, der speziell für das Erfassen von Windows-Ereignisprotokollen entwickelt wurde. Es kann zur Analyse von Sicherheitsereignissen, installierten Updates usw. verwendet werden.

Weitere Informationen zur Verwendung von Winlogbeat finden Siehier.

Beats konfigurieren

Beats basieren auf der gleichen zugrunde liegenden Architektur und folgen denselben Struktur- und Konfigurationsregeln.

Im Allgemeinen umfasst die Konfigurationsdatei für Ihren Beat zwei Hauptabschnitte: Der eine definiert, welche Daten zu erfassen sind und wie sie gehandhabt werden sollen, der andere, wohin die Daten gesendet werden sollen.

Konfigurationsdateien befinden sich normalerweise im selben Verzeichnis – für Linux ist dies die/etc/<beatname>Verzeichnis. Für Filebeat wäre dies/etc/filebeat/filebeat.yml, für Metricbeat /etc/metricbeat/metricbeat.yml.Und so weiter.

Beats-Konfigurationsdateien basieren auf dem YAML-Format mit einem Wörterbuch, das eine Gruppe von Schlüsselwertpaaren enthält. Sie können jedoch Listen und Zeichenfolgen sowie verschiedene andere Datentypen enthalten. Die meisten Beats enthalten auch Dateien mit vollständigen Konfigurationsbeispielen, die zum Lernen der verschiedenen Konfigurationseinstellungen hilfreich sind. Verwenden Sie es als Referenz.

Beats-Module

Filebeat- und Metricbeat-Unterstützungsmodule – integrierte Konfigurationen und Kibana-Objekte für bestimmte Plattformen und Systeme. Anstatt diese beiden Beats zu konfigurieren, helfen Ihnen diese Module, mit vorkonfigurierten Einstellungen zu beginnen, die in den meisten Fällen gut funktionieren, aber Sie können sie auch nach Ihren Wünschen anpassen und verfeinern.

Filebeat-Module: Apache, Auditd, Icinga, Kafka, Logstash, MySQL, Nginx, PostgreSQL, Redis, System, Traefik.

Metricbeat-Module: Apache, HAProxy, MySQL, Nginx, PostgreSQL, Redis, System, Zookeeper.

Konfigurationsbeispiel

Wie sieht also ein Konfigurationsbeispiel aus? Natürlich unterscheidet sich dies je nach Beat. Nachfolgend finden Sie jedoch ein Beispiel für eine Filebeat-Konfiguration, die einen einzelnen Prospector zum Verfolgen von Protokollen des Puppet-Servers, eine JSON-Anweisung zum Parsen und eine lokale Instanz von Elasticsearch als Ausgabeziel verwendet.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

filebeat.prospectors:

 

type: log

 

enabled: true

 

paths:

 

/var/log/puppetlabs/puppetserver/puppetserver.log.json

 

/var/log/puppetlabs/puppetserver/puppetserveraccess.log.json

 

json.keys_under_root: true

 

output.elasticsearch:

 

# Array of hosts to connect to.

 

hosts: [„localhost:9200“]

Best Practices für die Konfiguration

Jeder Beat enthält eine eigene Konfigurationsdatei und Konfigurationseinstellungen und erfordert daher eigene Anweisungen. Es gibt jedoch einige gängige Best Practices für die Konfiguration, die hier beschrieben werden können, um ein solides allgemeines Verständnis zu vermitteln.

  • Einige Beats, wie zum Beispiel Filebeat, enthalten vollständige Beispielkonfigurationsdateien (z. B. /etc/filebeat/filebeat.full.yml). Diese Dateien enthalten lange Listen aller verfügbaren Konfigurationsoptionen.
  • YAML-Dateien sind extrem empfindlich. Verwenden Sie beim Einrücken Ihrer Zeilen KEINE Tabulatoren – nur Leerzeichen. YAML-Konfigurationsdateien für Beats werden im Wesentlichen auf die gleiche Weise erstellt, wobei zwei Leerzeichen für die Einrückung verwendet werden.
  • Verwenden Sie einen Texteditor (ich verwende Sublime), um die Datei zu bearbeiten.

Das Zeichen ‚-‚ (Bindestrich) wird zum Definieren neuer Elemente verwendet. Achten Sie darauf, dass sie ihre Einrückungen und die Hierarchien zwischen Unterkonstrukten beibehalten.

 

nächster Artikel: Sicherheit