Мониторинг и здоровье кластера

Когда Elasticsearch работает в бою, первый вопрос при любой проблеме — «что вообще происходит с кластером?». Три API отвечают на него быстрее всего: _cluster/health, _cat и _nodes/stats. Разберём их по порядку.

Три цвета здоровья: green, yellow, red

Elasticsearch сводит состояние кластера к одному из трёх статусов — прямо как светофор.

Светофор — метафора трёх статусов здоровья кластера: green, yellow, red.Source: https://travelask.ru/blog/posts/16547-pochemu-signaly-svetofora-imeyut-imenno-krasnyy-zheltyy-i-ze
СтатусЧто означает
greenВсе primary-шарды и все реплики назначены и доступны. Кластер работает в полную силу.
yellowВсе primary-шарды назначены, но хотя бы одна реплика — нет. Данные целы, поиск работает, но отказоустойчивость снижена.
redХотя бы один primary-шард не назначен. Часть данных недоступна для поиска и индексации. Требует немедленного внимания.

Важный нюанс: статус кластера — это минимум по всем индексам. Один красный индекс окрашивает весь кластер в red, даже если 99 остальных зелёные.

flowchart TD A{"Все primary-шарды\nназначены?"} -->|Нет| R["RED\nЧасть данных недоступна"] A -->|Да| B{"Все реплики\nназначены?"} B -->|Нет| Y["YELLOW\nОтказоустойчивость снижена"] B -->|Да| G["GREEN\nКластер полностью здоров"] style R fill:#e84040,color:#fff,stroke:#c00 style Y fill:#f5a623,color:#333,stroke:#c87d00 style G fill:#52c41a,color:#fff,stroke:#389e0d
flowchart TD
    A{"Все primary-шарды\nназначены?"} -->|Нет| R["RED\nЧасть данных недоступна"]
    A -->|Да| B{"Все реплики\nназначены?"}
    B -->|Нет| Y["YELLOW\nОтказоустойчивость снижена"]
    B -->|Да| G["GREEN\nКластер полностью здоров"]
    style R fill:#e84040,color:#fff,stroke:#c00
    style Y fill:#f5a623,color:#333,stroke:#c87d00
    style G fill:#52c41a,color:#fff,stroke:#389e0d
Как Elasticsearch определяет статус кластера по состоянию шардов
Check yourself
У вас кластер из трёх нод с пятью индексами. Четыре зелёных, один жёлтый. Каким будет общий статус в `GET /_cluster/health`?

GET /_cluster/health

Самый быстрый способ получить статус — запросить _cluster/health:

GET /_cluster/health

Типичный ответ:

{
  "cluster_name": "my-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 12,
  "active_shards": 12,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 5,
  "active_shards_percent_as_number": 70.6
}

Ключевые поля:

  • status — green / yellow / red.
  • unassigned_shards — сколько шардов не назначено ни одной ноде. Ненулевое значение — сигнал для расследования.
  • relocating_shards — шарды в процессе переноса между нодами. Небольшое число нормально при ребалансировке; большое — кластер под нагрузкой.
  • initializing_shards — шарды, которые только что назначены ноде и восстанавливаются.
  • active_shards_percent_as_number — процент доступных шардов от ожидаемого числа. При $100\%$ кластер полностью здоров.

Проверить здоровье одного индекса:

GET /_cluster/health/products

Дождаться зелёного статуса перед следующим шагом (удобно в скриптах и автоматизации):

GET /_cluster/health?wait_for_status=green&timeout=30s

_cat API: читаемый вывод для диагностики

_cluster/health возвращает JSON — нужно разбирать глазами. Для быстрой диагностики в Kibana Dev Tools удобнее _cat-API: он выдаёт таблицы в текстовом виде.

#### Состояние индексов

GET /_cat/indices?v&s=health

Флаг v добавляет заголовки столбцов, s=health сортирует по статусу (red сверху). Пример вывода:

health status index    pri rep docs.count store.size
red    open   orders   1   1        5432       12mb
yellow open   products 1   1       18341       45mb
green  open   users    1   0        2100        8mb

Первый столбец — статус, сразу видно проблемные индексы.

#### Состояние нод

GET /_cat/nodes?v&h=name,ip,heap.percent,ram.percent,cpu,load_1m,node.role

Флаг h выбирает конкретные столбцы. Полезные метрики:

  • heap.percent — использование Java heap. Тревожно при $> 85\%$ стабильно, критично при $> 95\%$ — начинаются частые GC-паузы.
  • cpu — загрузка CPU в процентах.
  • load_1m — средняя нагрузка за 1 минуту (Unix load average).
  • node.role — роли ноды: m (master-eligible), d (data), i (ingest).

#### Шарды и их статусы

GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason&s=state

