Kibana: [Migration v6.5] Eine andere Kibana-Instanz scheint den Index zu migrieren

Pinging @ elastic / kibana-Operationen

@CamiloSierraH - danke für den Bericht. Dieses Problem wird durch das Stoppen des Prozesses verursacht, der für die Abwicklung der Migration verantwortlich ist. Diese "Sperrung" dient dazu, mehrere Kibana-Instanzen zu haben.

Bei diesem Problem sehe ich zwei mögliche Probleme:

• Wir sollten "Neuindizierung von .kibana in .kibana_X" einen Hinweis hinzufügen, der besagt, dass der Kibana-Prozess nicht gestoppt werden soll.
• Der Indexname in der Nachricht für nachfolgende Wiederholungsversuche während der Neuindizierung ist möglicherweise nicht korrekt.
  > log [14: 00: 20.457] [Warnung] [Migrationen] Eine andere Kibana-Instanz scheint den Index zu migrieren. Warten auf den Abschluss dieser Migration. Wenn keine andere Kibana-Instanz Migrationen versucht, können Sie diese Meldung umgehen, indem Sie den Index .kibana_2 löschen und Kibana neu starten.

Weitere Informationen finden Sie hier: https://www.elastic.co/guide/en/kibana/current/upgrade-migrations.html

das gleiche Problem in einer Docker / Dev-Umgebung

Das gleiche Problem, das mithilfe des DEB-Pakets von 6.4.0 auf 6.5.0 aktualisiert wurde, scheint auf "Eine andere Kibana-Instanz scheint den Index zu migrieren. Warten auf den Abschluss dieser Migration. Wenn keine andere Kibana-Instanz Migrationen versucht, können Sie dies tun." Um diese Nachricht zu umgehen, löschen Sie den Index .kibana_2 und starten Sie Kibana neu. "

Das Löschen von .kibana_2 und das Neustarten führen dazu, dass dasselbe passiert und in der obigen Nachricht hängen bleibt.

Die Kibana-Benutzeroberfläche sagt "Kibana-Server ist noch nicht bereit" - kann auch nicht auf denselben Status zugreifen.

Gleiches Problem wie beim Upgrade von

Ich habe das gleiche Problem und habe an meiner Testinstanz gearbeitet. Eigentlich habe ich keinen Zugang zu Kibana.
Haben Sie eine schnelle Lösung, um meine Benutzeroberfläche wiederzufinden? Ist es möglich, den ELK-Stack oder nur Kibana herunterzustufen?

@gmeriaux Sie müssen diese Schritte ausführen, um Ihre Kibana-Instanz wiederherzustellen -> https://www.elastic.co/guide/en/kibana/current/release-notes-6.5.0.html#known -issues-6.5. 0

@gmeriaux Ich hatte Erfolg damit, nur Kibana herunterzustufen und die Indizes .kibana_1 und .kibana_2 zu entfernen

@ CamiloSierraH, @ gheffern
Vielen Dank!!!
Ich habe Probleme beim Upgrade in der Windows-Umgebung (6.4.3 ⇨6.5.0).

.kibna2-Index löschen nach dem Start von kibna

Dort. war nein. Problem mit Version 6.5.1

Ich habe ein erfolgreiches Upgrade in einer Windows-Umgebung (6.4.3⇨6.5.1).

Beim Upgrade wurde ein ähnliches Problem festgestellt. Es stellte sich heraus, dass dies mit einem geschlossenen Index von .tasks . Kibana schlug mit einem index_closed_exception fehl. Dieser Index wird normalerweise nicht von Kibana verwendet (wurde vor langer Zeit vom Kurator automatisch geschlossen).

Mir ist aufgefallen, dass Kibana vor dem Löschen der Indizes zum Stillstand kommen sollte. Obwohl Kibana kurz vor dem Neustart einige Minuten lang langsam blieb - vielleicht um die beiden Indizes zu rekonstruieren -, waren alle Daten intakt.

$ curl-XGET "https://localhost:9200/_cat/indices"| grep kibana
...
green open .kibana_2 kVo3hhokTP2hVUSfmPkGVA 1 0 181 0 184.2kb 184.2kb
green open .kibana_1 mHhRaCqKStq6bL1qRLxMVA 1 0 178 0 170.9kb 170.9kb

Ich habe die Fehlermeldung: "Eine andere Kibana-Instanz scheint den Index zu migrieren. Warten auf den Abschluss dieser Migration. Wenn keine andere Kibana-Instanz Migrationen versucht, können Sie diese Meldung umgehen, indem Sie den Index .kibana_1 löschen und Kibana neu starten."
Nachdem ich curl -XDELETE http: // localhost : 9200 / .kibana_1 verwendet habe, um den Index zu löschen und kibana neu zu starten, erhalte ich dieselbe Meldung.
Die Version von Elch sind alle 6.5.4.

