Коротко. В Directum RX данные в Elasticsearch попадают через очередь RabbitMQ и сервис индексирования, а при полнотекстовом поиске ещё и через сервис хранилищ. На отдельном сервере нужно правильно задать ELASTICSEARCH_URL (лучше через прокси с TLS), учётную запись и разные постфиксы индексов для разных систем. После переноса Elasticsearch, восстановления RX или смены префикса нужно первоначальное индексирование. Поиск, который не находит свежие документы, чаще всего упирается в недоступность сервера, индекс в режиме только чтения из-за диска или очередь индексирования.

Elasticsearch для Directum RX часто ставят на отдельный сервер: у поисковой системы свои требования к памяти и дискам, и делить их с сервером приложений неудобно. Схема рабочая, но добавляет звенья, на которых поиск тихо перестаёт работать. Разбираем, как RX ходит в Elasticsearch, что настроить при разнесении на разные серверы и что смотреть, когда поиск отстаёт или ничего не находит.

Симптом

Типичные жалобы после разнесения или переезда Elasticsearch:

  • полнотекстовый поиск не находит свежие документы, а старые находит;
  • поиск не находит ничего, хотя документы на месте;
  • после переезда поиск работает, но результаты не совпадают с тем, что есть в системе;
  • на панели здоровья или в журналах ошибки доступа к Elasticsearch.

Почему так

Elasticsearch в RX используется для двух вещей: полнотекстового поиска по содержимому документов, задач и заданий и, если это включено, для поиска по критериям вместо СУБД. Данные в поисковую систему попадают не сразу из веб-сервера, а через отдельный сервис индексирования (IndexingService):

  1. Пользователь сохраняет документ или его версию.
  2. Веб-сервер кладёт запрос на индексирование в очередь RabbitMQ.
  3. Сервис индексирования забирает запрос, при полнотекстовом поиске получает содержимое документа у сервиса хранилищ и отправляет данные в Elasticsearch.

Поэтому «поиск не работает» может значить сбой в любом из четырёх мест: очередь, сервис индексирования, сервис хранилищ или сам Elasticsearch. Отдельный сервер добавляет пятое: сеть между сервисом индексирования и поисковой системой.

Что настроить при отдельном сервере

Подключение задаётся в общих настройках RX:

Параметр Что в нём На что обратить внимание
ELASTICSEARCH_URL адрес вида https://es.company.ru:443 или http://адрес:9200 если пусто, сервис индексирования ничего не индексирует и проверка его работоспособности не выполняется
ELASTICSEARCH_INDEX_POSTFIX постфикс индексов, например prod, test у рабочей и тестовой системы на одном Elasticsearch постфиксы должны отличаться, иначе они пишут в одни индексы
ELASTICSEARCH_INDEX_PREFIX необязательный префикс нужен, если на том же Elasticsearch живут другие системы
ELASTICSEARCH_LOGIN, ELASTICSEARCH_PASSWORD учётная запись Elasticsearch указываются оба или ни одного
ELASTICSEARCH_SHOW_QUERIES журнал запросов к Elasticsearch включать на время разбора, после первоначального индексирования

При установке через Directum Launcher адрес отдельного сервера указывают в параметре установки Elasticsearch, иначе там останется localhost. Если поисковая система открыта в сеть, вендор рекомендует закрыть порт 9200 и ставить перед ней прокси nginx с TLS и аутентификацией. Тогда в ELASTICSEARCH_URL указывается адрес прокси.

Что ещё проверить при разнесении:

  • Сетевой доступ. С серверов, где работает сервис индексирования и веб-сервер, должен открываться адрес из ELASTICSEARCH_URL. Проверка одной командой: curl -s -u логин https://es.company.ru/_cluster/health.
  • Доверие к сертификату прокси. Если сертификат выпущен своим удостоверяющим центром, его корневой сертификат должен быть в доверенных на серверах RX. Иначе соединение падает на проверке цепочки.
  • Память и диски самого Elasticsearch. Куча JVM, свободное место и число шардов считаются отдельно от сервера приложений. Посчитать можно в нашем калькуляторе Elasticsearch.

Диагностика

  1. Есть ли связь. Запрос _cluster/health с сервера RX по тому же адресу и с той же учётной записью, что в настройках. Статус red или отказ подключения объясняет всё остальное. Разбор красного статуса есть в справочнике: cluster health red.
  2. Не стоит ли индекс на запись. Когда диск сервера Elasticsearch заполнен выше порога, индексы переводятся в режим только чтения, и новые документы перестают попадать в поиск без явной ошибки для пользователя: read-only-allow-delete.
  3. Не копится ли очередь индексирования. Если в RabbitMQ растёт очередь сервиса индексирования, а сам сервис жив, он не успевает или падает на каждом сообщении. Смотреть его журнал.
  4. Какие ошибки у сервиса индексирования. Типичные: недоступен Elasticsearch, отказ аутентификации, слишком длинное значение для поля (immense term), предел шардов (maximum shards open), нехватка памяти (circuit breaking exception).
  5. Совпадают ли префикс и постфикс с теми, под которыми строились индексы. После их смены поиск смотрит в новые, пустые индексы.

Что сделать

  1. После переноса Elasticsearch на новый сервер, восстановления RX из резервной копии или смены префикса и постфикса запустить первоначальное индексирование утилитой InitialIndexing. Без него в поисковой системе только то, что изменилось после переключения.
  2. Мониторить поисковую систему как отдельный сервер: статус кластера, свободное место относительно порогов, кучу JVM, размер очереди индексирования. Если один из этих сигналов ушёл, поиск начнёт отставать раньше, чем пожалуются пользователи.
  3. Для рабочей и тестовой систем держать разные постфиксы индексов, а лучше разные кластеры Elasticsearch.

Чего не делать

  • Не открывать порт 9200 в сеть без прокси и аутентификации. В индексах лежит текст документов.
  • Не переносить индексы копированием каталогов данных между серверами с разными версиями Elasticsearch. Надёжнее построить индексы заново первоначальным индексированием.
  • Не оставлять ELASTICSEARCH_SHOW_QUERIES включённым после разбора: журнал запросов быстро растёт.
  • Не очищать ELASTICSEARCH_URL, чтобы «убрать ошибки» на время работ, и не забывать вернуть: пока он пуст, ничего не индексируется, и после возврата потребуется первоначальное индексирование.