Несколько вопросов по кластеру ELK

[KOTOXJle6 (Dmitriy)]

Добрый день.

Решил масштабировать единый сервер ELK в кластер. Ввел вторую ноду ES, роли оставил по-умолчанию, реплики только системные. Версию ELK поднял до 6.7.1. Никак не могу разобраться с некоторыми моментами:

1. Сейчас у меня 349 индексов, а шардов по 848. Разве их не должно быть 698?
   

   

2. На вкладке Monitoring в Disk Available я вижу место на обеих нодах как единую область. Как происходит запись данных на ноды? Пока есть место на первой, данные будут идти туда, а при заполнении на вторую? Если в logstash у меня будут указаны оба сервера, данные будут записываться на них равномерно?

3. Чтобы кластер был отказоустойчивым нужно добавить еще одну ноду Master-Data, добавить 2 реплики и задать параметр discovery.zen.minimum_master_nodes: 2? Реплики в этом случае равномерно будут писаться на все ноды кластера?

4. Сейчас данные от beats поступают в logstash и из него в elasticsearch. В основном данные с серверов Windows, для них недоступность ES не критична, когда сервис восстанавливается, все данные приходят. А если данные будут отправляться с сетевого устройства, а ES будет недоступен, то данные пропадут. Можно ли как-нибудь настроить logstash на хранение данных у себя до момента когда ES станет доступен или для этих целей лучше использовать другие программы?

[ep4sh]

1. Вы можете посмотреть кол-во шардов и реплик:
   GET _cat/indices?v
   думаю, что для некоторых индексов у Вас значение отличное от 1:1
2. Посмотрите вот это: https://www.elastic.co/guide/en/logstash/current/persistent-queues.html

По остальному, насколько я могу знать, всё происходит прозрачно для пользователя, по опыту со "средней" равномерностью)

[KOTOXJle6 (Dmitriy)]

@ep4sh

1. Вы можете посмотреть кол-во шардов и реплик:
   GET _cat/indices?v
   думаю, что для некоторых индексов у Вас значение отличное от 1:1

Да, там немного больше - 353. Но все равно получается большая разница. В принципе на работе это не сказывается, просто интересно как так получается.

@ep4sh

2. Посмотрите вот это: Persistent queues (PQ) | Logstash Reference [8.11] | Elastic

По остальному, насколько я могу знать, всё происходит прозрачно для пользователя, по опыту со "средней" равномерностью)

Спасибо за ссылку.

[Igor_Motov]

@KOTOXJle6

3. Чтобы кластер был отказоустойчивым нужно добавить еще одну ноду Master-Data, добавить 2 реплики и задать параметр discovery.zen.minimum_master_nodes: 2? Реплики в этом случае равномерно будут писаться на все ноды кластера?

Для отакзоустойчивости в случае потери одного узла достаточно добавить один узел. Увеличивать количество реплик до 2-х не обязательно. Достаточно одной копии, тогда шарды будут равномерно распределены, на разных узлах будут разные копии, но при этом потеря одного узла не должна привести к потере данных, так как копия этих данных будет на одном из выживших узлов.

[KOTOXJle6 (Dmitriy)]

Игорь, спасибо за ответ.

В итоге я пока остановился на следующей конфигурации:
1 Сервер-балансировщик без ролей ES, с Kibana и Logstash
3 Сервера со всеми ролями ES.
2 Реплики

Обновил задание на очистку Curator, индексов стало меньше. Если я правильно считаю, 240 индексов, 5 шардов и 2 реплики, получается 240 * 5 = 1200 и 1200 + 1200*2 = 3600 (3393 Total Shards в Kibana)

Примерно то же самое, что показывает Kibana.

[Igor_Motov]

У вас слишком много шард для такого маленького кластера. Если индексы создаются ежедневно, то возможно имеет смысл создавать их не так часто.

[KOTOXJle6 (Dmitriy)]

Да, индексы создаются ежедневно. А как можно реже создавать ежедневные индексы? Есть ли смысл уменьшить количество шардов до, например, 3?

[Igor_Motov]

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

[KOTOXJle6 (Dmitriy)]

Самый большой индекс 3.2ГБ, средний 300МБ. Больше 1ГБ пока создалось всего 30 индексов.

[Igor_Motov]

Да, я бы начал с уменьшения количества шард до 1.