Home » ELK Stack » Ошибка в elasticsearch - FORBIDDEN/12/index read-only / allow delete (api)

Ошибка в elasticsearch - FORBIDDEN/12/index read-only / allow delete (api)

Поймал несколько раз ошибку в работе связки logstash + elasticsearch. Выражается в том, что данные не поступают в определенный индекс. Самое просторе решение - удалить индекс и создать заново. Данные начнут поступать. Если вас не устраивает решение с удалением индекса, то читайте дальше.

Если у вас есть желание научиться профессионально строить и поддерживать высокодоступные виртуальные и кластерные среды, рекомендую познакомиться с онлайн-курсом Администратор Linux. Виртуализация и кластеризация в OTUS. Курс не для новичков, для поступления нужно пройти .

Полностью ошибка в логе logstash выглядит следующим образом:

[INFO ][logstash.outputs.elasticsearch] retrying failed action with response code: 403 ({"type"=>"cluster_block_exception", "reason"=>"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"})

Получил я ее несколько раз, когда оставалось очень мало свободного места на диске с данными elasticsearch. При достижении примерно 5% свободного места, данные переставали поступать в elasticsearch и появлялась эта ошибка. Исправить ее можно следующим образом. Во первых, перенести данные на более емкий диск или почистить его. Потом идем в Kibana -> Dev Tools и выполняем команду:

PUT weblogs-2018.09.10/_settings
{
  "index": {
  "blocks": {
  "read_only_allow_delete": "false"
}
}
}

Решение ошибки в elasticsearch - FORBIDDEN/12/index read-only / allow delete (api)

weblogs-2018.09.10 - имя индекса, куда не шли данные. После выполнения команды перезапустил logstash на сервере и данные пошли в текущий индекс.

Скорее всего для записи будут недоступны и системные индексы. Проверьте, какие у вас используются. Точно должен быть .kibana. Если используете мониторинг, то для него тоже свои системные индексы создаются. Они тоже могут быть заблокированы для записи.

Онлайн курс по Linux

Если вы хотите стать специалистом по отказоустойчивым виртуальным и кластерным средам, рекомендую познакомиться с онлайн-курсом Администратор Linux. Виртуализация и кластеризация в OTUS. Курс не для новичков, для поступления нужны хорошие знания по Linux. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Что даст вам этот курс:
  • Умение строить отказоустойчивые кластера виртуализации для запуска современных сервисов, рассчитанных под высокую нагрузку.
  • Будете разбираться в современных технологиях кластеризации, оркестрации и виртуализации.
  • Научитесь выбирать технологии для построения отказоустойчивых систем под высокую нагрузку.
  • Практические навыки внедрения виртуализации KVM, oVirt, Xen.
  • Кластеризация сервисов на базе pacemaker,k8s, nomad и построение дисковых кластеров на базе ceph, glaster, linstore.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

11 комментариев

  1. Аватар
    Сергей

    Так происходит из за переполнения жёсткого диска.
    https://stackoverflow.com/a/50609418/15045248

  2. Аватар
    Аноним

    Добрейшего утреца всем!
    Ребят а у меня эта ошибка возникает при сохранении визуализации на боевом!
    На тестовом всё прекрасно все работает даже с учетом того что мало места всего 15 пи поднял в виртуалке .
    Может кто нибудь оказать посильную помощь?
    Спасибо!

  3. Аватар
    Аноним

    А куратор может как то в этом помочь при отчистке данных с elasticsearch ?
    Проблема в том, что данных за сутки собирает более 30 гигов по индексу (Storage size). Уже и на циске оставил только ip flow ingress. Один черт льет просто гигабайты данных. А задача дергать топ 20 ip по загрузке день/неделя/месяц. Даже не знаю что и делать + еще и эта проблема с тем что индекс не отрабатывает.

    • Zerox

      Куратор конечно может помочь. Он этим и занимается. Закрывает и удаляет старые индексы. Рассчитайте дневное использование, сравните с объемом хранилища и настройте чистку с запасом. Но если льется очень много данных, то рекомендую подумать над тем, как этот поток сократить. В elasticsearch лучше лить как можно меньше, все лишнее отсекая до него. Он очень прожорлив до ресурсов и начинает сильно тормозить, когда много данных.

  4. Аватар
    Аноним

    Так как избежать данной ситуации ?

    • Zerox

      Следить, чтобы на разделе, где хранятся базы elasticsearch место не заканчивалось.

  5. Аватар
    Michael Kartashev

    Спасибо большое.

    Может кто знает, почему это могло приключиться, и как избежать этого в будущем?

  6. Аватар

    Добрый день!

    Можно выполнить команду для всех индексов:

    PUT _all/_settings
    {
      "index": {
        "blocks": {
          "read_only_allow_delete": "false"
        }
      }
    }

    Вместо false можно использовать null.
    В документации к Elasticsearch расписано более подробно и есть второй вариант решения данной проблемы:
    https://www.elastic.co/guide/en/elasticsearch/reference/6.4/disk-allocator.html

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.