pixel
Seite wählen

NETWAYS Blog

Graylog Operations vs. Security. Und was ist mit Opensearch?

von | Nov 10, 2022 | , ,

Bereits im Juni hatte mein Kollege Christian Stein vom neuen Versions-Model bei Graylog berichtet. Graylog Enterprise ging in Graylog Operations und in Graylog Security auf.

Eine damit große verbundene Neuerung war die Unterstützung von Opensearch (ein Fork von Elasticsearch). Opensearch kann nun in allen Versionen Graylog Open Source, Graylog Operations und Graylog Security verwendet werden. Aber was bedeuten die einzelnen Versionen und warum der Opensearch Support.

Warum Opensearch?

Elastic hatte Anfang 2021 die OSS-Versionen des Stacks abgekündigt. Dies geschah als Reaktion auf die Auseinandersetzung mit AWS. Somit war elasticsearch-oss 7.10.2 die letzte reine Open Source Version von Elasticsearch. Für viele Service-Anbieter  wie z.B. AWS war das eine große Herausforderung, denn mit der neuen DUAL-License kann elasticsearch x-pack unter anderem nicht als kommerzieller Service bereitgestellt werden. Die Reaktion hierauf war der Fork Opensearch.

Graylog hat bis heute einzig elasticsearch-oss 7.10.2 (x-pack funktioniert auch) als unterstützte Version aufgeführt.

Gründe für Opensearch

  • Elasticsearch 7.10.2 ist schon lange abgekündigt, also EOL. Somit ergibt sich über die Zeit eine Liste von möglichen CVE
  • Opensearch ist unter einer Apache License v2 Open Source
  • Opensearch hat in den aktuellen Versionen 1.3.5 und 2.2 ein Machine-Learning Plugin, welches eine ML basierte Anomalie-Erkennung möglich macht.

Und genau letzteres ist vermutlich der mit größte Punkt, denn in Graylog Security gibt es eine auf diesem Plugin gestützte Anonmalie-Erkennung.

Wichtig zu wissen: Graylog unterstütz nur Opensearch Version 1.3.5

Empfehlung

Es ist nicht absehbar, dass die offizielle Unterstützung von Elasticsearch in neueren Version in naher Zukunft oder vielleicht überhaupt realisiert wird. Zumindest gibt es Stand heute keine Anzeichen dafür. Daher seid Ihr auf der sicheren Seite, wenn Ihr direkt mit Opensearch beginnt oder mittelfristig eine Migration von Elasticsearch zu Opensearch plant und durchführt. Eine Beschreibung für die Migration ist in der Graylog-Dokumentation hinterlegt. Hierbei ist einiges zu beachten. Also ist das Thema Opensearch auch unabhängig von der Verwendung einer Graylog Security Variante zu sehen.

Graylog Operations vs. Security

Schauen wir hier noch mal genauer in den Vergleich

Graylog Operations

Graylog Operations erweitert Graylog Open Source um folgende Punkte:

  • Audit-Log: Protokollierung von Adminstoren und Benutzer-Vorgängen in Graylog selbst
  • Log-View: Real-Time Ansicht der Logs
  • Archive-Funktion: Indices lassen sich zusätzlich vor dem löschen, sichern und später wieder herstellen.
  • Teams: Benutzer lassen sich in sogenannten Teams mit AD-Gruppen abbilden, welche in den Berechtigungen genutzt werden können
  • Event-Correlation: Definierte Events/Alerts lassen sich bei der Detektierung miteinander verknüpfen.. Dies ermöglicht eine genauere detektierung
  • Erstellung von Reports
  • Custom-Themes
  • Graylog-Forwarder
  • Illuminate: Eine Art Content und Processor Paket, welches eine Aufbereitung der Informationen nach dem GIM und SIEM mit sich bringt, Ebenfalls befinden sich für einige Produkte wie z.B. Windows oder Fortigate Implementierungen zur Datenaufbereitung in diesem Bundle. Das Umfasst dann auch neben der Aufbereitung Dashboards und Events.

Graylog Security

Graylog Security beinhaltet alles was Graylog Operations beinhaltet und die bereits erwähnte Anomalie-Erkennung.

Diese Anomalie-Erkennung bringt einige Dashboards und bereits vorgefertigte Machine-Learning Regeln mit, welche zu den Inhalten im Illuminate Bundle passen.

Hinweis: Zum jetzigen Zeitpunkt lassen sich keine eigenen Regeln für die Anomalie-Erkennung schreiben.

Zum Ende bleibt zu sagen…

Dieser Blog-Post war eine sehr theoretische Aufstellung der „großen“ Änderungen in Graylog in diesem Jahr. Bestimmt kommt auch noch das ein oder andere mal ein Blog-Post mit einem technischen Tiefgang wohl dann zum Einsatz von Opensearch mit Graylog bzw. eine Post zur Migration. Denn die Leichtigkeit bei der Installation und der Betreuung eines Opensearch-Clusters im Graylog-Kontext, ist noch ausbaufähig. Wer sein Opensearch-Cluster nicht im Griff hat, der kann in Graylog nicht gewinnen. Das ist ein Fakt.