Ich hatte das gleiche Problem beim Upgrade von 6.4.2 auf 6.5.4

Ich hatte das gleiche Problem bei der Migration von 6.4.3 auf 6.6.0 .

Ich habe das Löschen der 3 Indizes gelöst: .kibana , .kibana_1 und .kibana_2 und den Neustart des Kibana-Dienstes.

Ich habe den folgenden Befehl von Linux Bash verwendet:
curl -X DELETE "localhost:9200/.kibana_2" && curl -X DELETE "localhost:9200/.kibana_1" && curl -X DELETE "localhost:9200/.kibana"

Hallo, die Anweisungen von @ Timmy93 sind destruktiv und Sie verlieren alle Dashboards und Visualisierungen .

Der Migrationsprozess wird auf dieser Dokumentationsseite erläutert.

Ich habe Kibana von 6.4.0 auf 6.7.1 aktualisiert. Ich hatte das gleiche Problem, also habe ich Indizes von .kibana_N gelöscht. Wie @lucabelluccini erwähnte, habe ich alle meine Dashboards und
Ich habe vor, ein weiteres auf 7.0.0 zu aktualisieren, aber ich möchte wirklich keine Kibana-Objekte mehr verlieren. Gibt es eine Möglichkeit, dieses Problem zu lösen, ohne Indizes zu löschen?

Ich habe gerade herausgefunden, dass es eine andere Kibana-Instanz im selben ES-Cluster gibt. Alles fertig nach dem Upgrade des Restes! Das war mein schlechtes. Bitte stellen Sie sicher, dass Sie keine andere Instanz im selben Cluster haben.

Das gleiche Problem beim Upgrade, aber jetzt dauert das Erstellen des Indexmusters ewig, bis zu dem Punkt, an dem ich befürchte, dass es überhaupt nicht funktioniert.

@notque - für dieses Problem würde ich empfehlen, die ES-Protokolle zu

Dieses Problem trat auch beim Upgrade von 6.6.2 auf 6.8.0 auf einer von drei Kibana-Instanzen mit demselben ES-Cluster auf.

Nachdem ich Kibana auf allen 3 gestoppt und den .kibana_2 -Index gelöscht hatte, startete ich die aktualisierte Instanz und sah dies immer wieder in den Protokollen:

kibana[8682]: {"type":"log","@timestamp":"2019-06-18T18:34:46Z","tags":["info","migrations"],"pid":8682,"message":"Creating index .kibana_2."}
kibana[8682]: {"type":"log","@timestamp":"2019-06-18T18:34:46Z","tags":["info","migrations"],"pid":8682,"message":"Migrating .kibana_1 saved objects to .kibana_2"}
kibana[8765]: {"type":"log","@timestamp":"2019-06-18T18:34:55Z","tags":["info","migrations"],"pid":8765,"message":"Creating index .kibana_2."}
kibana[8765]: {"type":"log","@timestamp":"2019-06-18T18:34:55Z","tags":["warning","migrations"],"pid":8765,"message":"Another Kibana instance appears to be migrating the index. Waiting for that migration to complete. If no other Kibana instance is attempting migrations, you can get past this message by deleting index .kibana_2 and restarting Kibana."}

Anstatt den .kibana_2 Index erneut zu löschen, habe ich den Alias ​​für .kibana so aktualisiert, dass er auf .kibana_2 . Dies löste das Problem für mich:

curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'
{
    "actions" : [
        { "remove" : { "index" : ".kibana_1", "alias" : ".kibana" } },
        { "add" : { "index" : ".kibana_2", "alias" : ".kibana" } }
    ]
}
'

Nur aus Neugier: Ich habe Kibana zu früh nach dem Upgrade von 7.0 auf 7.2 neu gestartet und steckte in „Kibana-Server ist nicht bereit“ fest (+ endlich wurde ein Protokolleintrag gefunden, dass eine andere Kibana-Instanz angezeigt wird…).

Es wäre wirklich schön, wenn Kibana die Migration von selbst aufnehmen könnte.

Dieser feststeckende Zustand kann auch auftreten, wenn die Elasticsearch-Zuordnung beim Upgrade von Kibana deaktiviert ist

Ich hatte den gleichen Fehler. (Kibana 6.8.2) Auf meiner Site wurden 3 Instanzen ausgeführt, .kibana, .kibana_1 und .kibana_2. Befolgen Sie die folgenden Schritte:

