Оптимизация ELK стека.

Всем привет.

Как любая сложная система ELK стек нуждается в оптимизации своей работы, т.е. настроек по умолчанию. Для нормальной работы ELK стека приведенные ниже рекомендации по оптимизации работы Elasticsearch будут одинаково справедливы как для кластерной схемы так и без нее. Что же следует сделать?

1) Установить размер heap size.

Так как Elasticsearch написан на Java, то для работы необходимо настроить размер «кучи» (heap size).  В каталоге установки Elasticsearch имеется файл jvm.options, в котором уже указаны размеры, по умолчанию - это 1 Гб. Однако, для настройки рекомендуется указать новые параметры в файле каталога jvm.options.d, который находится там же.

-Xms16g

-Xmx16g

Пример выше использует минимальный Xms и максимальный Xmx размер heap size, равный 16 Гб. Для настройки данных параметров следует использовать следующие рекомендации:

- установите значения Xmx и Xms не более 50% от имеющейся физической памяти узла. Оставшуюся память Elasticsearch будет использовать для других целей. Чем больше heap size, тем меньше памяти используется под системные кеш. JVM и память: чем больше тем лучше? Не всегда.

Xmx & Xms <= 31Gb

- устанавите значение не более того значения, которое использует JVM для сжатия указателей, он же compressed object pointers. Данное значение составляет около 32 Гб. Стоит также отметить, что рекомендуется ограничивать heap size еще одним параметром JVM, а именно zero-based compressed oops (обычно размер около 26 Гб). 

2) Отключить подкачку.

Подкачка негативно сказывается на производительности и стабильности работы Elasticsearch, ведь система может выгрузить страницы JVM на диск.

Есть несколько вариантов работы с подкачкой:

1. Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.

sudo swapoff -a

2. Ограничение подкачки через значение vm.swappiness=1 для sysctl.

3. Использование mlockall для блокировки адресного пространства в оперативной памяти.

Чтобы включить mlockall в конфигурации Elasticseach elasticsearch.yml указываем для параметра bootstrap.memory_lock значение true:

bootstrap.memory_lock: true

Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:

curl -X GET "http://192.168.1.10:9200/_nodes?filter_path=**.mlockall&pretty"

Если перезапуск Elasticsearch завершился ошибкой вида:

[1] bootstrap checks failed

[1]: memory locking requested for elasticsearch process but memory is not locked

или проверка показывает, что данная настройка не применилась, необходимо сделать следующее в зависимости от способа установки:

1. Установите значение параметра MAX_LOCKED_MEMORY как unlimited в /etc/sysconfig/elasticsearch для rpm или /etc/default/elasticsearch для dep.

2. Если вы используете systemd для запуска Elasticsearch, то лимиты должны быть указаны через настройку параметра LimitMEMLOCK. Для этого выполните команду:

sudo systemctl edit elasticsearch

и укажите следующее значение:

[Service]

LimitMEMLOCK=infinity

3) Настроить файловые дескрипторы.

Elasticsearch работает с большим количеством файловых дескрипторов, и их нехватка может катастрофически сказаться на его работе. Согласно официальной документации необходимо указать значение файловых дескрипторов не ниже 65 536. Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.

Для установки из архива необходимо в файле /etc/security/limits.conf установить параметр nofile для пользователя, который осуществляет запуск Elasticsearch. В примере ниже таким пользователем является elasticsearch:

elasticsearch - nofile 65536

Проверить установленные значения можно следующим образом:

curl -X GET "http://10.0.3.11:9200/_nodes/stats/process?filter_path=**.max_file_descriptors&pretty"

4) Настроить размер виртуальной памяти.

Elasticsearch по умолчанию использует каталог mmapfs для хранения индексов, и ограничение операционной системы по умолчанию для счетчиков mmap может привести к нехватки памяти. Для настройки запустите из-под root следующую команду:

sysctl -w vm.max_map_count=262144

Чтобы настройка сохранилась после перезапуска системы, необходимо указать параметр vm.max_map_count в файле /etc/sysctl.conf.

Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.

5) Настроить потоки.

Необходимо убедиться, что количество потоков, которые Elasticsearch может создавать, было не менее 4096. Это можно сделать, установив ulimit -u 4096 или установив значение nproc равным 4096 в файле /etc/security/limits.conf. Если Elasticsearch работает под управлением systemd, то настройка не требуется.

6) Включить DNS кеширование.

По умолчанию Elasticsearch кеширует результат DNS на 60 и 10 секунд для положительных и отрицательных запросов. В случае необходимости можно настроить эти параметры, а именно es.networkaddress.cache.ttl и es.networkaddress.cache.negative.ttl, как JVM опции в каталоге /etc/elasticsearch/jvm.options.d/ для RPM и Deb или в $ES_HOME/config/jvm.options.d/ для установки из архива.

7) Установить временный каталог для JNA.

Elasticsearch использует Java Native Access (JNA) для запуска кода, необходимого в его работе, и извлекает этот код в свой временный каталог директории /tmp. Следовательно, если каталог смонтирован с опцией noexec, то данный код невозможно будет выполнить. В данном случае необходимо или перемонтировать каталог /tmp без опции noexec, или изменить настройку JVM, указав другой путь через опцию -Djna.tmpdir=<new_path>.

8) Еще парочка параметров.

indices.memory.index_buffer_size = 20%

index.refresh_interval = 30s 

Для параметра ParallelGCThreads установить число ядер:

-XX:ParallelGCThreads=NCPU

где NCPU равен: 

grep 'cpu cores' /proc/cpuinfo | uniq | cut -f 2 -d ':`

На этом шаге можно считать что дополнительные настройки Elasticsearch окончены.

9) Таже рекомендуется установить значения параметров для пользовательских сессий Kibana.

Закрываем неактивные сессии:

xpack.security.session.idleTimeout: "30m"

Устанавливаем максимальную продолжительность одной сессии:

xpack.security.session.lifespan: "1d"

Настраиваем интервал принудительной очистки данных о неактивных или просроченных сессиях из сессионного индекса:

xpack.security.session.cleanupInterval: "8h"

Для всех параметров формат времени может быть следующим: ms | s | m | h | d | w | M | Y

Данные о сессии удаляются после того, как пользователь осуществляет закрытие сессии. Если не настроить закрытие неактивных сессий или не ограничить максимальную длительность сессии, то информация об этих сессиях будет накапливаться в сессионном индексе, и Kibana не сможет автоматически удалить данные.

Разумеется все следует проверять и еще раз проверять в работе!  Ибо что пошло на одних параметрах у одного, у другого может отработать на других. Это жизнь!