Aber Ihr seid nicht alleine. Wenn Ihr Unterstützung bei der Umsetzung einer Graylog-Umgebung oder einer Migration von Elasticsearch auf Opensearch benötigt, meldet euch einfach bei den Kolleginnen und Kollegen von Sales. Das Team von Professionell Services hilft euch gerne bei euren vorhaben.

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.
Lies mehr von Daniel und triff unser Team

OpenSearch: Wie verwalten wir unsere Daten?

von | Mai 26, 2022 |

OpenSearch: Ordnung muss sein! III

In der letzten Runde haben wir uns mit der Einlieferung der Daten und der ersten Schritte im OpenSearch Dashboards gewidmet. Heute wollen wir uns einmal mit der Haushaltung der Informationen befassen. Der erste wichtigste Unterschied ist die Bezeichnung. Im Elasticsearch sprechen wir vom ILM (Index Lifecycle Management), wohin gegen wir im OpenSearch Plugin von ISM (Index State Management) sprechen. Beide behandeln aber den selben Nenner „Policies“ für die Verwaltung der Vorhaltung der Daten.

ISM erklärt

Leider ist die Dokumentation zur ISM nach wie vor sehr Schlank. Alle Teile sind sehr knapp beschrieben.

Eine ISM Policy gliedert sich wie folgt auf:

  • Policy Info: ID und Beschreibung
  • Error Notification: Benachrichtigungen bei Fehlschlag
  • ISM Templates: Hier werden die Index-Pattern definiert, auf die die ISM Policy angewendet werden soll
    • Hierbei ist wichtig, dass der Index initial mit einem Hyphen Suffix angelegt wird z.B./e.g.: „myindex-00001“ (Regex-Muster: `^.*-\\d+$`)
  • States: Mit States werden die einzelnen Phasen eines Index definiert. In den States werden „Actions“ und „Transitions“ gesetzt. Die Transition kann zum Beispiel einer Action Rollover folgen, um den  Index in den nächsten State zu setzen. In dem neuen State wird der Index dann zum Beispiel auf „Read Only“ gesetzt oder der „Replica Count=0“ gesetzt.

Ring frei

Wir wollen uns das ganze mal an einem Beispielablauf anschauen. Leider war es für mich mit den bisher genutzten Mitteln nicht 100% automatisierbar, auch die Hilfen im Forum und dem restlichen Web waren nicht sehr aufschlussreich. Folgend setzten wir uns mit dem erstellen eines ISM mit entsprechenden Rollover, dass was wir in der Produktion immer wollen.

Bedingungen für die Runde

Einlieferung

Zur Einlieferung nutzen wir den Fluent Bit wie folgt Konfiguriert:


[INPUT]
name cpu
tag cpu.local

# Read interval (sec) Default: 1
interval_sec 1

[INPUT]
name tail
path /tmp/json-output
parser json

[OUTPUT]
name opensearch
match *
host 192.168.2.42
port 9200
index fluentbit-000001
type _doc
http_user admin
http_passwd admin
tls On
tls.verify Off

Wichtig ist hier beim Output, dass wir entsprechend Initial einen Hyphen am Ende mit einem Pattern haben welches sich hochzählen lässt.

Index Template für den Rollover

Für das Rollover handling setzen wir einen Rollover-alias. Dieser muss gesetzt sein. Dies regeln wir über ein Template


PUT _index_template/ism_rollover
{
 "index_patterns": ["fluentbit-*"],
"template": {

  "settings": {
    plugins.index_state_management.rollover_alias": "fluentbit"
   }
 }
}

Hier ist es wichtig keinen Index-Alias zu setzen dieser wird nach dem des Start des ISM-Init auf den index manuell gesetzt. Das ist sehr wichtig. Denn wenn wir den alias im template definieren, dann bekommen wir keinen rollover. Der folgende Fehler wäre dann der Fall:


Rollover alias [fluentbit] can point to multiple indices, found duplicated alias [[fluentbit]] in index template [ism_rollover]

Anlegen der Policy

Nun können wir unsere Policy anlegen.

Erstellung von ISM-Policies

Aufgrund der Übersichtlichkeit erkläre ich hier das ganz im JSON:


{
"id": "test_flow",
"seqNo": 603481,
"primaryTerm": 10,
"policy": {
"policy_id": "test_flow",
"description": "A sample description of the policy",
"last_updated_time": 1653467076033,
"schema_version": 13,
"error_notification": null,
"default_state": "Hot",
"states": [
{
"name": "Hot",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"rollover": {
"min_doc_count": 50,
"min_index_age": "4m"
}
}
],
"transitions": [
{
"state_name": "Warm",
"conditions": {
"min_rollover_age": "5m"
}
}
]
},
{
"name": "Warm",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"read_only": {}
}
],
"transitions": [
{
"state_name": "Cold",
"conditions": {
"min_rollover_age": "10m"
}
}
]
},
{
"name": "Cold",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"force_merge": {
"max_num_segments": 1
}
},
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"replica_count": {
"number_of_replicas": 0
}
}
],
"transitions": [
{
"state_name": "DELETE",
"conditions": {
"min_rollover_age": "1h"
}
}
]
},
{
"name": "DELETE",
"actions": [
{
"retry": {
"count": 1,
"backoff": "exponential",
"delay": "1m"
},
"delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"fluentbit-*"
],
"priority": 1,
"last_updated_time": 1652268548245
}
]
}
}

