Kibana: [migration v6.5] Une autre instance de Kibana semble migrer l'index

Pinging @ elastique / kibana-operations

@CamiloSierraH - merci pour le rapport. Ce problème est dû à l'arrêt du processus chargé de gérer la migration. Ce "verrouillage" consiste à gérer plusieurs instances de Kibana.

Avec ce problème, je vois deux problèmes possibles:

• Nous devrions ajouter une note à "Réindexer .kibana en .kibana_X" indiquant de ne pas arrêter le processus Kibana.
• Le nom de l'index dans la messagerie pour les réessais ultérieurs au cours de la réindexation peut être incorrect.
  > log [14: 00: 20.457] [avertissement] [migrations] Une autre instance Kibana semble migrer l'index. En attente de la fin de cette migration. Si aucune autre instance Kibana ne tente de migrer, vous pouvez passer ce message en supprimant l'index .kibana_2 et en redémarrant Kibana.

Plus d'informations sont disponibles ici: https://www.elastic.co/guide/en/kibana/current/upgrade-migrations.html

même problème dans un environnement docker / dev

Même problème - mis à niveau de 6.4.0 à 6.5.0 à l'aide du package DEB - semble être bloqué sur "Une autre instance Kibana semble migrer l'index. En attente de la fin de cette migration. Si aucune autre instance Kibana ne tente de migrer, vous pouvez passez ce message en supprimant l'index .kibana_2 et en redémarrant Kibana. "

La suppression de .kibana_2 et le redémarrage provoquent la même chose, se bloquent sur le message ci-dessus.

L'interface utilisateur de Kibana indique que "le serveur Kibana n'est pas encore prêt" - ne peut pas accéder / état non plus, même message.

Même problème que la mise à niveau @ lnx01 de 6.4.x vers 6.5.0

J'ai le même problème et je travaillais sur mon instance de test. En fait, je n'ai pas accès à kibana.
Avez-vous une solution rapide pour retrouver mon interface utilisateur? Est-il possible de rétrograder la pile ELK ou simplement kibana?

@gmeriaux vous devez suivre cette procédure pour récupérer votre instance kibana -> https://www.elastic.co/guide/en/kibana/current/release-notes-6.5.0.html#known -issues-6.5. 0

@gmeriaux J'ai eu du succès en rétrogradant simplement kibana et en supprimant les index .kibana_1 et .kibana_2

@ CamiloSierraH, @ gheffern
Merci!!!
J'ai du mal à effectuer la mise à niveau dans l'environnement Windows (6.4.3 ⇨6.5.0)

.kibna2 suppression d'indice après le démarrage de kibna

Là. était non. problème avec la version 6.5.1

Je réussis la mise à niveau dans l'environnement Windows (6.4.3⇨6.5.1)

Un problème similaire a été détecté lors de la mise à niveau. Il s'avère que c'était lié à un index fermé .tasks . Kibana échouait avec un index_closed_exception cet index n'est généralement pas utilisé par Kibana (a été fermé automatiquement par le conservateur il y a _long_ temps).

J'ai remarqué que Kibana devrait être en arrêt complet avant de supprimer les index. Bien que Kibana soit resté lent pendant quelques minutes juste avant de redémarrer - peut-être pour reconstruire les deux indices - il est venu avec toutes les données intactes.

$ 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

J'ai le message d'erreur: "Une autre instance de Kibana semble migrer l'index. En attente de la fin de cette migration. Si aucune autre instance de Kibana ne tente de migrer, vous pouvez passer ce message en supprimant l'index .kibana_1 et en redémarrant Kibana."
après avoir utilisé curl -XDELETE http: // localhost : 9200 / .kibana_1 pour supprimer l'index et redémarrer kibana., j'obtiens le même message.
la version d'elk est tous 6.5.4.

J'ai rencontré le même problème lors de la mise à niveau de 6.4.2 à 6.5.4

J'ai eu le même problème lors de la migration de 6.4.3 vers 6.6.0 .

J'ai résolu la suppression des 3 index: .kibana , .kibana_1 et .kibana_2 et redémarrage du service kibana.

J'ai utilisé la commande suivante de linux bash:
curl -X DELETE "localhost:9200/.kibana_2" && curl -X DELETE "localhost:9200/.kibana_1" && curl -X DELETE "localhost:9200/.kibana"

Bonjour, les instructions fournies par @ Timmy93 sont destructives et vous perdrez tous les tableaux de bord et visualisations .

Le processus de migration est expliqué sur cette page de documentation .

J'étais en train de mettre à jour Kibana de 6.4.0 à 6.7.1 . J'ai eu le même problème, j'ai donc supprimé les index de .kibana_N . Comme @lucabelluccini l'a mentionné, j'ai perdu tous mes tableaux de bord et modèles d'index.
Je prévois d'en mettre un de plus à niveau vers 7.0.0 mais je ne veux vraiment pas perdre à nouveau les objets kibana. Existe-t-il un moyen de résoudre ce problème sans supprimer les index?

Je viens de découvrir qu'il y avait une autre instance de kibana sur le même cluster es. Tout est prêt après la mise à niveau du reste! C'était mon mal. Plz plz plz assurez-vous que vous n'avez aucune autre instance sur le même cluster.

Même problème lors de la mise à niveau, mais maintenant la création du modèle d'index prend une éternité, au point que je crains que cela ne fonctionne pas du tout.

@notque - pour ce problème, je recommanderais d'inspecter les journaux ES car ils ne sont pas liés aux migrations Kibana.

