Устранение распространённых проблем кластера

В данном руководстве описывается, как устранять распространённые ошибки и проблемы с кластерами Elasticsearch.

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

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

Чтобы проверить, перемещаются ли фрагменты с затронутого узла, используйте API cat shards.

GET _cat/shards?v=true

Если фрагменты остаются на узле, используйте API cluster allocation explanation, чтобы получить объяснение статуса их размещения.

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": false,
  "current_node": "my-node"
}

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

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "90%",
    "cluster.routing.allocation.disk.watermark.high": "95%",
    "cluster.routing.allocation.disk.watermark.flood_stage": "97%"
  }
}

PUT */_settings?expand_wildcards=all
{
  "index.blocks.read_only_allow_delete": null
}

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

DELETE my-index

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

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": null,
    "cluster.routing.allocation.disk.watermark.high": null,
    "cluster.routing.allocation.disk.watermark.flood_stage": null
  }
}

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

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

Сообщения об ошибках

Если запрос вызывает срабатывание блокировщика цепи, Elasticsearch возвращает ошибку со статусом HTTP 429.

{
  'error': {
    'type': 'circuit_breaking_exception',
    'reason': '[parent] Data too large, data for [<http_request>] would be [123848638/118.1mb], which is larger than the limit of [123273216/117.5mb], real usage: [120182112/114.6mb], new bytes reserved: [3666526/3.4mb]',
    'bytes_wanted': 123848638,
    'bytes_limit': 123273216,
    'durability': 'TRANSIENT'
  },
  'status': 429
}

Elasticsearch также записывает ошибки блокировщика цепи в elasticsearch.log. Это полезно, когда автоматизированные процессы, такие как размещение, вызывают срабатывание блокировщика цепи.

Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [num/numGB], which is larger than the limit of [num/numGB], usages [request=0/0b, fielddata=num/numKB, in_flight_requests=num/numGB, accounting=num/numGB]

Проверка использования памяти JVM

Если вы включили мониторинг стека, вы можете просмотреть использование памяти JVM в Kibana. В главном меню нажмите Мониторинг стека. На странице обзора мониторинга стека нажмите Узлы. В столбце Куча JVM указано текущее использование памяти для каждого узла.

Вы также можете использовать API cat nodes, чтобы получить текущее значение heap.percent для каждого узла.

GET _cat/nodes?v=true&h=name,node*,heap*

Чтобы получить использование памяти JVM для каждого блокировщика цепи, используйте API node stats.

GET _nodes/stats/breaker

Снижение нагрузки на память JVM

Высокая нагрузка на память JVM часто приводит к ошибкам блокировщика цепи. См. Высокая нагрузка на память JVM.

Избегайте использования fielddata для text полей

Для полей с высокой кардинальностью text fielddata может использовать большое количество памяти JVM. Чтобы этого избежать, Elasticsearch по умолчанию отключает fielddata для text полей. Если вы включили fielddata и вызвали срабатывание блокировщика цепи fielddata, рассмотрите возможность его отключения и использования keyword поля вместо него. См. fielddata параметр сопоставления.

Очистить кэш fieldata

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

POST _cache/clear?fielddata=true

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

Если пул потоков исчерпан, Elasticsearch будет отклонять запросы, связанные с пулом потоков. Например, если пул потоков search исчерпан, Elasticsearch будет отклонять поисковые запросы, пока не появятся дополнительные потоки.

Проверка использования ЦП

GET _cat/nodes?v=true&s=cpu:desc

GET _cat/nodes?v=true&s=cpu:desc

Проверка горячих потоков

Если у узла высокое использование ЦП, используйте API nodes hot threads, чтобы проверить потоки с высокой загрузкой ресурсов, работающие на узле.

GET _nodes/my-node,my-other-node/hot_threads

Этот API возвращает детализацию любых горячих потоков в формате простого текста.

В следующих советах описаны наиболее частые причины высокого использования ЦП и их решения.

Масштабирование вашего кластера

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

Распределение массовых запросов

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

Отмена длительных поисков

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

