Beats und Logstash verwenden, um Logs an ElasticSearch zu senden

Beats und Logstash verwenden, um Logs an ElasticSearch zu senden

  • ITOps & DevOps
5 Minuten Lesezeit Aktualisiert Jul 5, 2019

Auf einen Blick: Anweisungen zum Senden von Logs an ElasticSearch mit Beats und Logstash werden bereitgestellt, mit Fokus auf das Parsen von nginx-Webserver-Logs. Beats wandelt Logs in JSON um, während Logstash das Parsing übernimmt und die Daten an ElasticSearch sendet.

  • Beats überwacht Logdateien und schickt sie zum Parsen an Logstash.
  • Logstash hört sich Beats an und formatiert die Logs, bevor er sie an ElasticSearch sendet.

Hier erklären wir, wie man Logs mit Beats (auch File Beats und Logstash genannt) an ElasticSearch sendet. Wir werden nginx-Webserver-Logs analysieren, da dies einer der einfachsten Anwendungsfälle ist. Wir verwenden außerdem Elastic Cloud anstelle unserer eigenen lokalen Installation von ElasticSearch. Aber die Anweisungen für eine eigenständige Installation sind dieselben, außer dass man bei einer eigenständigen Installation in den meisten Fällen keine Benutzer-ID und Passwort verwenden muss.

Wir haben bereits darüber geschrieben , wie man nginx-Logs mit Beats selbst, ohne Logstash, parsen. Man fragt sich vielleicht, warum man beides braucht. Die Antwort ist, dass Beats die Logs in JSON umwandelt, das von ElasticSearch geforderte Format, aber es parst das GET- oder POST-Nachrichtenfeld nicht auf den Webserver, um URL, Operation, Standort usw. herauszuziehen. Mit Logstash kann man all das machen.

  • Beats ist so konfiguriert, dass er auf neue Logeinträge achtet, die in /var/logs/nginx*.logs geschrieben werden.
  • Logstash ist so konfiguriert, dass es Beat anhört, diese Logs analysiert und sie dann an ElasticSearch sendet.

Laden Sie Beats herunter und installieren Sie es:

    wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.1.1-amd64.deb
sudo dpkg -i filebeat-7.1.1-amd64.deb

Du musst das nginx Beats-Modul nicht aktivieren, da wir Logstash das Parsen überlassen werden.

Bearbeite die /etc/filebeat/filebeat-Konfigurationsdatei:

Sie möchten die oberen und unteren Abschnitte der Datei ändern. Unten zeigen wir das in zwei separaten Abschnitten. Zuerst die oberen:

Die wichtigen Punkte sind:

 aktiviert: true

