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:
ElasticSearch-Leitfaden
- ElasticSearch Tutorial für Anfänger: ElasticSearch Grundlagen
- Verwendung von Apache Hive mit ElasticSearch
- Verwendung von ElasticSearch mit Apache Spark
- Curl ElasticSearch Befehle Spickzettel
- Spark ElasticSearch Hadoop-Update und Upsert Beispiel und Erklärung
- Wie man Apache Spark-Daten mit Python in ElasticSearch schreibt
- ElasticSearch-Suchsyntax sowie boolesche und Aggregationssuchen
- ElasticSearch verschachtelte Abfragen: Wie man nach eingebetteten Dokumenten sucht
- ElasticSearch Joins: Has_Child, Has_parent Abfrage
- Wie man einen elastischen Cluster der Version 7 einrichtet
- Wie man Filebeat für nginx und ElasticSearch konfiguriert
- Beats und Logstash verwenden, um Logs an ElasticSearch zu senden
- Wie man eine CSV-Datei mit Logstash in ElasticSearch lädt
- ElasticSearch-Aggregationen erklärt
- Was ist der ELK-Stack?
- Logstash 101: Verwendung von Logstash in einer Datenverarbeitungspipeline
- Verwendung von Kibana zur Ausführung von Abfragen in ElasticSearch mit Lucene und Kibana Query Language
- ElasticSearch Maschinelles Lernen
- Wie man Elastic Enterprise Search installiert
- Wie man Elastic Enterprise Search mit GitHub verwendet
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.