GET _tasks?actions=*search&detailed

Ответ содержит description поискового запроса и его запросы. running_time_in_nanos отображает, как долго запрос на поиск выполнялся.

{
  "nodes" : {
    "oTUltX4IQMOUUVeiohTt8A" : {
      "name" : "my-node",
      "transport_address" : "127.0.0.1:9300",
      "host" : "127.0.0.1",
      "ip" : "127.0.0.1:9300",
      "tasks" : {
        "oTUltX4IQMOUUVeiohTt8A:464" : {
          "node" : "oTUltX4IQMOUUVeiohTt8A",
          "id" : 464,
          "type" : "transport",
          "action" : "indices:data/read/search",
          "description" : "indices[my-index], search_type[QUERY_THEN_FETCH], source[{\"query\":...}]",
          "start_time_in_millis" : 4081771730000,
          "running_time_in_nanos" : 13991383,
          "cancellable" : true
        }
      }
    }
  }
}

Для отмены поиска и освобождения ресурсов используйте конечную точку _cancel API.

POST _tasks/oTUltX4IQMOUUVeiohTt8A:464/_cancel

Дополнительные советы по отслеживанию и избеганию ресурсоёмких поисков см. в разделе Избегание дорогостоящих запросов.

Высокое использование памяти JVM может ухудшить производительность кластера и вызвать ошибки блокировщика цепи. Для предотвращения этого рекомендуется принять меры для снижения нагрузки на память, если использование памяти JVM узла постоянно превышает 85%.

Проверка нагрузки на память JVM

GET _nodes/stats?filter_path=nodes.*.jvm.mem.pools.old

GET _nodes/stats?filter_path=nodes.*.jvm.mem.pools.old

Проверка журналов сборки мусора

По мере увеличения использования памяти сборка мусора становится более частой и занимает больше времени. Вы можете отслеживать частоту и продолжительность событий сборки мусора в elasticsearch.log. Например, следующее событие указывает, что Elasticsearch потратил более 50% (21 секунду) последних 40 секунд на выполнение сборки мусора.

[timestamp_short_interval_from_last][INFO ][o.e.m.j.JvmGcMonitorService] [node_id] [gc][number] overhead, spent [21s] collecting in the last [40s]

Уменьшить количество фрагментов

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

Избегайте дорогостоящих запросов

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

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

PUT _settings
{
  "index.max_result_window": 5000
}

PUT _cluster/settings
{
  "persistent": {
    "search.max_buckets": 20000,
    "search.allow_expensive_queries": false
  }
}

Предотвращение взрывов схемы

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

Распределять запросы bulk

Хотя более эффективны, чем отдельные запросы, большие bulk операции индексирования или multi-search запросы все равно могут создавать высокую нагрузку на память JVM. Если это возможно, отправляйте меньшие запросы и дайте больше времени между ними.

Обновить память узла

Высокая нагрузка при индексировании и поиске может привести к высокой нагрузке на память JVM. Для лучшего выполнения больших задач модернизируйте узлы, увеличив их объем памяти.

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

Проверьте статус вашего кластера

Используйте API состояния кластера.

GET _cluster/health?filter_path=status,*_shards

Здоровый кластер имеет зеленый status и ноль unassigned_shards. Желтый статус означает, что не назначены только реплики. Красный статус означает, что один или несколько первичных фрагментов не назначены.

Просмотр неназначенных фрагментов

Чтобы просмотреть неназначенные фрагменты, используйте API cat shards.

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

У неназначенных фрагментов есть state значении UNASSIGNED. Значение prirep равно p для первичных фрагментов и r для реплик.

Чтобы понять, почему неназначенный фрагмент не назначается и какие действия необходимо выполнить, чтобы разрешить Elasticsearch назначить его, используйте API объяснения распределения кластера.

GET _cluster/allocation/explain?filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*
{
  "index": "my-index",
  "shard": 0,
  "primary": false,
  "current_node": "my-node"
}

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

Возобновить распределение фрагментов