Sonst bringt es nichts.

 - /var/log/nginx/*.log

Du kannst hier auflisten, welche Ordner du beobachten solltest.  Setze jeden einzeln in eine Zeile. In diesem Fall listen wir nur nginx auf.

    #=========================== Filebeat inputs =============================

filebeat.inputs:

# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.

- type: log

  # Change to true to enable this input configuration.
  enabled: true

  # Paths that should be crawled and fetched. Glob based paths.
  paths:
    - /var/log/nginx/*.log

Hier möchten Sie:

  • Wenn wir die ElasticSearch-Ausgabe herausnehmen, verwenden wir logstash, um dort zu schreiben.
  • Entrem die Logstash-Linien.
  • Sag Beats, wo du LogStash findest.
  • Stelle sicher, dass du auch die Zeile ##output.elasticsearch remst.
    #-------------------------- Elasticsearch output ------------------------------
##output.elasticsearch:
  # Array of hosts to connect to.
  # hosts: ["localhost:9200"]

  # Enabled ilm (beta) to use index lifecycle management instead daily indices.
  #ilm.enabled: false

  # Optional protocol and basic auth credentials.
  #protocol: "https"
  #username: "elastic"
  #password: "changeme"

#----------------------------- Logstash output --------------------------------
output.logstash:
  # The Logstash hosts
  hosts: ["localhost:5044"]

Jetzt starte Beats. Das -e sagt ihm, Logs in Stdout zu schreiben, damit du sehen kannst, dass es funktioniert und auf Fehler überprüft wird.

    sudo /usr/share/filebeat/bin/filebeat -e -c /etc/filebeat/filebeat.yml

Installieren Sie LogStash

    cd /usr/share
sudo mkdir logstash
sudo wget https://artifacts.elastic.co/downloads/logstash/logstash-7.1.1.tar.gz
sudo tar xvfz logstash-7.1.1.tar.gz

Jetzt bearbeite /usr/share/logstash/logstash-7.1.1/config/nginx.conf

Die zu beachten Punkte sind:

Eingabe Sag logstash, sie sollen Beats auf Port 5044 hören

filter {

grok {

Um das zu verstehen, müsstest du Rok verstehen. Versuch das noch nicht. Es ist ein Dateiparser-Tool. Es versteht im Grunde verschiedene Dateiformate und kann erweitert werden. Nutze das untenstehende Beispiel, denn selbst die Beispiele in der ElasticSearch-Dokumentation funktionieren nicht. Stattdessen verwenden alle Technikautoren dasselbe funktionierende Beispiel.

Ausgabe {

elasticsearch {

Moderatoren => ["https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243"]

Benutzer => "elastisch"

Passwort => "xxxxxxxx"

index => "logstash-%{+YYYYY. MM.dd}"

}

stdout { codec => rubydebug }

}

Dieser Teil ist enttäuschend, denn ElasticSearch erlaubt es nicht, die cloud.id und cloud.auth zu verwenden, um sich mit ElasticSearch zu verbinden, ebenso wie Beats. Man muss also die URL, die Benutzer-ID und das Passwort angeben. Verwenden Sie dieselbe Benutzer-ID und das gleiche Passwort, mit denen Sie sich cloud.elastic.com anmelden.

Man könnte auch einen weiteren Benutzer erstellen, aber dann müsste man diesem Benutzer die Befugnis geben, Indizes zu erstellen. Die Verwendung des elastischen Benutzers bedeutet also, den Super-Nutzer als kurzes Protokoll zu verwenden.

Die Indexlinie erlaubt es, den Index zu einer Kombination aus den Wörtern logstash und dem Datum zu machen. Das Ziel ist es, ihm einen sinnvollen Namen zu geben. Vielleicht wäre nginx* besser, da du Logstash nutzt, um mit allen möglichen Logs und Anwendungen zu arbeiten.

Codec = RubyDeBug schreibt die Ausgabe in Stdout, sodass du sehen kannst, ob es funktioniert.

    input {
  beats {
    port => 5044
    host => "0.0.0.0"
  }
}

filter {
 grok {
   match => [ "message" , "%{COMBINEDAPACHELOG}+%{GREEDYDATA:extra_fields}"]
   overwrite => [ "message" ]
 }
 mutate {
   convert => ["response", "integer"]
   convert => ["bytes", "integer"]
   convert => ["responsetime", "float"]
 }
 geoip {
   source => "clientip"
   target => "geoip"
   add_tag => [ "nginx-geoip" ]
 }
 date {
   match => [ "timestamp" , "dd/MMM/YYYY:HH:mm:ss Z" ]
   remove_field => [ "timestamp" ]
 }
 useragent {
   source => "agent"
 }
}

output {
  elasticsearch {
    hosts => ["https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243"]
    user => "elastic"
    password => "xxxxxxxx"
    index => "logstash-%{+YYYY.MM.dd}"
  }
 stdout { codec => rubydebug }
}

Starte jetzt Logstash im Vordergrund, damit du sehen kannst, was vor sich geht.

    sudo /usr/share/logstash/logstash-7.1.1/bin/logstash -f /usr/share/logstash/logstash-7.1.1/config/nginx.conf

Angenommen, du hast einen Teil des nginx-Webservers und einige Logs, die nach etwa einer Minute in /var/log/nginx geschrieben werden, sollte er anfangen, Logs an ElasticSearch zu schreiben. Oder du kannst https://raw.githubusercontent.com/respondcreate/nginx-access-log-frequency/master/example-access.log herunterladen, um ihm einige Beispieleinträge zu geben.

Exportiere dein Passwort und deine ElasticSearch-Benutzer-ID in die Umgebungsvariable:

    export pwd="elastic:xxxxx"

Dann suchst du ElasticSearch ab und du solltest sehen, dass der logstash*- Index erstellt wurde.

    curl --user $pwd -XGET https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243/logstash-2019.06.19-000001/_search?pretty

Jetzt können Sie diesen ElasticSearch-Index abfragen und einen Datensatz ansehen. Im Folgenden haben wir den Datensatz verkürzt, sodass Sie sehen können, dass der Eintrag des Nachrichtenprotokolls in einzelne Felder geparst wurde, die Sie dann abfragen können, wie request (die URL) und das Verb (GET, PUT usw.).

    curl --user $pwd -X GET 'https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243/logstash-2019.06.19-000001?pretty'
    {
        "_index" : "logstash-2019.06.19-000001",
        "_type" : "_doc",
        "_id" : "9RZDcWsBDzKZEQI4C4Qu",
        
…

          "verb" : "GET",
          "input" : {
            "type" : "log"
          },
          "auth" : "-",
          "source" : "/var/log/nginx/another.log",
          "device" : "Other",
        

….

          "geoip" : {
            "timezone" : "Europe/Moscow",
            "latitude" : 55.7386,
            "location" : {
              "lon" : 37.6068,
              "lat" : 55.7386
            },
            "longitude" : 37.6068,
            "country_code2" : "RU",
            "ip" : "46.160.190.178",
            "continent_code" : "EU",
            "country_code3" : "RU",
            "country_name" : "Russia"
          },
          


…


          "response" : 200,
          "os_name" : "Windows",
          "major" : "52",
          "agent" : "\"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36\"",
          "build" : "",
          "clientip" : "46.160.190.178",
          "@version" : "1",
          "message" : "46.160.190.178 - - [19/Jun/2019:12:39:52 +0000] \"GET / HTTP/1.1\" 200 481 \"-\" \"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36\"",
          

…

          "request" : "/",

In Kibana sieht es so aus:

Und so, wenn es erweitert wird:

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus ITOps & DevOps

Abonnieren Sie The Brief

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Danke

Sie haben The Brief abonniert
Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.