Seite wählen

NETWAYS Blog

Ein kurzer Abriss über Graylog Sidecar

Graylog Sidecar ist ein Konfigurationsmanagementsystem, ein sogenanntes Framework, für unterschiedliche Log Collectoren, auch Backends genannt. Die Graylog Nodes agieren hier als zentraler Hub und halten die Konfiguration der Log Collectoren. Auf unterstützten Systemen, die Log Messages generieren, kann Sidecar als Service (unter Windows) oder daemon (unter Linux) laufen. Die Kommunikation zwischen Sidecar und Graylog wird durch eine SSL-Verschlüsselung der API gewährleistet. Für die Verbindung zwischen den Collectoren und Graylog sollte als Best Practive TLS aktiviert werden.

Die Log Collector Konfigurationen werden zentral über die Graylog Weboberfläche verwaltet. Periodisch holt sich der Sidecar daemon über die REST API alle relevanten Konfigurationen für das Ziel. Beim ersten Durchlauf oder nach einer Konfigurationsänderung erstellt Graylog Sidecar automatisch die relevanten Backend-Konfigurationsdateien. Im Anschluss werden die neu- oder umkonfigurierten Log Collectoren (neu-)gestartet.

 

Schematische Darstellung

Quelle: Graylog Sidecar

 

Folgende Punkte sind hierbei wichtig zu verstehen und zu beachten:

  • Eine Konfiguration ist die Darstellung einer Log Collector Konfigurationsdatei in der Graylog Weboberfläche. Eine Konfigurationsdatei kann den Sidecars zugewiesen werden, womit auch die entsprechenden Collectoren zugewiesen werden. Es können mehrere Konfigurationen einem einzigen Log Collector zugewiesen werden, jedoch kann ein Kollektor nicht mehreren Sidecars zugewiesen werden.
  • Inputs stellen die Prozesse dar, mit denen die Collectoren Daten sammeln. Ein Input kann z. B. ein Log File sein, das vom Collector in regelmäßgen Abständen gelesen wird, oder eine Verbindung zu einem Windows Event System, das Log Events ausgibt. Ein Input ist verbunden mit einem Output, ansonsten wäre es nicht möglich, die Daten an den näschsten Punkt zu weiterzugeben. Daher muss als erstes ein Output erstellt werden, mit dem danach einer oder mehrere Inputs verknüpft werden.
  • Jede Sidecar Instanz kann Statusinformationen zurück an Graylog senden. Über die Aktivierung der entsprechenden Funktion können Metriken wie Load oder auch die IP Adresse des Hosts, auf dem Sidecar läuft, gesendet werden. Des Weiteren sind auch Metriken enthalten, die für die Stabilität des Systems wichtig sind, z. B. Disk Volumes mit mehr als 75 % Füllstand. Zusätzlich kann per Aktivierung eine Liste mit Directories in der Graylog Weboberfläche angezeigt werden, worüber eingesehen werden kann, welche Dateien zum Sammeln bereit stehen. Diese Liste wird periodisch aktualisiert.
  • Für Sidecar existieren .deb und .rpm Packages sowie entsprechende Windows-Installer.

 

Log Collectors für Sidecar

Graylog umfasst unter anderem per Default Collector Konfigurationen für Filebeat, Winlogbeat oder NXLog (siehe untenstehende Liste). Es können aber auch weitere, eigene Collector Backends eingebracht werden wie z. B. sysmon, auditd oder packetbeat.

  • Beats on Linux: Filebeat und andere Beats
  • Beats on Windows: Im Windows Sidecare Package ist Filebeat und Winlogbeat bereits enthalten.
  • NXLog on Ubuntu
  • NXLog on CentOS
  • NXLog on Windows

 

Wir haben Euer Interesse an Graylog geweckt? Es haben sich Fragen aufgetan zu Eurer bestehenden Graylog-Umgebung? Dann her damit! Schreibt uns einfach über unser Kontaktformular oder an sales@netways.de. Auch per Telefon sind wir für Euch unter der 0911 / 92885-66 zum Thema Graylog erreichbar.

