- OpenSearch: Aller Anfang ist schwer!
- OpenSearch: Woher kommen die Informationen
- OpenSearch: Wie verwalten wir unsere Daten?
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.
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.
0 Kommentare