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

Elasticsearch — это мощный, распределенный поисковый и аналитический движок, но его сложность означает, что когда что-то идет не так, диагностировать первопричину может быть непросто. Самым важным инструментом для эффективного устранения неполадок является файл логов Elasticsearch. Эти логи служат оперативным дневником системы, записывая все: от успешных последовательностей запуска и планового обслуживания кластера до критических сбоев, таких как срабатывание предохранителя памяти или сбои в размещении шардов.

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

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

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

Расположение логов по умолчанию

Основные файлы логов обычно находятся в следующих местах, в зависимости от метода установки (например, пакет RPM/DEB, Docker или ZIP-файл):

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

Анатомия записи в логе

Каждая запись в логе, особенно в формате JSON, содержит несколько ключевых полей, критически важных для контекста:

@timestamp: Время, когда произошло событие.
level: Серьезность события (например, INFO, WARN, ERROR).
component: Конкретный класс или служба Elasticsearch, сгенерировавшая сообщение (например, o.e.c.c.ClusterService, o.e.n.Node). Это помогает сузить круг ответственной подсистемы.
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]"
}

2. Приоритизация устранения неполадок по уровням логов

Интерпретация поля level — самый быстрый способ приоритизировать проблемы. Вам следует, как правило, сначала фильтровать логи, чтобы сосредоточиться на сообщениях уровня WARN и ERROR.

Уровень	Описание	Приоритет действий
ERROR	Критические сбои, приводящие к простою службы или потере данных (например, остановка узла, серьезный сбой шарда).	Немедленно
WARN	Потенциальные проблемы или состояния, требующие мониторинга (например, устаревшие настройки, мало места на диске, предохранитель приближается к пределам).	Высокий
INFO	Общие операционные сообщения (например, запуск узла, создание индекса, завершение размещения шарда).	Низкий/Мониторинг
DEBUG/TRACE	Очень подробное логирование, используемое только при глубокой диагностике или разработке.	Н/Д (Если активно не отлаживается)

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

3. Устранение распространенных сценариев с помощью логов

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

3.1. Проблемы с запуском и состоянием кластера

Если узел не может присоединиться к кластеру или кластер остается красным/желтым, ищите логи, сгенерированные во время последовательности запуска.

A. Сбои проверок загрузки (Bootstrap Checks)

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]

B. Сбои при привязке к сети и обнаружении

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

Шаблон лога: Ищите BindException или Discovery failure.

3.2. Управление ресурсами (Память и JVM)

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

A. Исключения предохранителя (Circuit Breaker Exceptions)

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

Шаблон лога: Ищите CircuitBreakerException или Data too large.

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

B. Проблемы со сборкой мусора JVM (GC)

Хотя подробные логи GC часто находятся отдельно, основной лог Elasticsearch иногда сообщает о высокой активности GC или длительных паузах GC (события «stop-the-world»).

Шаблон лога: Ищите ссылки GC, особенно если появляются сообщения уровня WARN или ERROR о длительных паузах.

3.3. Сбои индексирования и размещения шардов

Сбои индексирования или поврежденные данные часто вызывают события сбоя шарда.

A. Размещение и сбой шарда

Если шард не удается разместить или узел обнаруживает проблему повреждения локальной копии шарда, это регистрируется в логе.

Шаблон лога: Ищите shard failed или failed to recovery.

[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

B. Пороговые значения диска (Disk Watermarks)

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

Шаблон лога: Ищите предупреждения DiskThresholdMonitor, которые обычно указывают на использование 85% (low) или 90% (high).

4. Настройка производительности с помощью медленных логов (Slow Logs)

Для анализа производительности, особенно медленных запросов или операций индексирования, основные логи кластера часто бывают недостаточными. Elasticsearch использует специализированные Медленные логи (Slow Logs).

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

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

Вы можете установить разные пороговые значения для фаз индексирования и поиска. В следующем примере устанавливается пороговое значение WARN в 1 секунду для поисковых запросов в определенном индексе.

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"
}

Интерпретация записей в медленных логах

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

Ключевые метрики, на которые следует обратить внимание:

took: Общее время, затраченное на операцию.
source: Полный текст запроса или операции индексации.
id: Идентификатор контекста поиска.

5. Лучшие практики анализа логов

Эффективное устранение неполадок зависит не только от знания того, куда смотреть, но и от системного подхода.

A. Централизация логов

В распределенной среде ручной просмотр логов на десятках узлов непрактичен. Используйте централизованные инструменты логирования, такие как Logstash, Filebeat или специализированные службы логирования, для агрегирования логов в один индекс Elasticsearch (часто называемый «кластером логирования»). Это позволяет вам одновременно искать, фильтровать и сопоставлять события по всем узлам.

B. Сопоставление событий между узлами

Ищите связанные события, используя поля @timestamp и cluster.uuid. Сбой шарда на node-A может быть зарегистрирован как ERROR на этом узле, но менеджер кластера, работающий на node-B, зарегистрирует INFO или WARN о последующей попытке перераспределения шарда.

C. Следите за повторяющимися шаблонами

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

D. Не игнорируйте сообщения WARN

Предупреждения часто служат ранними индикаторами будущих катастрофических сбоев. Например, повторяющиеся сообщения WARN об устаревших настройках или низком использовании памяти следует устранять проактивно, прежде чем они перерастут в сбои уровня ERROR.

Заключение

Логи Elasticsearch — это бесценный ресурс, предоставляющий необходимый контекст для перехода от симптоматического исправления к диагностике первопричины нестабильности кластера или плохой производительности. Понимая стандартную структуру логов, приоритизируя сообщения на основе серьезности и целенаправленно используя медленные логи для настройки производительности, администраторы могут значительно сократить время простоя и поддерживать надежное состояние кластера.