Мониторинг кластера
Тема дорожной карты · Elasticsearch
Мониторинг кластера Elasticsearch необходим для поддержания работоспособности, производительности и надёжности поискового движка в продуктивных средах. Elasticsearch предоставляет богатый набор API мониторинга: GET /_cluster/health, GET /_nodes/stats, GET /_cat/indices и GET /_cat/shards — они позволяют получать такие метрики, как использование кучи JVM, задержка поиска и индексирования, количество шардов и использование диска. Рекомендованный подход к мониторингу в рамках Elastic Stack — включение Stack Monitoring в Kibana, которое собирает метрики Elasticsearch в отдельный мониторинговый кластер (отдельный от производственного, чтобы накладные расходы мониторинга не влияли на производительность поиска). Ключевые метрики при мониторинге Elasticsearch: давление на кучу JVM (оповещение выше 75 %), длительность пауз сборки мусора, счётчики отклонённых запросов в пулах потоков (особенно bulk и search), а также перцентили задержки запросов. Внешние системы мониторинга, такие как Prometheus, также могут собирать метрики Elasticsearch через плагин Prometheus Exporter, интегрируя мониторинг кластера в существующие стеки наблюдаемости.
Как это работает
Мониторинг кластера: JVM тюнинг — heap = 50% RAM, max 31GB (граница compressed oops), G1GC на современных JDK. Bulk indexing — отключите refresh во время bulk (-1), увеличьте translog flush threshold, batch 5-15MB. Search optimisation — filter context (cacheable), ограничивайте specific индексами через aliases, избегайте wildcards на big-индексах, profile API для slow queries. Мониторинг через Stack Monitoring app (или Prometheus exporter — prometheus-es-exporter).
Когда применять
Меряйте до тюнинга — profile API + slow log для идентификации проблем. Для ingest bottleneck: больше bulk batches + больше клиентов + refresh off. Для search bottleneck: cache (filter context), trim полей через _source filtering, force-merge cold-индексов. Для cluster stability: dedicate роли, тюньте thread_pool sizes, мониторьте circuit_breakers.
Типичные ошибки
Ловушки Мониторинг кластера: heap = 100% RAM (нет OS file cache — медленные queries); heap > 32GB (теряет compressed oops); выключают refresh + забывают включить обратно; force-merge hot-индексов (locks + I/O storm).