1. Beenden Sie den Kibana-Service.
2. Gelöschter .kibana_2- und .kibana-Index -
curl -XDELETE localhost: 9200 / index / .kibana_2
curl -XDELETE localhost: 9200 / index / .kibana
3.Dann zeigt der Index .kibana_1 auf den Alias ​​.kibana -
curl -X POST " localhost: 9200 / _aliases " -H 'Inhaltstyp: application / json' -d '{"Aktionen": [{"add": {"index": ".kibana_1", "alias": ".kibana"}}]} '
4. Starten Sie den Kibana-Dienst neu.
Kibana wird wieder erfolgreich geladen.

Pinging @ elastic / kibana-Plattform (Team: Plattform)

[ elastisch @ sjc-v2-elk-l01 ~] $ curl localhost: 9200
{
"name": "master-1",
"cluster_name": "sjc-v2",
"cluster_uuid": "g-MOWUQGQMmgOUaCP0cdYA",
"Ausführung" : {
"Nummer": "7.6.2",
"build_flavor": "default",
"build_type": "tar",
"build_hash": "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
"build_date": "2020-03-26T06: 34: 37.794943Z",
"build_snapshot": false,
"lucene_version": "8.4.0",
"minimum_wire_compatibility_version": "6.8.0",
"Minimum_index_compatibility_version": "6.0.0-beta1"
},
"tagline": "Sie wissen, für die Suche"
}}

LOGS

log [03: 47: 03.301] [info] [savedobjects-service] Startet die Migration gespeicherter Objekte
log [03: 47: 03.312] [info] [savedobjects-service] Index .kibana_task_manager_1 erstellen.
log [03: 47: 03.316] [info] [savedobjects-service] Index .kibana_1 erstellen.
APM-Agent-Konfiguration konnte nicht erstellt werden: Zeitlimit nach 30000 ms anfordern
log [03: 47: 33.313] [Warnung] [Gespeicherter Objektdienst] Es kann keine Verbindung zu Elasticsearch hergestellt werden. Fehler: Timeout nach 30000 ms anfordern
log [03: 47: 35.817] [Warnung] [gespeicherter Objektdienst] Es kann keine Verbindung zu Elasticsearch hergestellt werden. Fehler: [resource_already_exists_exception] index [.kibana_task_manager_1 / 6jHlllmtTmGSJI3vco_KJw] ist bereits vorhanden, wobei {index_uuid = "6jHlllmtTmGSJI3vco_KJw" & index = ". Kibana_task_manager_1"}
log [03: 47: 35.818] [Warnung] [savedobjects-service] Eine andere Kibana-Instanz scheint den Index zu migrieren. Warten auf den Abschluss dieser Migration. Wenn keine andere Kibana-Instanz Migrationen versucht, können Sie diese Meldung umgehen, indem Sie den Index .kibana_task_manager_1 löschen und Kibana neu starten.
log [03: 47: 35.828] [Warnung] [gespeicherter Objektdienst] Es kann keine Verbindung zu Elasticsearch hergestellt werden. Fehler: [resource_already_exists_exception] index [.kibana_1 / xvwnY15cQaStFRV-qjMbaA] existiert bereits mit {index_uuid = "xvwnY15cQaStFRV-qjMbaA" & index = ". Kibana_1"}
log [03: 47: 35.829] [Warnung] [savedobjects-service] Eine andere Kibana-Instanz scheint den Index zu migrieren. Warten auf den Abschluss dieser Migration. Wenn keine andere Kibana-Instanz Migrationen versucht, können Sie diese Meldung umgehen, indem Sie den Index .kibana_1 löschen und Kibana neu starten.

Ich erhalte den gleichen Fehler, habe die unten stehenden Indizes gelöscht und neu gestartet, aber den gleichen Fehler.

[ elastisch @ sjc-v2-elk-l01 ~] $ curl localhost: 9200 / _cat / indizes
rot öffnen .kibana_task_manager_1 6jHlllmtTmGSJI3vco_KJw 1 1
rot offen .apm-agent-configuration uD5uuI-nQa-qucX3wx3HIQ 1 1
rot offen .kibana_1 xvwnY15cQaStFRV-qjMbaA 1 1

Hallo @shemukr
Die Indizes befinden sich im Status red und das Problem scheint nicht mit der Migration gespeicherter Objekte zu zusammenhängen.
Bitte wenden Sie sich an http://discuss.elastic.co/ (mit der Ausgabe von GET _cluster/allocation/explain ).

Dies ist derzeit das erwartete Verhalten, wenn eine Migration fehlschlägt, wird jedoch durch # 52202 verbessert, das für automatisierte Wiederholungsversuche fehlgeschlagener Migrationen ohne Benutzereingriff geeignet ist.