Это самый полезный запрос при диагностике проблем. Столбец state может быть:

  • STARTED — шард работает нормально.
  • INITIALIZING — восстанавливается.
  • RELOCATING — переезжает на другую ноду.
  • UNASSIGNED — не назначен. Колонка unassigned.reason объяснит почему.
Check yourself
В выводе `GET /_cat/shards` вы видите: индекс `orders`, шард 0, prirep=`r` (реплика), state=`UNASSIGNED`. Primary этого же шарда — `STARTED`. Какой статус у кластера и почему?

Почему шарды становятся unassigned

Unassigned-шарды — самая распространённая причина yellow и red статусов. Вот типичные сценарии и что с ними делать.

1. Реплики на кластере с одной нодой

Самый частый случай у новичков: вы подняли один Docker-контейнер (одна нода), создали индекс с number_of_replicas: 1. Реплику некуда разместить — нет второй ноды. Результат: yellow. Решение для dev-окружения — выставить реплики в 0:

PUT /products/_settings
{
  "index.number_of_replicas": 0
}

2. Нода покинула кластер

Если нода упала или потеряла связь, её шарды становятся unassigned. ES ждёт около минуты (настройка index.unassigned.node_left.delayed_timeout), прежде чем начать перераспределение — это защита от случая «нода временно перезагрузилась».

3. Нехватка дискового пространства

ES не назначит шард на ноду, у которой диск заполнен больше чем на $85\%$ (настройка cluster.routing.allocation.disk.watermark.low). Проверить заполненность дисков всех нод:

GET /_cat/allocation?v

Пример вывода:

shards disk.indices disk.used disk.avail disk.total disk.percent host      ip        node
    12       45.2mb    18.3gb     61.6gb     79.9gb           23 127.0.0.1 127.0.0.1 node-1
     5       22.1mb     9.1gb     70.8gb     79.9gb           11 127.0.0.2 127.0.0.2 node-2

4. Повреждённые данные или несовместимость версий

После аппаратного сбоя или неудачной миграции шард может не восстановиться. Причину покажет unassigned.reason = ALLOCATION_FAILED.

Универсальный диагностический запрос

Для любого unassigned-шарда ES умеет объяснить, почему он не назначается:

GET /_cluster/allocation/explain

Без тела запроса ES сам выберет первый unassigned-шард и вернёт подробное объяснение: на каких нодах шард мог бы оказаться и почему не оказался на каждой из них. Это первый инструмент при любом yellow/red.

Check yourself
Вы подняли ES через Docker (одна нода), создали индекс `PUT /catalog` без параметров, и Kibana показывает yellow. Какова самая вероятная причина и как её быстро исправить в dev-окружении?

Базовые метрики нагрузки

Помимо статуса шардов, важно понимать, не перегружен ли кластер.

#### _nodes/stats — детали по нодам

GET /_nodes/stats/indices,jvm,os

Ключевые поля в ответе:

  • jvm.mem.heap_used_percent — heap каждой ноды.
  • os.cpu.percent — загрузка CPU.
  • indices.search.query_time_in_millis и indices.search.query_total — суммарное время поиска и число запросов.
  • indices.indexing.index_time_in_millis и indices.indexing.index_total — то же для индексации.

Например, если query_time_in_millis = 150000 и query_total = 1000, среднее время запроса $= \frac{150\,000}{1\,000} = 150$ мс. Для полнотекстового поиска по небольшому индексу $< 50$ мс — норма; при $> 500$ мс — стоит разбираться с запросами или шардами.

#### Ориентиры для тревоги

МетрикаКогда беспокоиться
heap.percent$> 85\%$ стабильно
cpu на нодах$> 70\%$ стабильно
unassigned_shardsлюбое $> 0$
active_shards_percent$< 100\%$
relocating_shards$> 0$ продолжительное время

Быстрая диагностика: стандартная последовательность

Если что-то пошло не так — начинайте с этих пяти запросов:

# 1. Общий статус кластера
GET /_cluster/health

# 2. Какие индексы в проблеме?
GET /_cat/indices?v&s=health

# 3. Какие конкретно шарды unassigned и почему?
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason&s=state

# 4. Подробное объяснение для первого unassigned-шарда
GET /_cluster/allocation/explain

# 5. Загрузка нод: heap, CPU, диск
GET /_cat/nodes?v&h=name,heap.percent,cpu,load_1m,disk.used_percent

Эта пятёрка закрывает большинство диагностических сценариев.

Quick recall
При каком проценте использования Java heap на ноде начинаются тревожные GC-паузы?
Quick recall
Кластер перешёл в статус red. Почему это требует немедленного внимания?
Quick recall
Вы подняли Elasticsearch в Docker (одна нода), создали индекс и получили статус yellow. Индекс работает нормально. Почему кластер не зелёный?

См. также