Ich habe hier unterschiedlich States, eine Transition erfolgt immer in den darauf folgenden State, könnte aber auch umgekehrt werden. Bei der Berechnung der Zeitlichen Spanne ab wann eine Aktion oder Transition ausgeführt werden soll ist folgend immer auf den Rollover-Age zu setzen.

Weiter gehts…

Nach dem anlegen des Templates und der ISM Policy, starten wir den Fluent-bit. Danach sehen wir ziemlich zeitnah den INIT. Leider habe ich nur ein Bild wo den INIT des zweiten Index zeigt. Sorry.

Danach müssen wir den Index-Alias manuell setzen:


POST /_aliases
{
"actions" : [
{ "add" : { "index" : "fluentbit-000001", "alias" : "fluentbit" } }
]
}

Dann stoppen wir den Fluent-bit-Daemon und ändern den Index-Namen auf den Alias ab:


[OUTPUT]
name opensearch
match *
host 192.168.2.42
port 9200
index fluentbit
type _doc
http_user admin
http_passwd admin
tls On
tls.verify Off

Danach wird der Dienst wieder gestartet.

Diese Abfolge ist wichtig wird der Alias nicht gesetzt, schlägt uns der folgende Fehler auf:


Missing alias or not the write index when rollover [index=fluent-bit-000001]

Nun können wir die Runde entspannt laufen lassen. Die ISM Policy wird erfolgreich angewendet und wir sehen die einzelnen Transistions.

Managed Indices

Hilfen zur Analyse bei Fehlern

Folgend möchte ich euch noch ein paar hilfreiche API-Abfragen für die DEV-Tools liefern.

Prüfen der Aliases

Damit solletst du sehen ob dein Alias gesetzt ist.


GET _cat/aliases

ISM Erklärung

Dieser API-Punkt erklärt dir genau wie der ISM State für ein Index aussieht

GET _plugins/_ism/explain/fluentbit-000001

Abfrage ISM Policy

Dieser API-Punkt gibt dir deine Policy so zurück wie diese im Cluster gespeichert ist.

 GET _plugins/_ism/policies/test_flow

Der Gong ertönt!

Und wieder ist eine Runde rum. Diese Runde war nicht leicht, denn es galt verständlich sehr komplexes und dünn dokumentiertes Wissen zu transportieren. Auch die Tatsache, dass hier das verhalten im Vergleich zur Verwandschaft gänzlich anders ist.

Aber auch die Runde konnten wir mit ordentlich Punkten meistern. Auf die nächste Runde dürft Ihr gespannt sein, ich weis selbst noch nicht genau was uns erwartet. Weil es denke ich hilft gibt es auch noch ein Video.

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 IV.

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.
Lies mehr von Daniel und triff unser Team

OpenSearch: Woher kommen die Informationen

von | Nov 25, 2021 |

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:

override_main_response_version: true

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

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

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:

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

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

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.
  }
}

Filebeat

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


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

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

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: 
    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

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

  • Aktivieren des System-Module: 
    $ filebeat modules enable system
  • Danach laden wir noch das Pattern und das Template, dass ILM und die Dashboards werden nicht angelegt 
    filebeat -e setup system

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

    ....
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
  • Start des Filebeat-Service 
    $ systemctl start filebeat

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.
Lies mehr von Daniel und triff unser Team

OpenSearch: Aller Anfang ist schwer!

von | Nov 18, 2021 | ,

OpenSearch – Runde I

Worum geht es in der Serie? Wir wollen mit Euch erste Blicke in die frühen Versuche von OpenSearch und dessen Dashboard (OpenSearch Dashboards) werfen, welche je einen Fork durch AMAZON AWS von Elasticsearch-OSS 7.10.x (OpenSearch) und Kibana-OSS 7.10.x abbilden.

Wie es dazu kam, dürft Ihr in diesem Blog-Post von mir lesen. Dieses „Community“ Projekt könnte man, aufgrund der Hintergründe, als Nebenprodukt des Bezahl-Dienstes „Elasticsearch“ in der Amazon AWS Cloud bezeichnen, da es den Fortbestand dieses Dienstes sichern soll. Dieser war aufgrund der „Wehrhaftigkeit“ von Elastic gefährdet.