Обычно вы отключаете распределение во время перезагрузки или других обслуживаний кластера. Если вы забыли повторно включить распределение, Elasticsearch не сможет назначить фрагменты. Для повторного включения распределения сбросьте кластерную настройку cluster.routing.allocation.enable.

PUT _cluster/settings
{
  "persistent" : {
    "cluster.routing.allocation.enable" : null
  }
}

Восстановить потерянные узлы

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

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

POST _cluster/reroute

Исправить настройки распределения

Неправильно настроенные настройки распределения могут привести к неназначенному первичному фрагменту. Эти настройки включают:

Чтобы просмотреть настройки распределения, используйте API получения настроек индекса и API получения настроек кластера.

GET my-index/_settings?flat_settings=true&include_defaults=true

GET _cluster/settings?flat_settings=true&include_defaults=true

Вы можете изменить настройки, используя API обновления настроек индекса и API обновления настроек кластера.

Распределять или уменьшать реплики

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

PUT _settings
{
  "index.number_of_replicas": 1
}

Освободить или увеличить дисковое пространство

Elasticsearch использует пороговое значение низкого уровня диска, чтобы гарантировать, что узлы данных имеют достаточно дискового пространства для входящих фрагментов. По умолчанию Elasticsearch не распределяет фрагменты на узлы, использующие более 85% дискового пространства.

Чтобы проверить текущее дисковое пространство ваших узлов, используйте API cat allocation.

GET _cat/allocation?v=true&h=node,shards,disk.*

Если на ваших узлах мало места на диске, у вас есть несколько вариантов:

Снижение нагрузки на память JVM

Распределение фрагментов требует памяти кучи JVM. Высокая нагрузка на память JVM может активировать разрывы цепи, которые останавливают распределение и оставляют фрагменты неназначенными. См. Высокую нагрузку на память JVM.

Восстановление данных для потерянного основного фрагмента

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

Используйте API перенаправления кластера, чтобы вручную назначить незаданный первичный фрагмент другому узлу данных в том же уровне. Установите accept_data_loss на true.

POST _cluster/reroute
{
  "commands": [
    {
      "allocate_empty_primary": {
        "index": "my-index",
        "shard": 0,
        "node": "my-node",
        "accept_data_loss": "true"
      }
    }
  ]
}

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

Когда Elasticsearch отклоняет запрос, он останавливает операцию и возвращает ошибку с 429 кодом ответа. Отклоненные запросы обычно вызваны:

Чтобы проверить количество отклоненных задач для каждого пула потоков, используйте API пула потоков. Высокий коэффициент rejected к completed задачам, особенно в пулах потоков search и write, означает, что Elasticsearch регулярно отклоняет запросы.

GET /_cat/thread_pool?v=true&h=id,name,active,rejected,completed

Исправить высокую загрузку ЦП и памяти

Если Elasticsearch регулярно отклоняет запросы и другие задачи, в вашем кластере, вероятно, высокая загрузка ЦП или высокая нагрузка на память JVM. Советы см. в Высокой загрузке ЦП и Высокой нагрузке на память JVM.

Предотвращение ошибок разрыва цепи

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

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

Проверьте состояние пула потоков

Исчерпанный пул потоков может привести к отклоненным запросам.

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

GET /_cat/thread_pool?v&s=t,n&h=type,name,node_name,active,queue,rejected,completed

Проверьте горячие потоки на каждом узле

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

GET /_nodes/hot_threads

Ищите длительные задачи

Длительные задачи также могут привести к задержке. Вы можете использовать API управления задачами, чтобы получить информацию о выполняемых задачах. Проверьте running_time_in_nanos, чтобы определить задачи, которые занимают слишком много времени для завершения.

GET /_tasks?filter_path=nodes.*.tasks

Увеличьте доступные ресурсы

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

В некоторых случаях увеличение размера пула потоков может помочь. Например, пул потоков force_merge по умолчанию имеет один поток. Увеличение размера до 2 может помочь уменьшить задержку запросов на слияние.

Отменить зависшие задачи

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