Общий анализ логов Elasticsearch для эффективного устранения неполадок

Анализ логов Elasticsearch обычно является самым быстрым способом объяснить красный кластер, неудачный запрос индексации или жалобу на медленный поиск. Когда в кластере несколько узлов, логи сообщают вам, какой узел увидел первый сбой, какой компонент отреагировал и является ли проблема диском, памятью, обнаружением, безопасностью или восстановлением шардов.

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

Понимание структуры логов Elasticsearch

Elasticsearch использует Log4j 2 для ведения журнала. Установки из пакетов обычно записывают файлы логов в /var/log/elasticsearch/. Развертывания в контейнерах часто отправляют логи в стандартный вывод, где их собирает ваша среда выполнения контейнера или агент ведения журнала. В зависимости от вашей версии и log4j2.properties вы можете увидеть обычные текстовые логи, JSON-логи или и то, и другое.

Тип установки	Типичный путь к логам
Пакет RPM/DEB Linux	/var/log/elasticsearch/
Docker	Стандартный вывод контейнера
ZIP или tarball	$ES_HOME/logs/

Общие файлы включают основной серверный лог, логи устаревания, медленные логи, а иногда и логи аудита, если включен аудит безопасности.

Записи JSON-логов обычно включают такие поля:

• @timestamp: Когда произошло событие.
• level: Серьезность, например INFO, WARN или ERROR.
• component: Класс Elasticsearch или подсистема, которая записала сообщение.
• cluster.uuid: Идентификатор кластера.
• node.name: Узел, сгенерировавший строку лога.
• message: Текст события, понятный человеку.

{
  "@timestamp": "2024-01-15T10:30:00.123Z",
  "level": "WARN",
  "component": "o.e.c.r.a.DiskThresholdMonitor",
  "cluster.uuid": "abcde12345",
  "node.name": "es-node-01",
  "message": "high disk watermark [90%] exceeded on [es-node-01]"
}

Приоритизация сообщений по уровню логирования

Сначала фильтруйте по WARN и ERROR, затем расширяйте поиск вокруг той же временной метки. Строки перед первым ERROR часто объясняют причину лучше, чем окончательная трассировка стека.

Уровень	Что это обычно означает	Первое действие
ERROR	Запрос, шард, узел или подсистема вышли из строя.	Расследовать немедленно.
WARN	Elasticsearch обнаружил рискованное состояние.	Проверить, пока это не привело к простою.
INFO	Нормальная активность жизненного цикла.	Использовать для контекста вокруг предупреждений и ошибок.
DEBUG / TRACE	Глубокая диагностическая детализация.	Включать ненадолго только когда это необходимо.

Избегайте оставлять рабочие узлы на уровне DEBUG или TRACE. Подробное логирование может быстро заполнить диск и добавить излишнюю нагрузку.

Устранение неполадок с распространенными шаблонами логов

Логи Elasticsearch редко говорят "коренная причина - X" одним чистым предложением. Ищите шаблон: первое предупреждение, имя компонента, затронутый индекс или шард и повторяющееся сообщение, которое следует за ним.

Ошибки проверки начальной загрузки (Bootstrap Check Failures)

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

Ищите bootstrap checks failed:

[2024-01-15T10:00:00,123][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] bootstrap checks failed
[2024-01-15T10:00:00,124][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

Исправьте настройку хоста, перезапустите узел и убедитесь, что лог запуска доходит до момента, когда узел присоединяется к кластеру.

Ошибки сетевого связывания и обнаружения (Network Binding and Discovery Failures)

Если узел запускается, но не присоединяется к кластеру, ищите BindException, master not discovered, discovery и cluster.initial_master_nodes. BindException обычно указывает на конфликт адреса или порта. Сообщения об обнаружении часто указывают на неправильные хосты-семена, заблокированный транспортный порт 9300, несовпадающие имена кластеров или настройки безопасности, которые мешают узлам доверять друг другу.

Исключения автоматического выключателя (Circuit Breaker Exceptions)

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

Ищите CircuitBreakingException или Data too large:

[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02]
CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [500mb]

Распространенные причины включают большие агрегации, запросы, возвращающие слишком много полей, интенсивную пакетную индексацию или загрузку fielddata для текстовых полей. Определите шаблон запроса, затем уменьшите размер запроса, исправьте маппинги или добавьте мощности.

Предупреждения сборки мусора (Garbage Collection Warnings)

Основной лог Elasticsearch может сообщать о длительных паузах сборки мусора JVM. Ищите gc, JvmGcMonitorService и overhead. Несколько предупреждений во время всплеска нагрузки могут быть нормальными. Повторяющиеся предупреждения в паре с растущей задержкой поиска обычно означают, что куча находится под давлением.

Восстановление шардов и повреждение (Shard Recovery and Corruption)

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

Ищите shard failed, failed shard, failed to recover или имя затронутого индекса:

[2024-01-15T12:05:10,999][ERROR][o.e.i.e.Engine] [es-node-03] [my_index][2] fatal error in engine loop
java.io.IOException: Corrupt index files, checksum mismatch

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

Дисковые пороговые значения (Disk Watermarks)

Elasticsearch изменяет поведение распределения шардов, когда узлы пересекают дисковые пороговые значения. Ищите DiskThresholdMonitor, low disk watermark, high disk watermark или flood-stage disk watermark. Значения по умолчанию могут различаться в зависимости от версии и конфигурации, поэтому перед действием проверьте настройки вашего кластера:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Если индекс стал доступен только для чтения после события flood-stage, сначала освободите дисковое пространство. Затем снимите блокировку только после того, как узел безопасно окажется ниже порогового значения:

PUT /my-index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Использование медленных логов для проблем с производительностью

Для медленных операций поиска или индексации основной серверный лог часто слишком общий. Медленные логи отслеживают операции, превышающие настроенные пороговые значения. Настройте их для каждого индекса с помощью API настроек индекса.

PUT /my_index/_settings
{
  "index.search.slowlog.threshold.query.warn": "1s",
  "index.search.slowlog.threshold.query.info": "500ms",
  "index.indexing.slowlog.threshold.index.warn": "1s"
}

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

Практический рабочий процесс анализа

Начните с видимого пользователю симптома и двигайтесь назад:

1. Проверьте работоспособность кластера и затронутый индекс.
2. Поищите логи WARN и ERROR вокруг времени инцидента.
3. Сравните логи на разных узлах, используя node.name и cluster.uuid.
4. Следуйте за первым повторяющимся предупреждением, а не только за финальным исключением.
5. Затем используйте целевой API: allocation explain для неназначенных шардов, медленные логи для медленных запросов и статистику узлов для оценки нагрузки на ресурсы.

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

Вывод

Начинайте каждый инцидент с Elasticsearch с поиска первого соответствующего предупреждения или ошибки, а не самого громкого финального стека вызовов. Используйте основные логи для сбоев узлов, обнаружения, диска, памяти и шардов. Используйте медленные логи, когда кластер здоров, но конкретные поиски или рабочие нагрузки индексации работают медленно.