Nach über 8 Jahren Erfahrung mit Elastic Stack und Graylog, dachte ich mir zu Beginn des Jahres das wir mal mit OpenSearch in den Ring steigen. Mit der Zeit entwickelte sich der Trainings-Partner weiter und es gibt nun ein wenig her um davon zu berichten. Letzten Endes bleibt es aber auf unabsehbare Zeit dabei, dass OpenSearch und OpenSearch Dashboards, als „Open Source Community Projekt“ getarnte Quelle für den Amazon AWS Dienst dienen. Was bedeutet das es keine Support-Garantie, oder ähnliche Strukturen um diese Dienste aus dem Projekt-Kreis selbst geben wird. Allerdings treten schon die ersten Firmen auf, welche eine Support- (mit SLA), Consulting- und Fehlerbehebung als Service anbieten, jedoch bisher keine im deutschsprachigen Raum.

Worum geht also nun der erste Teil? Wir wollen uns mit OpenSearch und OpenSearch Dashboards auseinander setzen und Euch einen Weg zum ersten eigenen Betrieb aufzeigen.

Installationsquellen und Veröffentlichungen

Zum aktuellen Zeitpunkt gibt es tarballs für Linux: x64, ARM64, System-Pakete für FreeBSD: x64, ARM64, x86 und Docker-Images. Ein Release von stabilen Linux-Paketen und einem möglichen Paket-Repository ist für die nächste Veröffentlichung v1.2 am 16. November. 2021 angedacht, so zumindest der Fahrplan.

Im weiteren Verlauf werden wir uns für die ersten Versuche mittels Docker eine Testumgebung aufbauen. Zuerst wollen wir jedoch auf den Umfang von OpenSearch eingehen.

Funktionen von OpenSearch

OpenSearch ist in weiten Teilen mit Elasticsearch und Kibana aus der aktuellen Elastic-Stack Version in Bezug auf Templates und weiteren Funktionen gleich. Lediglich für die Einlieferung und der damit zusammen hängenden Funktionen gibt es wesentliche Unterschiede. Zum Zeitpunkt der Tests ist die Einlieferung nur mit Filebeat-OSS 7.12.1  oder logstash-7.13.2 in Verbindung mit dem Plugin „logstash-output-opensearch“ möglich.

Was hat nun funktioniert bzw. nicht?

  • Einliefern mit Standard-Inputs
  • Einliefern mit Modulen in OpenSearch
  • Laden der Ingest-Pipeline in OpenSearch
  • Einliefern mit Logstash (bedingt)
  • ILM und Index Management waren nicht möglich!

Letzteres sind nicht ganz so schöne Dinge, aber nun gut, später mehr.

Was ist denn wichtig und gleich aufgebaut wie in Elasticsearch?

  • Template API
  • Ingest Pipeline API
  • Index-Management (teilweise)

Folgende Plugins bringt OpenSearch mit sich:

  • opensearch-job-scheduler
  • opensearch-sql
  • opensearch-alerting
  • opensearch-security
  • opensearch-cross-cluster-replication
  • opensearch-performance-analyzer
  • opensearch-index-management
  • opensearch-knn
  • opensearch-anomaly-detection
  • opensearch-asynchronous-search
  • opensearch-reports-scheduler
  • opensearch-notebooks

Einige davon werden wir uns in Runde III genauer ansehen, diese Plugins bilden auch die Grundlage für einige Dashboard-Integrationen um z.B Alarmierungen, Notizen oder Berechtigungen in Form von Rollen und Benutzern zu verwalten. OpenSearch Dashboards nutzt somit die Plugins von OpenSearch.

Funktionen von OpenSearch Dashboards

Hier gibt es einiges Neues aber auch einiges was fehlt.

Folgend das Wichtigste und die neuesten Dinge:

  • Suche in den Daten
  • Dashboards
  • Visualisierungen
  • Reporting (NEU)
  • Notebooks (NEU)
  • Anomaly Detction
  • Index-Management; jedoch ohnne Index-Template Management!

 

Los Geht’s

Im folgenden Szenario gehen wir von einem Linux-Arbeitsplatz aus! Daher kommt gleich das Wichtigste zuerst! Wir gehen auch davon aus, dass eine funktionierende Docker-Umgebung auf dem Arbeitsplatz oder Zugriff auf eine solche besteht!

Die Container können übrigens in der richtigen Umgebung auch produktiv eingesetzt werden. Solche Umgebungen bekommt Ihr in Form von Kubernetes auch bei unseren Kollegen von NMS

Vorbereitung ist alles!

Für den Betrieb der Container brauchen wir, egal wie viel Last wir erzeugen, einen erhöhten „<code>vm.max_map_count</code> Wert.

Dies erledigt man wie folgt:

# entweder dauerhaft
$ sudo echo &quot;vm.max_map_count=262144&quot; &amp;amp;amp;gt;&amp;amp;amp;gt; /etc/sysctl.conf
$ sudo sysctl -p

# Oder temporär
$ sudo sysctl -w vm.max_map_count=262144
$ sudo sysctl -p

Wir setzen unsere Umgebung zusammen