Quelle Titelbild: pixabay.com / Creator: Murmel

Graylog: Basics für eine Best Practice Installation

Graylog hat hier einiges an Best Practice definiert, die Euch dabei hilft, eine stabil und sicher laufende Installation aufzubauen. Ein Hauptaugenmerk liegt dabei auf der Anzahl der Nodes, die für eine produktiv eingesetzte Umgebung folgendermaßen aussieht:

  • mehrere Graylog Nodes mit evtl. vorgeschaltetem Loadbalancer. Hier sollte auch im Nachhinein immer wieder über entsprechende Skalierungen oder Performance-Optimierungen nachgedacht werden.
  • jeder Graylog Node ist an die MongoDB Datenbank angeschlossen. Die MongoDB Instanzen sollten als Replica Set aufgesetzt sein.
  • ein Elasticsearch Cluster bestehend aus mindestens drei Nodes, um hier mit einem Quorum arbeiten zu können. (Vermeidung von Split Brain!)
  • ein Browser Eurer Wahl für den Zugriff auf die Graylog Web GUI

 

Hier eine schematische Darstellung einer Produktivumgebung:

Quelle: https://docs.graylog.org/docs/architecture

Des Weiteren sollten Log-Daten mithilfe der geeigneten Tools, z. B. syslog, GELF oder den Beats in Graylog wandern.  Zusätzlich wird ein Loadbalancer empfohlen, über den die gesamte Kommunikation mit Graylog erfolgt und somit eine Verteilung der Last ermöglicht und die Performance optimiert. Die Kommunikation umfasst hierbei alle Aufrufe über den Browser per HTTP(S) sowie die Weiterleitung der Log-Dateien an die vorhin genannten Graylog Nodes.

Wer hier tiefer einsteigen möchte, dem seien die folgenden Links zur Graylog Dokumentation empfohlen:

 

Natürlich könnt Ihr Euer KnowHow auch mit unserer Unterstützung aufbauen und erweitern! Ihr benötigt z. B. Unterstützung bei der Skalierung Eurer Umgebung? Ihr habt neue Systeme, deren Log Daten in Graylog laufen sollen? Ihr möchtet auf Graylog Enterprise umsteigen und benötigt eine Lizenz? Mit all diesen Fragen könnt Ihr einfach auf uns zukommen über unser Kontaktformular oder per Mail an sales@netways.de.

Infos zu Schulungen und deren Buchung zum Thema Graylog könnt Ihr hier finden: Graylog Schulung

Log Management mit Graylog

Graylog ist eines der Open Source Log Management Produkte aus dem NETWAYS Portfolio. Wir bieten hierzu sowohl Consulting-Dienstleistungen als auch Schulungen an. Im Consulting unterstützen wir Kunden vor allem

  • bei der Konzeptionierung und dem Sizing der Umgebung
  • dem initialen Aufbau
  • der Skalierung bzgl. Performance und Verfügbarkeit
  • Lösen von Problemstellungen
  • Erweitern des Funktionsumfangs, z. B. bei der Einrichtung der Graylog Enterprise Features

 

Im obigen Screenshot sieht man sehr schön die Anzahl der eingegangenen Log Messages im dargestellten Zeitraum. Darüber findet man sowohl die Suchleiste zum Filtern nach bestimmten Kriterien als auch die Möglichkeit, den zeitlichen Bereich individuell abzustecken.

 

 

 

 

 

 

 

 

 

Im folgenden möchten wir Euch einen ersten Überblick geben, was Graylog an Funktionen mitbringt und wie es Euch im alltäglichen Umgang mit Log Daten unterstützt:

