Статус кластера: красный или жёлтый

Статус кластера «красный» или «жёлтый» указывает на то, что один или несколько фрагментов не назначены узлу.

Когда в вашем кластере статус «красный» или «жёлтый», он будет продолжать обрабатывать поисковые запросы и индексирование, где это возможно, но может отложить определённые управляющие и очистительные действия до тех пор, пока статус кластера не станет зелёным. Например, некоторые действия ILM требуют, чтобы индекс, над которым они выполняются, имел зелёный статус.

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

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

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

resp = client.cluster.health(
    filter_path="status,*_shards",
)
print(resp)

response = client.cluster.health(
  filter_path: 'status,*_shards'
)
puts response

const response = await client.cluster.health({
  filter_path: "status,*_shards",
});
console.log(response);

GET _cluster/health?filter_path=status,*_shards

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

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

Для просмотра неназначенных фрагментов используйте API cat shards.

resp = client.cat.shards(
    v=True,
    h="index,shard,prirep,state,node,unassigned.reason",
    s="state",
)
print(resp)

response = client.cat.shards(
  v: true,
  h: 'index,shard,prirep,state,node,unassigned.reason',
  s: 'state'
)
puts response

const response = await client.cat.shards({
  v: "true",
  h: "index,shard,prirep,state,node,unassigned.reason",
  s: "state",
});
console.log(response);

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

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

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

resp = client.cluster.allocation_explain(
    filter_path="index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*",
    index="my-index",
    shard=0,
    primary=False,
)
print(resp)

response = client.cluster.allocation_explain(
  filter_path: 'index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*',
  body: {
    index: 'my-index',
    shard: 0,
    primary: false
  }
)
puts response

const response = await client.cluster.allocationExplain({
  filter_path:
    "index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*",
  index: "my-index",
  shard: 0,
  primary: false,
});
console.log(response);

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

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

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

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

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

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

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

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

response = client.cluster.reroute(
  metric: 'none'
)
puts response

POST _cluster/reroute?metric=none

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

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

resp = client.indices.get_settings(
    index="my-index",
    flat_settings=True,
    include_defaults=True,
)
print(resp)

resp1 = client.cluster.get_settings(
    flat_settings=True,
    include_defaults=True,
)
print(resp1)

response = client.indices.get_settings(
  index: 'my-index',
  flat_settings: true,
  include_defaults: true
)
puts response

response = client.cluster.get_settings(
  flat_settings: true,
  include_defaults: true
)
puts response

const response = await client.indices.getSettings({
  index: "my-index",
  flat_settings: "true",
  include_defaults: "true",
});
console.log(response);

const response1 = await client.cluster.getSettings({
  flat_settings: "true",
  include_defaults: "true",
});
console.log(response1);

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

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

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

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

resp = client.indices.put_settings(
    settings={
        "index.number_of_replicas": 1
    },
)
print(resp)

response = client.indices.put_settings(
  body: {
    'index.number_of_replicas' => 1
  }
)
puts response

const response = await client.indices.putSettings({
  settings: {
    "index.number_of_replicas": 1,
  },
});
console.log(response);

PUT _settings
{
  "index.number_of_replicas": 1
}

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

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

resp = client.cat.allocation(
    v=True,
    h="node,shards,disk.*",
)
print(resp)

response = client.cat.allocation(
  v: true,
  h: 'node,shards,disk.*'
)
puts response

const response = await client.cat.allocation({
  v: "true",
  h: "node,shards,disk.*",
});
console.log(response);

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

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

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

resp = client.cluster.put_settings(
    persistent={
        "cluster.routing.allocation.enable": None
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'cluster.routing.allocation.enable' => nil
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "cluster.routing.allocation.enable": null,
  },
});
console.log(response);

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

Посмотрите это видео для пошагового руководства по устранению неполадок с сообщением "no allocations are allowed".

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

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

См. это видео для пошагового руководства по устранению неполадок no_valid_shard_copy.