Dafür benötigen wir nichts weiter als eine einfache Docker-Compose Beschreibung in einer Datei:

version: '3'
services:
opensearch-node1: # Wählt hier euren Namen für eure Knoten
image: opensearchproject/opensearch:latest # Lädt immer die letzte stabile Veröffentlichung eines Abbild
container_name: opensearch-node1
environment:
- cluster.name=opensearch-cluster # Euer Cluster-Name
- node.name=opensearch-node1 # Wählt hier euren Namen für eure Knoten
- discovery.seed_hosts=opensearch-node1,opensearch-node2 # Knoten zur Cluster erkennung
- cluster.initial_master_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
# - jedes weitere beliebige elasticsearch Einstellung wie Knoten-Typ oder Knoten Eigenschaften (node.attr.)
- &quot;OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m&quot; # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems
hard: 65536
volumes:
- opensearch-data1:/usr/share/opensearch/data # keine dauerhaften Daten! Pfad im Container
# Wollt hier die Knoten dauerhaft betreiben empfiehlt es sich einen dauerhaften lokalen Pfad abzubilden um die Daten nicht zu verlieren
# - ./srv/opensearch-data1:/usr/share/opensearch/data 
- 9200:9200
- 9600:9600 # required for Performance Analyzer
networks:
- opensearch-net
opensearch-node2:
image: opensearchproject/opensearch:latest
container_name: opensearch-node2
environment:
- cluster.name=opensearch-cluster
- node.name=opensearch-node2
- discovery.seed_hosts=opensearch-node1,opensearch-node2
- cluster.initial_master_nodes=opensearch-node1,opensearch-node2
- bootstrap.memory_lock=true
- &quot;OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m&quot;
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
volumes:
- opensearch-data2:/usr/share/opensearch/data  
networks:
- opensearch-net
opensearch-dashboards:
image: opensearchproject/opensearch-dashboards:latest
container_name: opensearch-dashboards
ports:
- 5601:5601
expose:
- &quot;5601&quot;
environment:
OPENSEARCH_HOSTS: '[&quot;https://opensearch-node1:9200&quot;,&quot;https://opensearch-node2:9200&quot;]'
networks:
- opensearch-net

volumes:
opensearch-data1: # bitte beides auskommentieren für dauerhafte Daten, siehe oben.
opensearch-data2:

networks:
opensearch-net:

Die Netzwerkeinstellungen im obigen Konfigurationsbeispiel sind für eine Portweiterleitung gesetzt. Im Folgenden gehen wir davon aus, dass das Notebook die beispielhafte IP 192.168.2.42 hat.
Nun starten wir  aus dem Verzeichnis heraus, unsere Komposition und lassen alles zusammen spielen:

$ docker-compose up
Starting opensearch-node1 ... done
Starting opensearch-dashboards ... done
Starting opensearch-node2 ... done
Attaching to opensearch-node2, opensearch-node1, opensearch-dashboards
opensearch-node2 | [2021-10-11T17:15:44,498][INFO ][o.o.n.Node ] [opensearch-node2] version[1.0.0], pid[11], build[tar/34550c5b17124ddc59458ef774f6b43a086522e3/2021-07-02T23:22:21.383695Z], OS[Linux/5.10.0-8-amd64/amd64], JVM[AdoptOpenJD
K/OpenJDK 64-Bit Server VM/15.0.1/15.0.1+9]
opensearch-node2 | [2021-10-11T17:15:44,501][INFO ][o.o.n.Node ] [opensearch-node2] JVM home [/usr/share/opensearch/jdk], using bundled JDK [true]
opensearch-node2 | [2021-10-11T17:15:44,501][INFO ][o.o.n.Node ] [opensearch-node2] JVM arguments [-Xshare:auto, -Dopensearch.networkaddress.cache.ttl=60, -Dopensearch.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -D
java.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -XX:+ShowCodeDetailsInExceptionMessages, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.al
locator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g, -Xmx1g, -XX:+UseG1GC, -XX:G1ReservePercent=25, -XX:InitiatingHeapOccupancyPercent=30, -Djava.io.tmpdir=/tmp/opensearch-1450963
1834068960625, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.
security.policy=/usr/share/opensearch/plugins/opensearch-performance-analyzer/pa_config/opensearch_security.policy, -Dopensearch.cgroups.hierarchy.override=/, -Xms512m, -Xmx512m, -XX:MaxDirectMemorySize=268435456, -Dopensearch.path.home=/usr/share/opensearch,
-Dopensearch.path.conf=/usr/share/opensearch/config, -Dopensearch.distribution.type=tar, -Dopensearch.bundled_jdk=true]
opensearch-node1 | [2021-10-11T17:15:44,792][INFO ][o.o.n.Node ] [opensearch-node1] version[1.0.0], pid[11], build[tar/34550c5b17124ddc59458ef774f6b43a086522e3/2021-07-02T23:22:21.383695Z], OS[Linux/5.10.0-8-amd64/amd64], JVM[AdoptOpenJD
K/OpenJDK 64-Bit Server VM/15.0.1/15.0.1+9]
opensearch-node1 | [2021-10-11T17:15:44,794][INFO ][o.o.n.Node ] [opensearch-node1] JVM home [/usr/share/opensearch/jdk], using bundled JDK [true]
opensearch-node1 | [2021-10-11T17:15:44,794][INFO ][o.o.n.Node ] [opensearch-node1] JVM arguments [-Xshare:auto, -Dopensearch.networkaddress.cache.ttl=60, -Dopensearch.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -XX:+ShowCodeDetailsInExceptionMessages, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.al
locator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g, -Xmx1g, -XX:+UseG1GC, -XX:G1ReservePercent=25, -XX:InitiatingHeapOccupancyPercent=30, -Djava.io.tmpdir=/tmp/opensearch-1753077
5664832230117, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=/usr/share/opensearch/plugins/opensearch-performance-analyzer/pa_config/opensearch_security.policy, -Dopensearch.cgroups.hierarchy.override=/, -Xms512m, -Xmx512m, -XX:MaxDirectMemorySize=268435456, -Dopensearch.path.home=/usr/share/opensearch,
-Dopensearch.path.conf=/usr/share/opensearch/config, -Dopensearch.distribution.type=tar, -Dopensearch.bundled_jdk=true]
opensearch-node2 | [2021-10-11T17:15:45,739][INFO ][o.o.s.s.t.SSLConfig ] [opensearch-node2] SSL dual mode is disabled
opensearch-node2 | [2021-10-11T17:15:45,740][INFO ][o.o.s.OpenSearchSecurityPlugin] [opensearch-node2] OpenSearch Config path is /usr/share/opensearch/config
opensearch-node1 | [2021-10-11T17:15:45,863][INFO ][o.o.s.s.t.SSLConfig ] [opensearch-node1] SSL dual mode is disabled
opensearch-node1 | [2021-10-11T17:15:45,863][INFO ][o.o.s.OpenSearchSecurityPlugin] [opensearch-node1] OpenSearch Config path is /usr/share/opensearch/config
opensearch-dashboards | {&quot;type&quot;:&quot;log&quot;,&quot;@timestamp&quot;:&quot;2021-10-11T17:15:45Z&quot;,&quot;tags&quot;:[&quot;info&quot;,&quot;plugins-service&quot;],&quot;pid&quot;:1,&quot;message&quot;:&quot;Plugin \&quot;visTypeXy\&quot; is disabled.&quot;}
opensearch-node2 | [2021-10-11T17:15:45,991][INFO ][o.o.s.s.DefaultSecurityKeyStore] [opensearch-node2] JVM supports TLSv1.3
opensearch-node2 | [2021-10-11T17:15:45,992][INFO ][o.o.s.s.DefaultSecurityKeyStore] [opensearch-node2] Config directory is /usr/share/opensearch/config/, from there the key- and truststore files are resolved relatively
opensearch-dashboards | {&quot;type&quot;:&quot;log&quot;,&quot;@timestamp&quot;:&quot;2021-10-11T17:15:46Z&quot;,&quot;tags&quot;:[&quot;warning&quot;,&quot;config&quot;,&quot;deprecation&quot;],&quot;pid&quot;:1,&quot;message&quot;:&quot;\&quot;cpu.cgroup.path.override\&quot; is deprecated and has been replaced by \&quot;ops.cGroupOverrides.cpuPath\&quot;&quot;}
opensearch-dashboards | {&quot;type&quot;:&quot;log&quot;,&quot;@timestamp&quot;:&quot;2021-10-11T17:15:46Z&quot;,&quot;tags&quot;:[&quot;warning&quot;,&quot;config&quot;,&quot;deprecation&quot;],&quot;pid&quot;:1,&quot;message&quot;:&quot;\&quot;cpuacct.cgroup.path.override\&quot; is deprecated and has been replaced by \&quot;ops.cGroupOverrides.cpuAcctPath\&quot;&quot;}
opensearch-node1 | [2021-10-11T17:15:46,131][INFO ][o.o.s.s.DefaultSecurityKeyStore] [opensearch-node1] JVM supports TLSv1.3
opensearch-node1 | [2021-10-11T17:15:46,132][INFO ][o.o.s.s.DefaultSecurityKeyStore] [opensearch-node1] Config directory is /usr/share/opensearch/config/, from there the key- and truststore files are resolved relatively
opensearch-dashboards | {&quot;type&quot;:&quot;log&quot;,&quot;@timestamp&quot;:&quot;2021-10-11T17:15:46Z&quot;,&quot;tags&quot;:[&quot;info&quot;,&quot;plugins-system&quot;],&quot;pid&quot;:1,&quot;message&quot;:&quot;Setting up [45] plugins: [alertingDashboards,usageCollection,opensearchDashboardsUsageCollection,opensearchDashboardsLegacy,mapsLe
gacy,share,opensearchUiShared,legacyExport,embeddable,expressions,data,home,console,apmOss,management,indexPatternManagement,advancedSettings,savedObjects,securityDashboards,indexManagementDashboards,anomalyDetectionDashboards,dashboard,notebooksDashboards,vi
sualizations,visTypeVega,visTypeTimeline,timeline,visTypeTable,visTypeMarkdown,tileMap,regionMap,inputControlVis,ganttChartDashboards,visualize,reportsDashboards,traceAnalyticsDashboards,queryWorkbenchDashboards,charts,visTypeVislib,visTypeTimeseries,visTypeT
agcloud,visTypeMetric,discover,savedObjectsManagement,bfetch]&quot;}

