Kibana: [миграция v6.5] Другой экземпляр Kibana, похоже, переносит индекс

Пинг @ elastic / kibana-operations

@CamiloSierraH - спасибо за отчет. Эта проблема вызвана остановкой процесса, отвечающего за перенос. Эта «блокировка» предназначена для обработки нескольких экземпляров Kibana.

С этой проблемой я вижу две возможные проблемы:

• Мы должны добавить примечание «Переиндексировать .kibana в .kibana_X», в котором говорится, что не следует останавливать процесс Kibana.
• Имя индекса в сообщении для последующих повторных попыток во время повторного индексирования может быть неправильным.
  > log [14: 00: 20.457] [предупреждение] [миграции] Другой экземпляр Kibana, похоже, выполняет миграцию индекса. Ожидаем завершения миграции. Если никакой другой экземпляр Kibana не пытается выполнить миграцию, вы можете пропустить это сообщение, удалив индекс .kibana_2 и перезапустив Kibana.

Дополнительная информация доступна здесь: https://www.elastic.co/guide/en/kibana/current/upgrade-migrations.html.

такая же проблема в среде docker / dev

Та же проблема - при обновлении с 6.4.0 до 6.5.0 с использованием пакета DEB - похоже, застряла на "Другой экземпляр Kibana, похоже, переносит индекс. Ожидает завершения этой миграции. Если никакой другой экземпляр Kibana не пытается выполнить миграцию, вы можете пропустите это сообщение, удалив индекс .kibana_2 и перезапустив Kibana. "

Удаление .kibana_2 и перезапуск вызывает то же самое, застревает в сообщении выше.

Пользовательский интерфейс Kibana говорит: «Сервер Kibana еще не готов» - нет доступа / статуса, такое же сообщение.

Та же проблема, что и при обновлении

У меня такая же проблема, и я работал над своим тестовым экземпляром. На самом деле у меня нет доступа к кибане.
У вас есть быстрое решение, чтобы найти мой интерфейс? Можно ли понизить стек ELK или просто кибану?

@gmeriaux, вам необходимо выполнить следующие действия, чтобы вернуть свой экземпляр кибаны -> https://www.elastic.co/guide/en/kibana/current/release-notes-6.5.0.html#known -issues-6.5. 0

@gmeriaux Мне удалось просто понизить версию kibana и удалить индексы .kibana_1 и .kibana_2

@ CamiloSierraH, @ gheffern
благодаря!!!
У меня проблемы с обновлением в среде Windows (6.4.3 ⇨6.5.0)

.kibna2 удаление индекса после запуска кибны

Там. не было. проблема с версией 6.5.1

Я успешно обновляюсь в среде Windows (6.4.3⇨6.5.1)

Обнаружил аналогичную проблему при обновлении. Оказывается, это было связано с закрытым индексом .tasks . Кибана не справлялась с index_closed_exception этот индекс обычно не используется Кибаной (был автоматически закрыт куратором _долго_ назад).

Я заметил, что Кибана должна быть на полной остановке перед удалением индексов. Хотя Kibana оставалась медленной в течение нескольких минут прямо перед перезапуском - возможно, для восстановления обоих индексов - все данные остались нетронутыми.

$ 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

У меня появляется сообщение об ошибке: «Похоже, что другой экземпляр Kibana выполняет миграцию индекса. Ожидает завершения миграции. Если никакой другой экземпляр Kibana не пытается выполнить миграцию, вы можете пропустить это сообщение, удалив индекс .kibana_1 и перезапустив Kibana».
после того, как я использую curl -XDELETE http: // localhost : 9200 / .kibana_1 для удаления индекса и перезапуска kibana., я получаю то же сообщение.
версия лося все 6.5.4.

Я столкнулся с той же проблемой при обновлении с 6.4.2 до 6.5.4

У меня была такая же проблема при переходе с 6.4.3 на 6.6.0 .

Я решил удалить 3 индекса: .kibana , .kibana_1 и .kibana_2 и перезапустить службу кибаны.

Я использовал следующую команду из linux bash:
curl -X DELETE "localhost:9200/.kibana_2" && curl -X DELETE "localhost:9200/.kibana_1" && curl -X DELETE "localhost:9200/.kibana"

Здравствуйте, инструкции, предоставленные @ Timmy93 , разрушительны, и вы потеряете все панели мониторинга и визуализации .

Процесс миграции объясняется на этой странице документации .

Я обновлял кибану с 6.4.0 до 6.7.1 . У меня была такая же проблема, поэтому я удалил индексы .kibana_N . Как упоминал @lucabelluccini , я потерял все свои информационные панели и шаблоны индекса.
Я планирую обновить еще один до 7.0.0 но я действительно не хочу снова терять объекты кибаны. Есть ли способ решить эту проблему без удаления индексов?

Я только что узнал, что в том же кластере es есть еще один экземпляр кибаны. Все готово после обновления, остальное! Это было моим плохим. Пожалуйста, пожалуйста, убедитесь, что у вас нет другого экземпляра в том же кластере.

Та же проблема при обновлении, но теперь создание шаблона индекса занимает вечность, и я обеспокоен тем, что он вообще не работает.

@notque - по этой проблеме я бы рекомендовал проверить журналы ES, поскольку они не связаны с миграциями Kibana.

Я также столкнулся с этой проблемой при обновлении с 6.6.2 до 6.8.0 на 1 из 3 экземпляров Kibana, использующих один и тот же кластер ES.