J'ai également rencontré ce problème lors de la mise à niveau de 6.6.2 à 6.8.0 sur 1 des 3 instances Kibana utilisant le même cluster ES.

Après avoir arrêté Kibana sur les 3 et supprimé l'index .kibana_2 , j'ai démarré l'instance mise à jour et j'ai continué à voir cela dans les journaux:

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

Au lieu de supprimer à nouveau l'index .kibana_2 , j'ai mis à jour l'alias pour .kibana pour qu'il pointe vers .kibana_2 . Cela a fini par résoudre le problème pour moi:

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" } }
    ]
}
'

Juste par curiosité: j'ai redémarré kibana trop tôt après la mise à niveau de la version 7.0 à 7.2 et je suis resté bloqué dans „Le serveur Kibana n'est pas prêt” (+ j'ai finalement trouvé une entrée de journal indiquant qu'une autre instance de kibana apparaît…) Heureusement, un message m'a suggéré quel index dois-je supprimer.

Ce serait vraiment bien si Kibana pouvait prendre en charge la migration par lui-même.

Cet état bloqué peut également se produire si l'allocation Elasticsearch est désactivée lors de la mise à niveau de Kibana

J'ai eu la même erreur. (Kibana 6.8.2) 3 instances étaient en cours d'exécution sur mon site, .kibana, .kibana_1 et .kibana_2. Suivez les étapes ci-dessous:

1.Arrêtez le service Kibana.
2. Suppression des index .kibana_2 et .kibana -
curl -XDELETE localhost: 9200 / index / .kibana_2
curl -XDELETE localhost: 9200 / index / .kibana
3.Pointez ensuite l'index .kibana_1 vers l'alias .kibana -
curl -X POST " localhost: 9200 / _aliases " -H 'Content-Type: application / json' -d '{"actions": [{"add": {"index": ".kibana_1", "alias": ".kibana"}}]} '
4.Redémarrez le service Kibana.
Kibana est à nouveau chargé avec succès.

Pinging @ élastique / kibana-platform (Équipe: Platform)

[ élastique @ sjc-v2-elk-l01 ~] $ curl localhost: 9200
{
"nom": "maître-1",
"nom_classe": "sjc-v2",
"cluster_uuid": "g-MOWUQGQMmgOUaCP0cdYA",
"version" : {
"nombre": "7.6.2",
"build_flavor": "default",
"build_type": "tar",
"build_hash": "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
"build_date": "2020-03-26T06: 34: 37.794943Z",
"build_snapshot": faux,
"lucene_version": "8.4.0",
"minimum_wire_compatibility_version": "6.8.0",
"minimum_index_compatibility_version": "6.0.0-beta1"
},
"tagline": "Vous savez, pour la recherche"
}

BÛCHES

log [03: 47: 03.301] [info] [savedobjects-service] Démarrage des migrations d'objets enregistrés
log [03: 47: 03.312] [info] [savedobjects-service] Création de l'index .kibana_task_manager_1.
log [03: 47: 03.316] [info] [savedobjects-service] Création de l'index .kibana_1.
Impossible de créer la configuration de l'agent APM: délai d'expiration de la demande après 30000 ms
log [03: 47: 33.313] [avertissement] [savedobjects-service] Impossible de se connecter à Elasticsearch. Erreur: délai d'expiration de la demande après 30000 ms
log [03: 47: 35.817] [avertissement] [savedobjects-service] Impossible de se connecter à Elasticsearch. Erreur: [resource_already_exists_exception] index [.kibana_task_manager_1 / 6jHlllmtTmGSJI3vco_KJw] existe déjà, avec {index_uuid = "6jHlllmtTmGSJI3vco_KJww" & index = ". Kibana_task_manager_1"}
log [03: 47: 35.818] [warning] [savedobjects-service] Une autre instance de Kibana semble être en train de migrer l'index. En attente de la fin de cette migration. Si aucune autre instance Kibana ne tente de migrer, vous pouvez passer ce message en supprimant l'index .kibana_task_manager_1 et en redémarrant Kibana.
log [03: 47: 35.828] [avertissement] [savedobjects-service] Impossible de se connecter à Elasticsearch. Erreur: [resource_already_exists_exception] index [.kibana_1 / xvwnY15cQaStFRV-qjMbaA] existe déjà, avec {index_uuid = "xvwnY15cQaStFRV-qjMbaA" & index = ". Kibana_1"}
log [03: 47: 35.829] [avertissement] [savedobjects-service] Une autre instance de Kibana semble migrer l'index. En attente de la fin de cette migration. Si aucune autre instance Kibana ne tente de migrer, vous pouvez passer ce message en supprimant l'index .kibana_1 et en redémarrant Kibana.

J'obtiens la même erreur, j'ai supprimé les indices ci-dessous et redémarré, mais même erro.

[ élastique @ sjc-v2-elk-l01 ~] $ curl localhost: 9200 / _cat / indices
rouge ouvert .kibana_task_manager_1 6jHlllmtTmGSJI3vco_KJw 1 1
rouge ouvert .apm-agent-configuration uD5uuI-nQa-qucX3wx3HIQ 1 1
rouge ouvert .kibana_1 xvwnY15cQaStFRV-qjMbaA 1 1

Bonjour @shemukr
Les index sont à l'état red et le problème ne semble pas lié à la migration des objets enregistrés.
Veuillez contacter http://discuss.elastic.co/ (avec la sortie de GET _cluster/allocation/explain ).

Il s'agit actuellement du comportement attendu en cas d'échec d'une migration, mais il sera amélioré par # 52202 qui permettra de relancer automatiquement les migrations échouées sans intervention de l'utilisateur.