Eingesetzt werden kann Graylog vor allem auf den Gebieten Security, Compliance, IT Operations und DevOps: Alle Log-Daten können mit einer Lösung kombiniert, angereichert, korreliert, abgefragt und visualisiert werden. Durch diese Möglichkeiten können Gefahren erkannt und gebannt, Audits vereinfacht, Downtimes verhindert und die Komplexität im Umgang mit Log-Daten reduziert werden.

Graylog ist also die zentrale Stelle zur Verarbeitung von Log-Dateien und den darin enthaltenen Log-Daten. Daraus ergeben sich ganz klar Mehrwerte sowohl für Techies als auch für das Management:

  • alle Log-Daten an einem Ort
  • tiefgreifende Analyse von Log-Daten durch das Erstellen und Kombinieren individuell erstellter Searches
  • Echtzeitverarbeitung von Searches
  • Exportieren von Resultaten anhand von Reports
  • Visualisierung der Log-Daten anhand von Widgets und Dashboards
  • schnelle Resultate durch verteilte Multithread Search Workflows sowie der Wiederverwendbarkeit bereits erstellter Elemente
  • Alarmierung anhand individuell definierter Events, gleichzeitigem Eintreten oder auch Ausbleiben von Events

 

Wir haben Euer Interesse an Graylog geweckt? Es haben sich Fragen aufgetan zu Eurer bestehenden Graylog-Umgebung? Dann her damit! Schreibt uns einfach über unser Kontaktformular oder an sales@netways.de. Auch per Telefon sind wir für Euch unter der 0911 / 92885-66 zum Thema Graylog erreichbar.

NETWAYS Webinar Plan 2022 – Phase 1

Es ist wieder soweit: In 2022 starten wir wieder voll durch mit neuen Webinaren rund um unsere angebotenen Dienstleistungen von Icinga, über Graylog bis hin zu Elastic. Den Fokus legen wir dabei auch wie üblich auf einen einfachen Einstieg und im späteren Verlauf auf komplexere Themen.

Anfangen werden wir mit einigen Webinaren für Icinga for Windows – die Lösung von Icinga, um Windows Systeme und Microsoft Produkte zu überwachen. Die folgenden Termine stehen dabei schon fest:

Für Icinga selbst werden im Laufe des Jahres dann noch eigene Webinare zum Icinga Director, der vSphereDB sowie dem Reporting Modul folgen – daher am besten direkt unseren YouTube Kanal abonnieren und die Glocke aktivieren.

Darüber hinaus, haben wir noch eine Webinar-Serie zu jeweils Elastic und Graylog geplant, welche die Grundfunktionalitäten sowie Erstinstallation, aber auch spätere Integrationen, Dashboard Erstellung und Auswertungen aufzeigt. Hierzu folgen in den nächsten Wochen weitere Informationen.

Wie immer freuen wir uns über eine rege Teilnahme sowie Input für Themen, welche wir vorstellen können!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

OpenSearch: Woher kommen die Informationen

OpenSearch: Jetzt kommt was rein in Runde II

Nach dem wir das Cluster erfolgreich in Betrieb genommen haben, wollen wir zunächst prüfen auf welchem Weg wir Informationen und Ereignisse aus dem klassischen Log-Management einliefern können. Laut der Kompabilitäts-Matrix der Projektseite sind wir hier aktuell etwas limitiert.

Logstash und Filebeat sind somit in alten Versionen einsetzbar. Gerade beim Filebeat ist dies weniger schön, da einige Module und Funktionen in der unterstützen Version noch in einem Beta-Stadium sind. Auch werden längst nicht alle teile Unterstützt. Damit die beiden Elastic Stack Werkzeuge überhaupt mit dem OpenSearch reibungsloser zusammenspielen, sollte die folgende Einstellung für die Kompatibilität in der Konfiguration vorgenommen werden:

[code lang=“plain“]
override_main_response_version: true
[/code]

Am einfachsten funktioniert es mit dieser Konfiguration in eurer Docker-Compose Datei:

[code lang=“plain“]
environment:
– cluster.name=opensearch-cluster
– node.name=opensearch-node1
– discovery.seed_hosts=opensearch-node1,opensearch-node2
– cluster.initial_master_nodes=opensearch-node1,opensearch-node2
– bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
– compatibility.override_main_response_version=true
– "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
[/code]

Damit erspart ihr euch einiges an Frust 😉

Logstash

Bei Logstash empfiehlt es sich auf keinen Fall das Projekt-Tarball zu verwenden! Für Logstash solltet ihr die Version 7.13.4 nutzen und auf jeden Fall das Plugin von „ruby.org“ nachinstallieren. Auf einem Debian System installiert ihr Logstash und das notwendige Plugin wie folgt:

[code lang=“plain“]
root@buster:~# wget https://artifacts.elastic.co/downloads/logstash/logstash-7.13.4-amd64.deb
root@buster:~# dpkg -i logstash-7.13.4-amd64.deb
root@buster:~# /usr/share/logstash/bin/logstash-plugin install logstash-output-opensearch
[/code]

Eine mögliche Konfiguration könnte dann wie folgt aussehen:

[code lang=“plain“]
input {
file {
path => "/tmp/json-output"
}
}

filter {
json {
source => "message"
}
}

output {
opensearch {
hosts => "https://192.168.2.42:9200"
user => "admin"
password => "admin"
index => "logstash-logs-%{+YYYY.MM.dd}"
ssl_certificate_verification => false ## ich habe hier keinen Fokus auf eine korrekte Zertifikats-Handhabung gelegt.
}
}
[/code]

Filebeat

Beim Filebeat bleibt uns nichts anderes übrig als auf Version OSS-7.12.1 zu setzen. Unter Debian machen wir das wie folgt:

[code lang=“plain“]

$ wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-oss-7.10.2-amd64.deb

$ dpkg -i filebeat-oss-7.10.2-amd64.deb

[/code]

In diesem Szenario wollen wir versuchen mit einem Module zu arbeiten, Pipelines zu laden, das ILM zu nutzen und das Template zu verwenden.

Was auf jeden Fall nicht ging:

  • Laden von ILM-Policies (war für mich zum testen des Zeitpunktes nicht möglich, deshalb gibt es einen eigenen Artikel dazu)
  • Laden von Dashboards in das Kibana

