pixel
Select Page

OpenSearch: Wie verwalten wir unsere Daten?

by | May 26, 2022 | OpenSearch

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...
More posts on the topicOpenSearch