После остановки Kibana на всех 3 и удаления индекса .kibana_2 я запустил обновленный экземпляр и продолжал видеть это в журналах:

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

Вместо повторного удаления индекса .kibana_2 я обновил псевдоним для .kibana чтобы он указывал на .kibana_2 . Это решило проблему для меня:

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

Просто из любопытства: я перезапустил кибану слишком скоро после обновления с 7.0 до 7.2 и застрял в сообщении «Сервер Kibana не готов» (+ наконец-то нашел запись в журнале о том, что появляется другой экземпляр кибаны…). К счастью, в сообщении было предложено, какой индекс мне следует удалить.

Было бы очень хорошо, если бы кибана могла начать миграцию сама по себе.

Это состояние зависания также может произойти, если выделение Elasticsearch отключено при обновлении Kibana.

У меня была такая же ошибка. (Kibana 6.8.2) На моем сайте работало 3 экземпляра: .kibana, .kibana_1 и .kibana_2. Выполнили следующие шаги:

1. Остановите службу Kibana.
2.Удалены индексы .kibana_2 и .kibana -
curl -XDELETE локальный : 9200 / индекс / .kibana_2
curl -XDELETE локальный : 9200 / индекс / .kibana
3. Затем укажите индекс .kibana_1 на псевдоним .kibana -
curl -X POST " localhost: 9200 / _aliases " -H 'Content-Type: application / json' -d '{"actions": [{"add": {"index": ".kibana_1", "alias": ".kibana"}}]} '
4. перезапустите службу Kibana.
Кибана снова успешно загружается.

Pinging @ elastic / kibana-platform (Команда: Platform)

[ эластичный @ sjc-v2-elk-l01 ~] $ curl localhost: 9200
{
"имя": "мастер-1",
"имя_кластера": "sjc-v2",
"cluster_uuid": "g-MOWUQGQMmgOUaCP0cdYA",
"версия": {
"number": "7.6.2",
"build_flavor": "по умолчанию",
"build_type": "tar",
"build_hash": "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
"build_date": "2020-03-26T06: 34: 37.794943Z",
"build_snapshot": ложь,
"lucene_version": "8.4.0",
"minimum_wire_compatibility_version": "6.8.0",
"minimum_index_compatibility_version": "6.0.0-beta1"
},
"слоган": "Знаешь, для поиска"
}

ЖУРНАЛЫ

log [03: 47: 03.301] [info] [savedobjects-service] Запуск миграции сохраненных объектов
log [03: 47: 03.312] [info] [savedobjects-service] Создание индекса .kibana_task_manager_1.
log [03: 47: 03.316] [info] [savedobjects-service] Создание индекса .kibana_1.
Не удалось создать конфигурацию агента APM: тайм-аут запроса через 30000 мс
журнал [03: 47: 33.313] [предупреждение] [savedobjects-service] Невозможно подключиться к Elasticsearch. Ошибка: таймаут запроса через 30000 мс
журнал [03: 47: 35.817] [предупреждение] [savedobjects-service] Невозможно подключиться к Elasticsearch. Ошибка: [resource_already_exists_exception] индекс [.kibana_task_manager_1 / 6jHlllmtTmGSJI3vco_KJw] уже существует, причем {index_uuid = "6jHlllmtTmGSJI3vco_KJw" & index = ". Kibana_task_manager_1".
log [03: 47: 35.818] [предупреждение] [savedobjects-service] Другой экземпляр Kibana, похоже, выполняет миграцию индекса. Ожидаем завершения миграции. Если никакой другой экземпляр Kibana не пытается выполнить миграцию, вы можете обойти это сообщение, удалив индекс .kibana_task_manager_1 и перезапустив Kibana.
журнал [03: 47: 35.828] [предупреждение] [savedobjects-service] Невозможно подключиться к Elasticsearch. Ошибка: [resource_already_exists_exception] индекс [.kibana_1 / xvwnY15cQaStFRV-qjMbaA] уже существует, с {index_uuid = "xvwnY15cQaStFRV-qjMbaA" & index = ". Kibana_1"}
log [03: 47: 35.829] [предупреждение] [savedobjects-service] Другой экземпляр Kibana, похоже, переносит индекс. Ожидаем завершения миграции. Если никакой другой экземпляр Kibana не пытается выполнить миграцию, вы можете обойти это сообщение, удалив индекс .kibana_1 и перезапустив Kibana.

Я получаю ту же ошибку, я удалил указанные ниже индексы и перезапустился, но с той же ошибкой.

[ эластичный @ sjc-v2-elk-l01 ~] $ curl localhost: 9200 / _cat / index
красный открытый .kibana_task_manager_1 6jHlllmtTmGSJI3vco_KJw 1 1
красный открыть .apm-agent-configuration uD5uuI-nQa-qucX3wx3HIQ 1 1
красный открытый .kibana_1 xvwnY15cQaStFRV-qjMbaA 1 1

Привет @shemukr
Индексы находятся в состоянии red и проблема, похоже, не связана с переносом сохраненных объектов.
Пожалуйста, обратитесь на http://discuss.elastic.co/ (с выводом GET _cluster/allocation/explain ).

В настоящее время это ожидаемое поведение при сбое миграции, но оно будет улучшено в выпуске # 52202, который будет выполнять автоматические повторные попытки неудачной миграции без вмешательства пользователя.