Где Elasticsearch хранит логи?

Как Elasticsearch хранит и использует логи

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

1. Логи Elasticsearch (логи кластера)

Это системные логи, которые генерирует сам процесс Elasticsearch. Они хранятся локально на файловой системе каждого узла кластера, в директории, указанной в конфигурационном файле elasticsearch.yml.

• Путь по умолчанию: обычно это поддиректория logs внутри пути установки Elasticsearch (например, /var/log/elasticsearch/ или /usr/share/elasticsearch/logs).
• Конфигурация: путь можно задать через параметр path.logs:

# Пример elasticsearch.yml
path.logs: /var/log/my-elasticsearch-cluster

• Основные файлы логов:

    *   **`elasticsearch.log`** (или `<cluster_name>.log`): основной файл логов, содержащий информацию о работе узла, ошибках, событиях кластера (например, присоединение узлов, шаarding).
    *   **`gc.log`** (или несколько файлов): логи сборщика мусора (Garbage Collector) Java, критически важные для диагностики проблем с памятью и производительностью.
    *   **`slowlogs`** (индексируются в отдельные файлы): логи медленных запросов (search slow log и indexing slow log). Их можно настроить с определенными thresholds.
    *   **`deprecation.log`**: логи, предупреждающие об использовании deprecated функционала, который будет удален в будущих версиях.

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

• Filebeat (часть Elastic Stack): для сбора и отправки этих файловых логов в другой кластер Elasticsearch (например, в логовый или мониторинговый кластер).
• Системы мониторинга: Elasticsearch собственный Elastic APM, Prometheus + Grafana (через exporters).

2. Логи приложений (данные, индексированные в Elasticsearch)

Когда Elasticsearch используется как централизованное хранилище логов (в рамках ELK/Elastic Stack), сами данные логов (сообщения из Apache, Nginx, системные syslog, логи приложений) хранятся в индексах Elasticsearch. Это его основная функция — поисковый движок.

• Механизм: Логи собираются агентами (например, Beats: Filebeat, Metricbeat) или шинами (Logstash) и отправляются в Elasticsearch через его API (обычно HTTP).
• Структура: Логи становятся документами JSON внутри индексов. Каждый индекс состоит из шардов (первичных и реплик), которые физически представляют собой Lucene-индексы на диске.
• Расположение данных: Шарды хранятся в директории path.data, указанной в elasticsearch.yml. Каждый шард — это набор файлов на диске (segments, инвертированные индексы).

# Пример elasticsearch.yml
path.data:
  - /data1/elasticsearch-data
  - /data2/elasticsearch-data # Можно указать несколько путей

Ключевые различия и рекомендации

1. Разделение ответственности: Логи кластера (elasticsearch.log) нужны для администрирования и здоровья самого Elasticsearch. Логи в индексах — это бизнес-данные, которые он обслуживает.
2. Ротация логов кластера: Файлы elasticsearch.log и gc.log могут расти. Управление их ротацией часто осуществляется через logrotate (в Linux) или встроенные механизмы JVM (для gc.log). Нельзя допускать, чтобы они заполнили диск узла.
3. Мониторинг: Для полноценного мониторинга здоровья кластера необходимо анализировать оба типа логов. Логи кластера показывают внутренние проблемы (например, отказ узла, проблемы с сетью), а метрики и логи приложений в индексах могут показать проблемы с производительностью запросов.
4. Best Practice: В production-окружении стандартной практикой является создание отдельного, меньшего логового кластера Elasticsearch, в который с помощью Filebeat отправляются логи основного кластера (elasticsearch.log, gc.log). Это позволяет:

    *   Централизованно анализировать логи всех узлов.
    *   Не создавать циклическую зависимость (логи основного кластера не пишутся в него же, что может усугубить проблемы при его сбое).
    *   Снизить нагрузку на основной кластер.

Вывод: Elasticsearch хранит свои системные логи как файлы на диске каждого узла, а логи приложений — как индексированные данные внутри своих шардов. Управление первыми требует инфраструктурных решений (logrotate, Filebeat), управление вторыми — стандартных операций с индексами (ротация, retention политики, шаarding).