Und ja ich gebe es zu, ich hatte alles schon mal am Laufen!

Nun prüfen wir ob alles läuft!

Im Standard wird OpenSearch und OpenSearch Dashboards bereits mit Zertifikaten und einer Absicherung ausgerollt. Der Standard-Benutzer ist „admin“ und auch das Passwort lautet „admin“. Bitte denkt daran das es sich um selbst signierte Zertifikate handelt! Dies ist bei allen Anbindungen zu beachten (ssl.verification_mode: none).


$ curl -k -u &quot;admin:admin&quot; -X GET 'https://192.168.2.42:9200/_cluster/health?pretty'
{
&quot;cluster_name&quot; : &quot;opensearch-cluster&quot;,
&quot;status&quot; : &quot;green&quot;,
&quot;timed_out&quot; : false,
&quot;number_of_nodes&quot; : 2,
&quot;number_of_data_nodes&quot; : 2,
&quot;discovered_master&quot; : true,
&quot;active_primary_shards&quot; : 12,
&quot;active_shards&quot; : 24,
&quot;relocating_shards&quot; : 0,
&quot;initializing_shards&quot; : 0,
&quot;unassigned_shards&quot; : 0,
&quot;delayed_unassigned_shards&quot; : 0,
&quot;number_of_pending_tasks&quot; : 0,
&quot;number_of_in_flight_fetch&quot; : 0,
&quot;task_max_waiting_in_queue_millis&quot; : 0,
&quot;active_shards_percent_as_number&quot; : 100.0
}

Und nun ab in die visuelle Ansicht:

Hier empfiehlt es sich erst mal den Tenant auf Privat zu setzen.

Nun folgt eine kleines Video. Mein erstes Video Tutorial oder was auch immer nur für euch:

 

Und da ist der Pausengong!

Und schon ist sie rum, die erste Runde und OpenSearch steht noch! Also macht Euch alle bereit für die nächste Runde. Wenn Euch das, was ihr jetzt schon gelesen habt gefällt und Ihr es nicht bis Runde II aushaltet, 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.

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.
Lies mehr von Daniel und triff unser Team

Warum OpenSearch? Was ist OpenSearch? OpenSearch VS. Elastic

von | Jun 10, 2021 | ,

Es fing bereits 2015 an zu brodeln, als AWS seinen neuen SaaS-Dienst „AWS Elasticsearch Services“ veröffentlichte und später dann 2019 das Produkt OpenDistro erschien. Bei zuletzt genanntem Produkt erschließt sich mir bis heute nicht, warum ich dieses der X-Pack Basic von Elastic vorziehen sollte. So lange ich natürlich ein Elasticsearch oder den Elastic Stack nicht als SaaS-Dienst vermarkten möchte. Denn dann bleibt mir nur die bis vor kurzem verfügbare OSS-Variante, welche natürlich entsprechende Features, welche im X-Pack Basic integriert sind, vermissen lässt.

2017 auf der ElasticON in San Francisco wurde das neue offene Lizenz-Modell auf Basis der Apache-2.0-Lizenz und der daraus entstandenen OSS-Variante, so wie die Veröffentlichung einer X-Pack Basic Variante bekannt gegeben. Dieser Weg wird jetzt teilweise verlassen.

Anfang des Jahres war der Höhepunkt einer langen gerichtlichen Auseinandersetzung wohl erreicht. Elastic kündigte im Januar, wohl als letztes Mittel gegen Amazon, dass Ende der OSS mit Version Elasitc Stack 7.11 und den Wechsel zu einem dualen Lizenzmodell aus Server Side Public License (SSPL, wie z.b MongoDB) oder Elastic-Lizenz an. Amazon reagierte darauf und brachte die Community zum kochen, dass Ergebnis ist der Fork von Amazon „OpenSearch“, welcher auf Elastic Stack v 7.10 aufbaut.

Jetzt wollen wir aber mal alles im Detail betrachten und wie es weitergeht.

Spieler 1: Elastic

Was bedeutet dies jetzt für die Nutzer von Elastic Stack Produkten (IMHO):

  1. Die OSS Varianten welche Elasticsearch, Kibana und Beats unter APLv2 frei nutzbar und auch als SaaS-Dienst verkaufbar machten wurden abgekündigt mit Version 7.10
  2. Die X-Pack Basic bleibt bestehen und ist weiterhin frei Verfügbar und nutzbar mit allen Features, die darin enthalten sind
  3.  Lediglich die Vermarktung des Elastic Stack als SaaS-Dienst ist nicht mehr möglich