Nun gut, legen wir mal mit dem los was geht. Wir konfigurieren unsern Filebeat aktivieren das Modul und dann sehen wir weiter.

  • Unsere Filebeat Konfiguration:

    [code lang=“plain“]
    filebeat.inputs:
    filebeat.config.inputs:
    enabled: true
    path: inputs.d/*.yml
    filebeat.config.modules:
    path: ${path.config}/modules.d/*.yml
    reload.enabled: false
    output.elasticsearch:
    hosts: ["https://192.168.2.42:9200"]
    ssl.verification_mode: none
    username: "admin"
    password: "admin"
    processors:
    – add_host_metadata:
    when.not.contains.tags: forwarded
    – add_cloud_metadata: ~
    – add_docker_metadata: ~
    – add_kubernetes_metadata: ~
    logging.level: info
    logging.to_files: true
    logging.files:
    path: /var/log/filebeat
    name: filebeat
    keepfiles: 7
    permissions: 0644
    setup.kibana:
    host: "http://192.168.2.42:5601"
    username: admin
    password: admin
    headers:
    securitytenant: global
    setup.template.enabled: true
    setup.template.settings:
    index.number_of_shards: 1
    setup.dashboards.enabled: false
    setup.dashboards.url: "http://192.168.2.42:5601"
    setup.ilm.enabled: false
    [/code]

    Wichtig ist hier das setup.ilm.enabled: false nur so kann ein erfolgreicher Start und INIT erfolgen.

  • Aktivieren des System-Module:

    [code lang=“plain“]
    $ filebeat modules enable system
    [/code]

  • Danach laden wir noch das Pattern und das Template, dass ILM und die Dashboards werden nicht angelegt

    [code lang=“plain“]
    filebeat -e setup system
    [/code]

    Hier wird deutlich, dass die Kibana API in Opensearch Dashboards nicht kompatible ist:

    [code lang=“plain“]
    ….
    2021-11-24T22:59:30.039+0100 INFO eslegclient/connection.go:99 elasticsearch url: https://192.168.2.42:9200
    2021-11-24T22:59:30.039+0100 WARN [tls] tlscommon/tls_config.go:98 SSL/TLS verifications disabled.
    2021-11-24T22:59:30.039+0100 WARN [tls] tlscommon/tls_config.go:98 SSL/TLS verifications disabled.
    2021-11-24T22:59:30.647+0100 INFO [esclientleg] eslegclient/connection.go:314 Attempting to connect to Elasticsearch version 7.10.2
    ILM policy and write alias loading not enabled.

    2021-11-24T22:59:30.654+0100 INFO template/load.go:183 Existing template will be overwritten, as overwrite is enabled.
    2021-11-24T22:59:30.722+0100 INFO template/load.go:117 Try loading template filebeat-7.12.1 to Elasticsearch
    2021-11-24T22:59:31.106+0100 INFO template/load.go:109 template with name ‚filebeat-7.12.1‘ loaded.
    2021-11-24T22:59:31.107+0100 INFO [index-management] idxmgmt/std.go:298 Loaded index template.
    Index setup finished.
    Loading dashboards (Kibana must be running and reachable)
    2021-11-24T22:59:31.108+0100 INFO kibana/client.go:119 Kibana url: http://192.168.2.42:5601
    2021-11-24T22:59:31.230+0100 INFO kibana/client.go:119 Kibana url: http://192.168.2.42:5601
    2021-11-24T22:59:31.242+0100 ERROR instance/beat.go:971 Exiting: Kibana API is not available in Kibana version 1.2.0
    Exiting: Kibana API is not available in Kibana version 1.2.0
    [/code]

  • Start des Filebeat-Service

    [code lang=“plain“]
    $ systemctl start filebeat
    [/code]

Und sehen wir was?

Nach dem erfolgreichen Start sehen wir auch schon die ersten Ergebnisse.

Opensearch Dashboards Document

Nun ja, schwer war das ganze jetzt erst mal nicht und wir haben auf eine bereits aus der Elastic Stack Welt vertraute Art und weise in den neuen Fork OpenSearch Informationen in Form eines System-Logs eingeliefert. Jetzt sind wir in der Lage gänzlich, wie vielleicht schon gewohnt, mit den Daten zu interagieren.

Dies verifizieren wir zusätzlich in einem weiteren Video:

 

Der Gong ertönt!

Die Runde war eine gänzlich einfache Übung. Wir haben uns hier mit bereits bekannten Werkzeugen beschäftigt, den Gegner über die Runde bei Laune gehalten und auch an seine Grenzen getrieben. Jedoch gilt es jetzt die Schwachstellen zu identifizieren und zu studieren um den Gegner zu knacken. Mit anderen Worten, dies war nicht die letzte Runde. In den kommenden Runden werden wir uns SLM/ILM und andere Themen bemühen. Und dann hoffentlich auch bald mit dem bereits angekündigten System-Paketen.

Wenn Euch das, was ihr jetzt schon gelesen habt noch mehr reizt und ihr schneller zum Sieg über ein KO in der nächsten Runde erringen wollt, dann meldet Euch doch einfach bei unserem Sales Team sales[at]netways.de. Wir helfen Euch in einem PoC (Proof of Concept) gleich von Runde I an mit zu kämpfen! Nach den letzten Monaten intensiver OpenSearch Evaluierung bin ich der Trainer der euch “State of the Art” Euren “Kampf gegen die Informationsflut” gewinnen lässt. Ihr dürft gespannt sein auf Runde III.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.