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