IMHO: Bisher für mich in der Wertung alles noch kein Beinbruch und viele Reaktionen unverständlich, denn von irgendwas muss ja als Firma gelebt werden. Zudem darf man nicht vergessen, dass mit den Werkzeugen des Elastic Stack, hervorragende Standards für ein modernes Event und Informations-Managment geschaffen wurden.

Was mich aber wirklich aufregt an der ganzen Sache ist der Fakt, dass mit der Filebeat Version 7.13, die Beats nur noch mit Elasticsearch und Kibana mit Versionen ältere als 7.10 sprich 7.11 zusammen spielen. Breaking Change lesen hier.
Dies könnte es schwierig machen die aktuellen Beats bzw. Filebeat mit anderen Werkzeugen wie z.B. Graylog zu nutzen. Aber dies werden wir für euch testen und berichten.

Spieler 2: OpenSearch

Als Antwort auf die Veränderungen des Elastic Stack wurde die Community unter anderem um AWS OpenDistro laut und es brodelte weiter bis es zum Ausbruch kam und Amazon AWS den Fork von Elastic Stack OSS 7.10 bekannt gab. Dies zunächst in Form von „OpenSearch“ als Fork von Elasticsearch und OpenDashboard als Fork von Kibana. Beide kommen bereits mit einer Vielzahl an Plugins und Integrationen, wie Sie es im Elastic Stack gibt. Hier ist schon mal ein guter Grundstock vorhanden.

Am 25.5.2021 wurde die Roadmap veröffentlicht  welche besagt, dass der aktuelle RC1 am 12.07.2021 als v1.0 veröffentlicht wird.

Jetzt wollen wir aber auch die Gegenseite Stellung beziehen lassen:

  1.  Am 21.01.2021 wurde der Fork ausgerufen und der heldenhafte Einsatz für ein ehrliches und quelloffenes Elasticsearch erklärt
  2.  Am 12.04.2021 wurde der Fork „OpenSearch“ öffentlich vorgestellt und gestartet.

Was bedeutet das für neue Nutzer oder Nutzer von OpenDistro oder von Nutzern des AWS Saas-Dienstes (IMHO):

  1. Abwarten ist hier angesagt der RC1 welchen wir uns natürlich für euch bereits ansehen und auch demnächst vorstellen werden ist „nur“ ein RC.
  2. Nutzer von OpenDistro sollten mit der Veröffentlichung von Version 1.0 umsteigen. Dennn OpenDistro wird mit Version 1.13 eingestellt!
  3.  „AWS Elasticsearch Service“ Nutzer müssen nicht bangen.
  4. Denn es gibt eine Abwärts-Kompatibilität zu Elasticsearch und Kibana 7.10.2 wie hier besagt und in den FAQs beschrieben.
  5. Diese Abwärts-Kompatibilität bedeutet es ist auch von Elasticsearch-OSS 7.10 oder gar 6.0 auf OpenSearch möglich.
  6. Wer Elasticsearch als SaaS-Dienst oder in SaaS-Dienste oder ähnlichen Produkt-Formaten verwenden will muss auf OpenSearch setzen (oder einfach Solr nutzen)

 

Abschließend bleibt zu sagen…

Nun liebe Lesenden ich weiss, dass war jetzt alles nichts technisches. Aber wir sind bereits den RC1 fleißig für euch am Testen und werden euch so bald es passt davon berichten. Vielleicht sogar passend zur Veröffentlichung von Version 1.0 am 12.07.2021?

Wer bisher auf den „alt“ bewährten Elastic Stack setzen möchte, kann dies in der Zukunft natürlich gerne weiterhin tun. Zu mal auch abzuwarten bleibt, wie es sich bei einer Vielzahl von Anwendungen welche auf Elasticsearch als Speicher setzen, wie z.B Graylog  mit der Integration verhält.

IMHO: Für mich ist klar Amazon in Form von AWS hat, dies bewusst provoziert und ist nicht der faire Spieler in dieser Partie (gewesen). Denn wenn man durchs Leben geht sollte es immer gelten ….

Bei allem, was wir denken, sagen oder tun, sollten wir uns fragen:
1. Ist es wahr?
2. Ist es fair für alle Beteiligten?
3. Wird es Freundschaft und guten Willen fördern?
4. Wird es dem Wohl aller Beteiligten dienen?”

Wer zu den oben erwähnten Themen und Werkzeugen Unterstützung benötigt, darf sich natürlich gerne von uns helfen lassen und bei den Kollegen von Sales nach einem/r Kollegen/Kollegin von Professional Services fragen. Oder in einer unserer Schulungen zu Graylog oder dem Elastic Stack lernen, wie mit den Werkzeugen in der Produktion umgegangen wird.

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.
Lies mehr von Daniel und triff unser Team

Trainings

Web Services

Events