Я использую elasticsearch как часть стека Logstash, в котором все компоненты стека установлены на одном сервере.
Целью этого является предоставление разработчикам журналов приложений для отладки. Мне не нужно сохранять созданные индексы. У меня есть задание cron, которое удаляет индексы старше 7 дней.
Необработанные журналы сохраняются в другом месте на случай, если нам понадобится исторический анализ.
У меня проблема в том, что elasticsearch продолжает переходить в состояние здоровья Red из-за неназначенных осколков. Я исследовал различные способы восстановить это, но неизбежно заканчиваю тем, что удаляю необработанные файлы индекса и перезапускаю службу.
Это настоящая боль, так как это всегда время, когда разработчикам нужен доступ, который не работает с elasticsearch.
Мне кажется, что нет более простого способа восстановить elasticsearch, кроме как удалить нарушающие индексы. Я настроил elasticsearch на использование одного узла, без реплик и без обнаружения сети, но каждые пару дней он продолжает падать.
Я зря трачу время, пытаясь запустить elasticsearch на одном сервере? Всегда ли он будет падать из-за неназначенных осколков? Учитывая то, для чего я его использую, развертывание кластера может показаться излишним.
Примечание. Я использую этот стек в Amazon EC2.
После долгих страданий я обнаружил, что лучший способ запустить elasticsearch на одном сервере - это изменить настройку по умолчанию:
index.number_of_replicas: 1
к
index.number_of_replicas: 0
Если существует 0 реплик, elasticsearch никогда не будет пытаться назначить шарды какой-либо другой «реплике», а не самому себе, тем самым устраняя проблему неназначенных шардов и поврежденных индексов.
Моя полная (стабильная) автономная конфигурация elasticsearch не по умолчанию:
node.max_local_storage_nodes: 1
index.number_of_replicas: 0
Обратите внимание, что это конфигурация только для программы чтения журналов, а не для полномасштабной производственной установки.
Не уверен, почему вы получаете неназначенные шарды, особенно с Logstash. я использую куратор управлять elasticsearch. Мой стек ELK работает на одной виртуальной машине (на данный момент), поэтому он очень голоден, но все еще работает. Мне пришлось чертовски подправить сам elasticsearch, чтобы оптимизировать его для виртуальной машины. Ключевыми компонентами для меня были ES_HEAP_SIZE и MAX_OPEN_FILES.