Сеть

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

Вы можете настроить Elasticsearch на автоматическое определение своих адресов, используя следующие специальные значения. Используйте эти значения при настройке network.host, network.bind_host, network.publish_host и соответствующих параметров для HTTP- и транспортных интерфейсов.

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

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

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

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

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

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

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

Используйте следующие дополнительные параметры для конфигурации интерфейса удалённого кластера (модель на основе API-ключа) независимо от транспортного интерфейса. Вы также можете настроить оба интерфейса вместе, используя параметры сети.

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

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.http.HttpTracer": "TRACE"
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      "logger.org.elasticsearch.http.HttpTracer": 'TRACE'
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.http.HttpTracer": "TRACE",
  },
});
console.log(response);

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.http.HttpTracer" : "TRACE"
   }
}

resp = client.cluster.put_settings(
    persistent={
        "http.tracer.include": "*",
        "http.tracer.exclude": ""
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'http.tracer.include' => '*',
      'http.tracer.exclude' => ''
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "http.tracer.include": "*",
    "http.tracer.exclude": "",
  },
});
console.log(response);

PUT _cluster/settings
{
   "persistent" : {
      "http.tracer.include" : "*",
      "http.tracer.exclude" : ""
   }
}

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.http.HttpTracer": "TRACE",
        "logger.org.elasticsearch.http.HttpBodyTracer": "TRACE"
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      "logger.org.elasticsearch.http.HttpTracer": 'TRACE',
      "logger.org.elasticsearch.http.HttpBodyTracer": 'TRACE'
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.http.HttpTracer": "TRACE",
    "logger.org.elasticsearch.http.HttpBodyTracer": "TRACE",
  },
});
console.log(response);

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.http.HttpTracer" : "TRACE",
      "logger.org.elasticsearch.http.HttpBodyTracer" : "TRACE"
   }
}

[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 1]: H4sIAAAAAAAA/9...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 2]: 2oJ93QyYLWWhcD...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body (gzip compressed, base64-encoded, and split into 2 parts on preceding log lines)

cat httptrace.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.transport.TransportService.tracer": "TRACE"
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      "logger.org.elasticsearch.transport.TransportService.tracer": 'TRACE'
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.transport.TransportService.tracer": "TRACE",
  },
});
console.log(response);

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.transport.TransportService.tracer" : "TRACE"
   }
}

resp = client.cluster.put_settings(
    persistent={
        "transport.tracer.include": "*",
        "transport.tracer.exclude": "internal:coordination/fault_detection/*"
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'transport.tracer.include' => '*',
      'transport.tracer.exclude' => 'internal:coordination/fault_detection/*'
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "transport.tracer.include": "*",
    "transport.tracer.exclude": "internal:coordination/fault_detection/*",
  },
});
console.log(response);

PUT _cluster/settings
{
   "persistent" : {
      "transport.tracer.include" : "*",
      "transport.tracer.exclude" : "internal:coordination/fault_detection/*"
   }
}

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

Узлы Elasticsearch обмениваются данными через набор TCP-каналов, которые вместе образуют транспортное соединение. Клиенты Elasticsearch взаимодействуют с кластером через HTTP, который также использует один или несколько TCP-каналов. Каждый из этих TCP-каналов принадлежит ровно одному из transport_worker потоков в узле. Этот владеющий поток выбирается при открытии канала и остается неизменным на протяжении всего жизненного цикла канала.

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

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

Обычно transport_worker потоки не полностью обрабатывают получаемые ими сообщения. Вместо этого они выполняют небольшую предварительную обработку и затем перенаправляют (передают) сообщение в другой пул потоков для дальнейшей обработки. Например, сообщения bulk перенаправляются в write пул потоков, запросы поиска — в один из search пулов потоков, а запросы на статистику и другие задачи управления — в основном в management пул потоков. Однако в некоторых случаях обработка сообщения ожидается настолько быстрой, что Elasticsearch выполнит всю обработку в transport_worker потоке, а не тратит время на его перенаправление.

По умолчанию существует один transport_worker поток на процессор. В отличие от этого, иногда может быть десятки и тысячи TCP-каналов. Если данные поступают по TCP-каналу, и владеющий transport_worker поток занят, данные не обрабатываются, пока поток не закончит текущую работу. Аналогично, исходящие данные не отправляются по каналу, пока владеющий transport_worker поток свободен. Это означает, что каждый transport_worker поток должен часто быть в состоянии ожидания. Незанятый transport_worker поток может выглядеть примерно так в дампе стека:

"elasticsearch[instance-0000000004][transport_worker][T#1]" #32 daemon prio=5 os_prio=0 cpu=9645.94ms elapsed=501.63s tid=0x00007fb83b6307f0 nid=0x1c4 runnable  [0x00007fb7b8ffe000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPoll.wait(java.base@17.0.2/Native Method)
	at sun.nio.ch.EPollSelectorImpl.doSelect(java.base@17.0.2/EPollSelectorImpl.java:118)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@17.0.2/SelectorImpl.java:129)
	- locked <0x00000000c443c518> (a sun.nio.ch.Util$2)
	- locked <0x00000000c38f7700> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(java.base@17.0.2/SelectorImpl.java:146)
	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)

В API горячих потоков узлов незанятый transport_worker поток отображается следующим образом:

   0.0% [cpu=0.0%, idle=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
     10/10 snapshots sharing following 9 elements
       java.base@17.0.2/sun.nio.ch.EPoll.wait(Native Method)
       java.base@17.0.2/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:118)
       java.base@17.0.2/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:129)
       java.base@17.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:146)
       io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
       io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
       io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
       java.base@17.0.2/java.lang.Thread.run(Thread.java:833)

Обратите внимание, что transport_worker потоки всегда должны быть в состоянии RUNNABLE, даже при ожидании ввода, потому что они блокируются в методе native EPoll#wait. Время idle= показывает долю времени, которую поток потратил на ожидание ввода, а время cpu= показывает долю времени, потраченного потоком на обработку полученного ввода.

Если transport_worker поток не часто находится в состоянии ожидания, может образоваться очередь необработанных задач. Это может привести к задержкам при обработке сообщений по каналам, которыми он владеет. Сложно точно предсказать, какая работа будет задержана:

Если очередь станет слишком большой, некоторые сообщения могут задержаться на много секунд. Узел может даже провалить проверки работоспособности и быть удален из кластера. Иногда можно найти доказательства занятых transport_worker потоков с помощью API горячих потоков узлов. Однако этот API сам отправляет сетевые сообщения, поэтому он может работать неправильно, если transport_worker потоки слишком заняты. Наиболее надежно использовать jstack для получения дампов стека или Java Flight Recorder для получения профилирующего трассировки. Эти инструменты независимы от любой работы, выполняемой JVM.

Также возможно определить некоторые причины задержек из журналов сервера. Например, посмотрите следующие логгеры:

Если настроено, узел может открыть TCP-порт, когда узел находится в состоянии готовности. Узел считается готовым, когда он успешно присоединился к кластеру. В конфигурации с одним узлом узел считается готовым, когда он может принимать запросы.

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

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

Успешное подключение к порту готовности TCP сигнализирует о том, что узел Elasticsearch готов. При подключении клиента к порту готовности сервер просто закрывает сокетное соединение. Клиенту не отправляются данные. Если клиент не может подключиться к порту готовности, узел не готов.