Error watching consul catalog services

I am using Consul as my register center, now when the client spring boot application(spring-cloud-starter-consul-discovery version 2.2.7.RELEASE) start up, will show one error like this: [13:13:54:...

I am using Consul as my register center, now when the client spring boot application(spring-cloud-starter-consul-discovery version 2.2.7.RELEASE) start up, will show one error like this:

[13:13:54:269] [ERROR] - org.springframework.cloud.consul.discovery.ConsulCatalogWatch.catalogServicesWatch(ConsulCatalogWatch.java:148) - Error watching Consul CatalogServices
com.ecwid.consul.v1.OperationException: OperationException(statusCode=500, statusMessage='Internal Server Error', statusContent='rpc error making call: No cluster leader')
at com.ecwid.consul.v1.catalog.CatalogConsulClient.getCatalogServices(CatalogConsulClient.java:151) ~[consul-api-1.4.5.jar!/:?]
at com.ecwid.consul.v1.ConsulClient.getCatalogServices(ConsulClient.java:400) ~[consul-api-1.4.5.jar!/:?]
at org.springframework.cloud.consul.discovery.ConsulCatalogWatch.catalogServicesWatch(ConsulCatalogWatch.java:135) [spring-cloud-consul-discovery-2.2.7.RELEASE.jar!/:2.2.7.RELEASE]
at org.springframework.cloud.consul.discovery.ConsulCatalogWatch$$Lambda$1076/0x00000000fa715fb0.run(Unknown Source) [spring-cloud-consul-discovery-2.2.7.RELEASE.jar!/:2.2.7.RELEASE]
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54) [spring-context-5.2.14.RELEASE.jar!/:5.2.14.RELEASE]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:836) [?:?]

I check the consul register center in kubernetes cluster with 3 node, all node running fine. it tell me no cluster leader but the application still running fine. why shows this error? is it possible to fix it? I searching from internet seems no one talk about the real reason. BTW, this is my consul config:

# registry center
spring.cloud.consul.host=consul-1630121482-headless.reddwarf-pro.svc.cluster.local
spring.cloud.consule.port=8500
spring.cloud.consul.enabled=true
spring.cloud.consul.discovery.heartbeat.ttl-unit=s
spring.cloud.consul.discovery.heartbeat.ttl-value=30
spring.cloud.consul.discovery.health-check-interval=15s
spring.cloud.consul.discovery.instance-id= ${spring.application.name}:${vcap.application.instance_id:${spring.application.instance_id:${random.value}}}
spring.cloud.consul.discovery.prefer-ip-address= true
spring.cloud.consul.discovery.deregister=true
# service check failed, delete service
spring.cloud.consul.discovery.health-check-critical-timeout=30s
spring.cloud.consul.discovery.heartbeat.enabled=true

Источник

Обновлено Обновлено: 24.12.2022
Опубликовано Опубликовано: 10.09.2021

Установленный агент Consul позволяет обмениваться информацией с кластером, отправляя состояние работы сервисов, которые запущены на узле. Мы рассмотрим процесс установки агента на компьютер под управлением Linux на базе Deb (Ubuntu, Debian) или RPM (Rocky Linux, CentOS). Также мы приведем примеры регистрации и настройки проверки сервисов.

Предварительная настройка ноды
Инсталляция агента
Настройка и запуск клиентской части
ACL авторизация
Описание процесса регистрации сервиса
Примеры регистрации и проверок
    Включение возможности делать проверку
    HTTP-запросы
    Java (такие же http с другим методом проверки)
    KeyDB
    Без агента (на примере Postgresql)
    Описание нескольких проверок
Вывод ноды из кластера и удаление регистрации
Возможные проблемы и их решение

Подготовка системы

Предварительно, необходимо настроить брандмауэр. Открываем порты 8300,8301,8302,8500. В зависимости от системы управления netfilter, команды будут отличаться.

а) iptables (как правило для систем на базе deb):

iptables -I INPUT -p tcp —match multiport —dports 8300,8301,8302,8500 -j ACCEPT

iptables -I INPUT -p udp —match multiport —dports 8301,8302 -j ACCEPT

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

б) firewalld (чаще для RPM-based):

firewall-cmd —permanent —add-port={8300,8500}/tcp

firewall-cmd —permanent —add-port={8301,8302}/{udp,tcp}

firewall-cmd —reload

Установка агента

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

Для начала, установим дополнительные пакеты:

  • wget — утилита для загрузки файлов.
  • unzip — пакет для распаковки архивов zip.

Для этого, как раз, используются разные команды (в зависимости от операционной системы).

а) Для Deb:

apt install wget unzip

б) Для RPM:

yum install wget unzip

Теперь можно приступать к установке консула.

На странице со списком релизов необходимо посмотреть на все версии и выбрать необходимую. Также мы можем посмотреть версию consul на сервере:

consul -v

… и установить такую же.

Так или иначе, создаем переменную с номером версии:

export VER=»1.10.2″

И скачиваем архив с бинарным файлом:

wget https://releases.hashicorp.com/consul/${VER}/consul_${VER}_linux_amd64.zip

Распаковываем его в каталог /usr/bin:

unzip consul_${VER}_linux_amd64.zip -d /usr/bin

Проверяем, что команды консул выполняются:

consul -v

Мы должны увидеть версию программы:

Consul v1.10.2
…

Агент установлен.

Настройка и запуск агента

Настроим запуск агента в качестве сервиса. Для этого мы создадим юнит в systemd.

Создаем учетную запись, от которой будет работать агент:

useradd -r -c ‘Consul Agent’ consul

* в данном примере мы создадим системную (-r) учетную запись consul. Для удобства восприятия мы также добавим комментарий (-c).

Создаем каталоги для приложения консул:

mkdir -p /var/lib/consul /etc/consul.d

И выставим на них соответствующие права:

chown consul:consul /var/lib/consul /etc/consul.d

chmod 775 /var/lib/consul /etc/consul.d

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

Создаем конфигурационный файл:

vi /etc/consul.d/config.json

{
  «server»: false,
  «datacenter»: «dc1»,
  «node_name»: «agent01»,
  «data_dir»: «/var/lib/consul»,
  «bind_addr»: «192.168.0.100»,
  «client_addr»: «127.0.0.1»,
  «retry_join»: [«192.168.0.15», «192.168.0.20», «192.168.0.25»],
  «encrypt»: «zpjf5a4reDbJFpT6FeaF0LGxD0zBRPSRbIoUkLBt0ps=»,
  «log_level»: «warn»,
  «enable_syslog»: true,
  «telemetry»: {
    «disable_compat_1.9»: true
  }
}

* где:

  • server — указывает на использование серверного режима. При значении false используется режим клиента.
  • datacenter — датацентр, к которому будет присоединяться участник кластера. dc1 — датацентр по умолчанию.
  • node_name — имя, которым будет представлен узел в кластере.
  • data_dir — каталог на компьютере, который будет использоваться консулом для хранения своей информации.
  • bind_addr — IP-адрес, на котором будет слушать сервис.
  • client_addr — адрес, к которому будут привязаны клиентские интерфейсы. На практике, были проблемы при указании нескольких адресов. Проблема не наблюдается при использовании 127.0.0.1 для client_addr и внешнего сетевого адреса для bind_addr.
  • retry_join — список серверов консула, к которым должен присоединиться агент.
  • encrypt — ключ, который был сформирован для серверов консул и используется в качестве значения параметра encrypt (его можно посмотреть в конфигурационном файле на сервере consul).
  • log_level — уровень логирования. Возможны варианты trace, debug, info, warn, err. По умолчанию используется info.
  • enable_syslog — вести ли системный лог.
  • disable_compat_1.9 — запрещает все метрики, которые объявлены устаревшими, начиная с версии 1.9.

Проверяем корректность настройки:

consul validate /etc/consul.d/

Мы должны увидеть:

Configuration is valid!

Продолжаем. Создаем юнит в systemd:

vi /etc/systemd/system/consul.service

[Unit]
Description=Consul client agent
Requires=network-online.target
After=network-online.target

[Service]
User=consul
Group=consul
PIDFile=/var/run/consul/consul.pid
RuntimeDirectory=consul
ExecStart=/usr/bin/consul agent
    -config-dir=/etc/consul.d 
    -pid-file=/var/run/consul/consul.pid
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Перечитываем конфигурацию systemd:

systemctl daemon-reload

Разрешаем автозапуск сервиса, стартуем его и проверяем статус:

systemctl enable consul

systemctl start consul

systemctl status consul

На любом из узлов кластера выполним:

consul members

Среди членов кластера мы должны увидеть свой компьютер, например:

…
agent01                 192.168.0.100:8301  alive   client  1.10.2  2         dc1  <default>

С агентом завершили.

Использование ACL

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

На сервере переходим в каталог с конфигурациями консула и создаем файл с политикой:

cd /etc/consul.d

vi agent-policy.txt

node_prefix «» {
  policy = «write»
}
node «» {
  policy = «write»
}
service_prefix «» {
  policy = «write»
}
service «» {
  policy = «write»
}

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

Создаем политику agent на основе файла agent-policy.txt:

consul acl policy create -name «agent» -rules @agent-policy.txt

И после, создаем токен на основе политики agent:

consul acl token create -description «Token for Agent» -policy-name agent

Мы получим что-то на подобие:

AccessorID:       ddcf169e-237b-836c-47cf-537c12a3818f
SecretID:         37570fdb-798c-24e5-c8c3-612e86031345
Description:      Token for Agent
Local:            false
Create Time:      2021-09-09 16:36:57.216491588 +0300 MSK
Policies:
   b3f3a892-c792-726c-8136-9744fd7e0f7b — agent

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

Переходим на клиентскую ноду и открываем наш конфигурационный файл:

vi /etc/consul.d/config.json

Допишем:

  …
  «acl»: {
    «enabled»: true,
    «tokens»: {
      «default»: «<token (SecretID)>»
    }
  }
  …

<token> — это сформированный на сервере токен.

Перезагружаем консул на агенте:

systemctl restart consul

Регистрация сервисов

Рассмотрим общий принцип регистрации сервиса в консуле.

Для каждого сервиса можно создавать свой конфигурационный файл (или писать все в одном). Пошагово, необходимо:

  1. Добавить настройку в консул.
  2. Проверить конфигурацию и перезапустить сервис consul.
  3. Проверить регистрацию.
  4. Настроить проверку состояния.

 Синтаксис для конфигурации при регистрации сервиса следующий:

{
  «service»: {
    «name»: «<имя сервиса>»,
    «tags»: [
      «<теги>»
    ],
    «port»: <порт>
  }
}

Чтобы настройка применилась, перезагружаем консул.

Проверить, что сервис зарегистрировался можно в веб-панели. Также мы можем опросить сервис в DNS:

nslookup -port=8600 <тег>.<имя сервиса>.service.<датацентр>.<домен> <IP-адрес сервера консул>

или:

dig @<IP-адрес сервера консул> -p 8600 <тег>.<имя сервиса>.service.<датацентр>.<домен>

* в боевой среде стоит настроить перенаправление запросов для домена консула (по умолчанию, consul) на серверы консула. Также для корректной работы многих приложений необходимо сделать так, чтобы консул отвечал на DNS-запросы по порту 53 — для этого можно использовать dnsmasq.

Более конкретно, мы рассмотрим настройки в примерах.

Для проверки состояния нашего сервиса используется конфигурация следующего вида:

{
  «service»: {
    …
    «check»: {
      «args»: [
        «<аргумент>»,
        «<аргумент>»
      ],
      «interval»: «<время опроса>»
    }
  }
}

* это всего лишь пример. Конфигурация для выполнения проверок может использовать разные подходы. Подробнее, можно почитать в инструкции Consul. Health-check на сайте influunt.ru или Checks на официальном сайте консула.

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

Но чтобы это работало, в конфигурационном файле консула нужно добавить две строки:

  …
  «enable_local_script_checks»: true,
  «enable_script_checks»: true
  …

Перейдем к конкретике.

Примеры регистрации сервисов

По мере необходимости, я буду добавлять новые примеры.

0. Включение возможности делать проверку

Предварительно, разрешаем выполнение проверок. Для этого открываем наш конфигурационный файл консула:

vi /etc/consul.d/config.json

Добавим в него:

  …,
  «enable_local_script_checks»: true,
  «enable_script_checks»: true

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

Проверяем конфигурационный файл и перезапускаем консул:

consul validate /etc/consul.d/

systemctl restart consul

1. HTTP (веб)

Создаем конфигурацию:

vi /etc/consul.d/web.json

{
  «service»: {
    «name»: «web»,
    «tags»: [
      «front»
    ],
    «port»: 80,
    «check»: {
      «args»: [
        «curl»,
        «localhost»
      ],
      «interval»: «10s»
    }
  }
}

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Если мы увидим:

Configuration is valid!

… то с конфигурационным файлом все хорошо — можно продолжать.

Применяем настройки:

systemctl restart consul

В панели управления должен появиться наш сервис:

В веб-панели консула появился новый сервис

Также dns-запрос:

nslookup -port=8600 web.service.dc1.consul 192.168.0.15

или:

nslookup -port=8600 front.web.service.dc1.consul 192.168.0.15

… должен вернуть IP-адрес нашего сервера с агентом, например:

Non-authoritative answer:
Name:    web.service.dc1.consul
Address: 192.168.0.100

2. Java (http)

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

Создаем конфигурацию:

vi /etc/consul.d/java.json

{
  «service»: {
    «name»: «java»,
    «tags»: [
      «back»
    ],
    «port»: 8080,
    «check»: {
      «http»: «https://localhost:8080»,
      «tls_skip_verify»: false,
      «method»: «GET»,
      «interval»: «10s»,
      «timeout»: «2s»
    }
  }
}

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Применяем настройки:

systemctl restart consul

3. KeyDB (Redis)

KeyDB и Redis являются довольно популярными базами резидентского типа. Рассмотрим на примере первой процесс регистрации сервиса в Consul и проверки состояния, которое мы будем проверять с помощью скрипта.

Создаем конфигурацию:

vi /etc/consul.d/keydb.json

{
  «service»: {
    «name»: «keydb»,
    «tags»: [
      «db»
    ],
    «port»: 6379,
    «check»: {
      «args»: [ «/scripts/keydb_check.sh» ],
      «interval»: «10s»,
      «timeout»: «1s»
    }
  }
}

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Создаем скрипт для проверки состояния базы:

mkdir /scripts

vi /scripts/keydb_check.sh

#!/bin/bash
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

ping_check=$(keydb-cli ping)

if [ «$ping_check» = «PONG» ]
then
    exit 0
else
    exit 2
fi

exit 2

Разрешим его запуск на исполнение:

chmod +x /scripts/keydb_check.sh

Применяем настройки:

systemctl restart consul

4. Postgresql (без агента)

В данном примере мы рассмотрим пример регистрации сервиса без агента с указанием его адреса. В нашем случае это сервис Postgresql.

Создаем конфигурацию:

vi /etc/consul.d/postgresql.json

{
  «service»: {
    «name»: «db»,
    «tags»: [
      «master»
    ],
    «port»: 5432,
    «address»: «db.dmosk.local»
  }
}

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

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Применяем настройки:

systemctl restart consul

5. Несколько проверок

Мы можем перечислить несколько проверок. Каждая настройка описывается в фигурных скобках и это все оборачивается в квадратные скобки. Ключевое слово check меняем на checks.

Проверим работу веб-сервера как в части запущенной службы, так и возможности получения ответа по порту 80:

vi /etc/consul.d/web_service.json

{
  «service»: {
    «name»: «web»,
    «tags»: [
      «active»
    ],
    «port»: 80,
    «checks»: [{
      «http»: «http://localhost:80»,
      «interval»: «10s»,
      «method»: «GET»,
      «timeout»: «5s»,
      «deregister_critical_service_after»: «10s»
    },
    {
      «id»: «nginx»,
      «name»: «nginx service»,
      «args»: [«systemctl», «is-active», «nginx.service»],
      «interval»: «10s»,
      «timeout»:»1s»
    }]
  }
}

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

Вывод из эксплуатации членов кластера

Рассмотрим процесс удаление сервисов и нод кластера.

Снятие с регистрации сервисов

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

consul catalog services

Удаляем сервис:

consul services deregister -id=’web’

* где web — имя нашего сервиса, который необходимо снять с регистрации.

Удаление нод

На агенте вводим:

consul leave

Если нам нужно форсированно удалить ноду, то с любого участника, где можно управлять кластером, вводим:

consul force-leave agent01

Возможные ошибки

При настройке агента мы можем столкнуться с различными проблемами. Для их решения нам может помочь команда:

consul monitor

Также рассмотрим те, с которыми столкнулся я.

No installed keys could decryp

Ошибка возникаем при попытке подключить узел к кластеру. В итоге мы не обнаруживаем его среди участников (когда смотрим командой consul members). При этом мы видим в логах ошибку

… No installed keys could decryp

Причина: мы указали неверное значение для параметра encrypt.

Решение: состоит из двух шагов — проверки значения encrypt и удаление временного файла, где хранится его значение.

Для начала смотрим на сервере конфигурационный файл и находим в нем значение для опции encrypt. Точно такое же значение должно быть и на клиенте.

Однако, этого недостаточно, так как после первого запуска был создан файл local.keyring, в котором хранится неправильное значение. Просто удаляем его:

rm -f /var/lib/consul/serf/local.keyring

* где /var/lib/consul — путь, который мы указали в конфигурационно файле агента.

Перезагружаем консул на агенте:

systemctl restart consul

Coordinate update blocked by ACLs

Ошибка появляется при подключении агента к кластеру.

Причина: на сервере включен ACL и требуется дополнительная аутентификация.

Решение: на клиенте включаем ACL, а на сервере создаем токен. Подробнее процедура описана выше.

Источник

When filing a bug, please include the following headings if possible. Any example text in this template can be deleted.

Overview of the Issue

Dead server not removed from consul manager’s servers list when dead server’s IP address alive as client. New server was added, killed and force left (consul force-leave ). The same IP address was assigned to a new client and we see consul manager is rebalancing to 4 servers even we have only 3 server even after 24h.

Reproduction Steps

Steps to reproduce this issue, eg:

Server log before adding a server:

2019/04/09 18:50:58 [DEBUG] manager: Rebalanced 1 servers, next active server is econ-52485095260256623-c-gwo1.us-west1 (Addr: tcp/10.132.2.48:8300) (DC: us-west1)
2019/04/09 18:51:03 [DEBUG] manager: Rebalanced 3 servers, next active server is econ-0d5059ea0ad72e4f2-b-ea.us-east-1 (Addr: tcp/10.16.37.45:8300) (DC: us-east-1)
2019/04/09 18:51:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301

Server Debug logs after adding new server node (ezk-0760588ca5d7c54e6-a-wo) and killing the consul process ezk-0760588ca5d7c54e6-a-wo:

2019/04/09 18:50:18 [DEBUG] memberlist: Stream connection from=10.16.37.45:44530
2019/04/09 18:50:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.37.45:8302
2019/04/09 18:50:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.486555ms) from=127.0.0.1:58348
2019/04/09 18:50:30 [DEBUG] http: Request GET /v1/catalog/services (1.323442ms) from=127.0.0.1:58350
2019/04/09 18:50:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.492054ms) from=127.0.0.1:58352
2019/04/09 18:50:30 [DEBUG] http: Request GET /v1/agent/members (93.618µs) from=127.0.0.1:58354
2019/04/09 18:50:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:50:35 [DEBUG] memberlist: Stream connection from=10.16.3.52:39958
2019/04/09 18:50:46 [DEBUG] memberlist: Stream connection from=10.16.3.238:39546
2019/04/09 18:50:58 [DEBUG] manager: Rebalanced 1 servers, next active server is econ-52485095260256623-c-gwo1.us-west1 (Addr: tcp/10.132.2.48:8300) (DC: us-west1)
2019/04/09 18:51:03 [DEBUG] manager: Rebalanced 3 servers, next active server is econ-0d5059ea0ad72e4f2-b-ea.us-east-1 (Addr: tcp/10.16.37.45:8300) (DC: us-east-1)
2019/04/09 18:51:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:51:18 [DEBUG] memberlist: Stream connection from=10.16.37.45:44600
2019/04/09 18:51:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.33.185:8302
2019/04/09 18:51:26 [DEBUG] manager: Rebalanced 3 servers, next active server is econ-00dfa4c5521dace34-a-wo.us-west-2 (Addr: tcp/10.16.3.52:8300) (DC: us-west-2)
2019/04/09 18:51:29 [DEBUG] memberlist: Stream connection from=10.16.3.52:34084
2019/04/09 18:51:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.41693ms) from=127.0.0.1:58426
2019/04/09 18:51:30 [DEBUG] http: Request GET /v1/catalog/services (1.294127ms) from=127.0.0.1:58428
2019/04/09 18:51:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.281487ms) from=127.0.0.1:58430
2019/04/09 18:51:30 [DEBUG] http: Request GET /v1/agent/members (100.231µs) from=127.0.0.1:58432
2019/04/09 18:51:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8301
2019/04/09 18:51:58 [DEBUG] agent: Skipping remote check "serfHealth" since it is managed automatically
2019/04/09 18:51:58 [DEBUG] agent: Node info in sync
2019/04/09 18:52:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:52:05 [DEBUG] memberlist: Stream connection from=10.16.3.52:40032
2019/04/09 18:52:17 [INFO] serf: EventMemberJoin: ezk-0760588ca5d7c54e6-a-wo 10.16.1.81
2019/04/09 18:52:17 [INFO] consul: Adding LAN server ezk-0760588ca5d7c54e6-a-wo (Addr: tcp/10.16.1.81:8300) (DC: us-west-2)
2019/04/09 18:52:17 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.1.81:8302
2019/04/09 18:52:17 [INFO] serf: EventMemberJoin: ezk-0760588ca5d7c54e6-a-wo.us-west-2 10.16.1.81
2019/04/09 18:52:17 [DEBUG] consul: Successfully performed flood-join for "ezk-0760588ca5d7c54e6-a-wo" at 10.16.1.81:8302
2019/04/09 18:52:17 [INFO] consul: Handled member-join event for server "ezk-0760588ca5d7c54e6-a-wo.us-west-2" in area "wan"
2019/04/09 18:52:17 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:52:17 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:52:17 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:52:17 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:52:17 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-03b2d0d795a41eb0a-c-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-00dfa4c5521dace34-a-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-00dfa4c5521dace34-a-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-03b2d0d795a41eb0a-c-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-03b2d0d795a41eb0a-c-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-00dfa4c5521dace34-a-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-00dfa4c5521dace34-a-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-03b2d0d795a41eb0a-c-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-03b2d0d795a41eb0a-c-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-00dfa4c5521dace34-a-wo.us-west-2
2019/04/09 18:52:18 [DEBUG] serf: messageJoinType: econ-00dfa4c5521dace34-a-wo.us-west-2
2019/04/09 18:52:19 [DEBUG] memberlist: Stream connection from=10.16.37.45:44672
2019/04/09 18:52:19 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo.us-west-2
2019/04/09 18:52:19 [DEBUG] serf: messageJoinType: ezk-0760588ca5d7c54e6-a-wo.us-west-2
2019/04/09 18:52:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.33.185:8302
2019/04/09 18:52:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.396631ms) from=127.0.0.1:58498
2019/04/09 18:52:30 [DEBUG] http: Request GET /v1/catalog/services (1.349508ms) from=127.0.0.1:58500
2019/04/09 18:52:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.27465ms) from=127.0.0.1:58502
2019/04/09 18:52:30 [DEBUG] http: Request GET /v1/agent/members (98.878µs) from=127.0.0.1:58504
2019/04/09 18:52:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.1.81:8301
2019/04/09 18:52:35 [DEBUG] memberlist: Stream connection from=10.16.3.52:40112
2019/04/09 18:53:00 [DEBUG] manager: Rebalanced 1 servers, next active server is econ-52485095260256623-c-gwo1.us-west1 (Addr: tcp/10.132.2.48:8300) (DC: us-west1)
2019/04/09 18:53:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8301
2019/04/09 18:53:11 [DEBUG] manager: Rebalanced 3 servers, next active server is econ-0d5059ea0ad72e4f2-b-ea.us-east-1 (Addr: tcp/10.16.37.45:8300) (DC: us-east-1)
2019/04/09 18:53:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.37.45:8302
2019/04/09 18:53:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.599572ms) from=127.0.0.1:58572
2019/04/09 18:53:30 [DEBUG] http: Request GET /v1/catalog/services (1.711998ms) from=127.0.0.1:58574
2019/04/09 18:53:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.321894ms) from=127.0.0.1:58576
2019/04/09 18:53:30 [DEBUG] http: Request GET /v1/agent/members (96.184µs) from=127.0.0.1:58578
2019/04/09 18:53:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8301
2019/04/09 18:53:44 [DEBUG] memberlist: Stream connection from=10.16.1.81:60388
2019/04/09 18:53:56 [DEBUG] agent: Skipping remote check "serfHealth" since it is managed automatically
2019/04/09 18:53:56 [DEBUG] agent: Node info in sync
2019/04/09 18:54:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8301
2019/04/09 18:54:10 [DEBUG] manager: Rebalanced 4 servers, next active server is ezk-0760588ca5d7c54e6-a-wo.us-west-2 (Addr: tcp/10.16.1.81:8300) (DC: us-west-2)
2019/04/09 18:54:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.132.2.48:8302
2019/04/09 18:54:30 [DEBUG] memberlist: Failed ping: ezk-0760588ca5d7c54e6-a-wo (timeout reached)
2019/04/09 18:54:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.372775ms) from=127.0.0.1:58646
2019/04/09 18:54:30 [DEBUG] http: Request GET /v1/catalog/services (1.336123ms) from=127.0.0.1:58648
2019/04/09 18:54:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.281863ms) from=127.0.0.1:58650
2019/04/09 18:54:30 [DEBUG] http: Request GET /v1/agent/members (103.225µs) from=127.0.0.1:58652
2019/04/09 18:54:30 [INFO] memberlist: Suspect ezk-0760588ca5d7c54e6-a-wo has failed, no acks received
2019/04/09 18:54:33 [DEBUG] memberlist: Failed ping: ezk-0760588ca5d7c54e6-a-wo (timeout reached)
2019/04/09 18:54:33 [DEBUG] memberlist: Failed ping: ezk-0760588ca5d7c54e6-a-wo.us-west-2 (timeout reached)
2019/04/09 18:54:33 [INFO] memberlist: Suspect ezk-0760588ca5d7c54e6-a-wo has failed, no acks received
2019/04/09 18:54:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:54:34 [DEBUG] memberlist: Failed ping: ezk-0760588ca5d7c54e6-a-wo (timeout reached)
2019/04/09 18:54:34 [INFO] memberlist: Marking ezk-0760588ca5d7c54e6-a-wo as failed, suspect timeout reached (2 peer confirmations)
2019/04/09 18:54:34 [INFO] serf: EventMemberFailed: ezk-0760588ca5d7c54e6-a-wo 10.16.1.81
2019/04/09 18:54:34 [INFO] consul: Removing LAN server ezk-0760588ca5d7c54e6-a-wo (Addr: tcp/10.16.1.81:8300) (DC: us-west-2)
2019/04/09 18:54:35 [INFO] memberlist: Suspect ezk-0760588ca5d7c54e6-a-wo.us-west-2 has failed, no acks received
2019/04/09 18:54:36 [INFO] memberlist: Suspect ezk-0760588ca5d7c54e6-a-wo has failed, no acks received
2019/04/09 18:54:37 [DEBUG] memberlist: Stream connection from=10.16.33.185:51406
2019/04/09 18:54:40 [INFO] serf: attempting reconnect to ezk-0760588ca5d7c54e6-a-wo 10.16.1.81:8301
2019/04/09 18:54:40 [DEBUG] memberlist: Failed to join 10.16.1.81: dial tcp 10.16.1.81:8301: connect: connection refused
2019/04/09 18:54:43 [DEBUG] serf: messageLeaveType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:54:43 [INFO] serf: EventMemberLeave (forced): ezk-0760588ca5d7c54e6-a-wo 10.16.1.81
2019/04/09 18:54:43 [INFO] consul: Removing LAN server ezk-0760588ca5d7c54e6-a-wo (Addr: tcp/10.16.1.81:8300) (DC: us-west-2)
2019/04/09 18:54:43 [DEBUG] serf: messageLeaveType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:54:43 [DEBUG] serf: messageLeaveType: ezk-0760588ca5d7c54e6-a-wo
2019/04/09 18:55:03 [DEBUG] memberlist: Stream connection from=10.132.2.48:53596
2019/04/09 18:55:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:55:05 [INFO] serf: EventMemberFailed: ezk-0760588ca5d7c54e6-a-wo.us-west-2 10.16.1.81
2019/04/09 18:55:05 [DEBUG] manager: cycled away from server "ezk-0760588ca5d7c54e6-a-wo.us-west-2"
2019/04/09 18:55:05 [INFO] consul: Handled member-failed event for server "ezk-0760588ca5d7c54e6-a-wo.us-west-2" in area "wan"
2019/04/09 18:55:10 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 18:55:13 [DEBUG] manager: Rebalanced 3 servers, next active server is econ-0d5059ea0ad72e4f2-b-ea.us-east-1 (Addr: tcp/10.16.37.45:8300) (DC: us-east-1)
2019/04/09 18:55:16 [DEBUG] memberlist: Stream connection from=10.16.3.238:39850
2019/04/09 18:55:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.37.152:8302
2019/04/09 18:55:30 [DEBUG] memberlist: Stream connection from=10.16.3.52:34452
2019/04/09 18:55:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.465747ms) from=127.0.0.1:58726
2019/04/09 18:55:30 [DEBUG] http: Request GET /v1/catalog/services (1.313806ms) from=127.0.0.1:58728
2019/04/09 18:55:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.547925ms) from=127.0.0.1:58730
2019/04/09 18:55:30 [DEBUG] http: Request GET /v1/agent/members (103.065µs) from=127.0.0.1:58732
2019/04/09 18:55:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:55:34 [DEBUG] manager: Rebalanced 1 servers, next active server is econ-52485095260256623-c-gwo1.us-west1 (Addr: tcp/10.132.2.48:8300) (DC: us-west1)
2019/04/09 18:55:34 [DEBUG] agent: Skipping remote check "serfHealth" since it is managed automatically
2019/04/09 18:55:34 [DEBUG] agent: Node info in sync
2019/04/09 18:55:40 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 18:55:46 [DEBUG] memberlist: Stream connection from=10.16.3.238:39924
2019/04/09 18:56:03 [DEBUG] memberlist: Stream connection from=10.132.2.48:53634
2019/04/09 18:56:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8301
2019/04/09 18:56:10 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 18:56:15 [DEBUG] manager: Rebalanced 4 servers, next active server is econ-03b2d0d795a41eb0a-c-wo.us-west-2 (Addr: tcp/10.16.4.17:8300) (DC: us-west-2)
2019/04/09 18:56:16 [DEBUG] memberlist: Stream connection from=10.16.3.238:39934
2019/04/09 18:56:23 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8302
2019/04/09 18:56:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.352894ms) from=127.0.0.1:58804
2019/04/09 18:56:30 [DEBUG] http: Request GET /v1/catalog/services (1.34292ms) from=127.0.0.1:58806
2019/04/09 18:56:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.283166ms) from=127.0.0.1:58808
2019/04/09 18:56:30 [DEBUG] http: Request GET /v1/agent/members (124.328µs) from=127.0.0.1:58810
2019/04/09 18:56:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:56:40 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 18:57:03 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.238:8301
2019/04/09 18:57:05 [DEBUG] memberlist: Stream connection from=10.16.3.52:40476
2019/04/09 18:57:10 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 18:57:16 [DEBUG] memberlist: Stream connection from=10.16.3.238:40004
2019/04/09 18:57:17 [DEBUG] agent: Skipping remote check "serfHealth" since it is managed automatically
2019/04/09 18:57:17 [DEBUG] agent: Node info in sync
2019/04/09 18:57:24 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.37.45:8302
2019/04/09 18:57:30 [DEBUG] http: Request GET /v1/kv/?recurse (1.470712ms) from=127.0.0.1:58874
2019/04/09 18:57:30 [DEBUG] http: Request GET /v1/catalog/services (1.329342ms) from=127.0.0.1:58876
2019/04/09 18:57:30 [DEBUG] http: Request GET /v1/health/node/econ-03b2d0d795a41eb0a-c-wo (1.34464ms) from=127.0.0.1:58878
2019/04/09 18:57:30 [DEBUG] http: Request GET /v1/agent/members (118.731µs) from=127.0.0.1:58880
2019/04/09 18:57:33 [DEBUG] memberlist: Initiating push/pull sync with: 10.16.3.52:8301
2019/04/09 18:57:40 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 19:06:39 [DEBUG] agent: Skipping remote check "serfHealth" since it is managed automatically
2019/04/09 19:06:39 [DEBUG] agent: Node info in sync
2019/04/09 19:06:40 [DEBUG] serf: forgoing reconnect for random throttling
2019/04/09 19:06:54 [DEBUG] manager: pinging server "ezk-0760588ca5d7c54e6-a-wo.us-west-2 (Addr: tcp/10.16.1.81:8300) (DC: us-west-2)" failed: rpc error getting client: failed to get conn: dial tcp <nil>->10.16.1.81:8300: connect: connection refused
2019/04/09 19:06:54 [DEBUG] manager: Rebalanced 4 servers, next active server is econ-0aed93bbec0ebdbf5-b-wo.us-west-2 (Addr: tcp/10.16.3.238:8300) (DC: us-west-2)

From one of the server nodes called force-leave the dead node (ezk-0760588ca5d7c54e6-a-wo)

$consul members
Node                         Address           Status  Type    Build  Protocol  DC         Segment
econ-00dfa4c5521dace34-a-wo  10.16.3.52:8301   alive   server  1.2.3  2         us-west-2  <all>
econ-03b2d0d795a41eb0a-c-wo  10.16.4.17:8301   alive   server  1.2.3  2         us-west-2  <all>
econ-0aed93bbec0ebdbf5-b-wo  10.16.3.238:8301  alive   server  1.2.3  2         us-west-2  <all>
ezk-0760588ca5d7c54e6-a-wo   10.16.1.81:8301   left    server  1.2.3  2         us-west-2  <all>

ezk-0760588ca5d7c54e6-a-wo joins as client now:

 consul members
Node                         Address           Status  Type    Build  Protocol  DC         Segment
econ-00dfa4c5521dace34-a-wo  10.16.3.52:8301   alive   server  1.2.3  2         us-west-2  <all>
econ-03b2d0d795a41eb0a-c-wo  10.16.4.17:8301   alive   server  1.2.3  2         us-west-2  <all>
econ-0aed93bbec0ebdbf5-b-wo  10.16.3.238:8301  alive   server  1.2.3  2         us-west-2  <all>
ezk-0760588ca5d7c54e6-a-wo   10.16.1.81:8301   alive   client  1.2.3  2         us-west-2  <default> <---

Debug logs from server after force-leave dead server:

2019/04/09 19:45:42 [DEBUG] manager: pinging server "ezk-0760588ca5d7c54e6-a-wo.us-west-2 (Addr: tcp/10.16.1.81:8300) (DC: us-west-2)" failed: rpc error getting client: failed to get conn: dial tcp <nil>->10.16.1.81:8300: connect: connection refused
2019/04/09 19:45:42 [DEBUG] manager: Rebalanced 4 servers, next active server is econ-03b2d0d795a41eb0a-c-wo.us-west-2 (Addr: tcp/10.16.4.17:8300) (DC: us-west-2)

Autopilot config:

consul operator  autopilot get-config
CleanupDeadServers = true
LastContactThreshold = 24h0m0s
MaxTrailingLogs = 250
ServerStabilizationTime = 10s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeVersionTag = ""

Autopilot health:

{
  "Healthy": true,
  "FailureTolerance": 1,
  "Servers": [
    {
      "ID": "6eb86dd1-007c-4809-f9f5-c334de952aa8",
      "Name": "econ-00dfa4c5521dace34-a-wo",
      "Address": "10.16.3.52:8300",
      "SerfStatus": "alive",
      "Version": "1.2.3",
      "Leader": true,
      "LastContact": "0s",
      "LastTerm": 2,
      "LastIndex": 11721,
      "Healthy": true,
      "Voter": true,
      "StableSince": "2019-04-09T18:09:36Z"
    },
    {
      "ID": "d066550e-4c3e-ed14-7de1-5073e11bede4",
      "Name": "econ-03b2d0d795a41eb0a-c-wo",
      "Address": "10.16.4.17:8300",
      "SerfStatus": "alive",
      "Version": "1.2.3",
      "Leader": false,
      "LastContact": "43.064614ms",
      "LastTerm": 2,
      "LastIndex": 11721,
      "Healthy": true,
      "Voter": true,
      "StableSince": "2019-04-09T18:09:36Z"
    },
    {
      "ID": "3670437a-fe5e-8558-f198-0ad66a3a09a8",
      "Name": "econ-0aed93bbec0ebdbf5-b-wo",
      "Address": "10.16.3.238:8300",
      "SerfStatus": "alive",
      "Version": "1.2.3",
      "Leader": false,
      "LastContact": "10.867376ms",
      "LastTerm": 2,
      "LastIndex": 11721,
      "Healthy": true,
      "Voter": true,
      "StableSince": "2019-04-09T18:09:36Z"
    }
  ]
}

After 24hrs i still see consul trying to rebalance with 4 servers.

2019/04/10 18:07:33 [DEBUG] memberlist: Failed to join 10.16.1.81: dial tcp 10.16.1.81:8302: connect: connection refused
2019/04/10 18:07:35 [DEBUG] manager: Rebalanced 4 servers, next active server is econ-00dfa4c5521dace34-a-wo.us-west-2 (Addr: tcp/10.16.3.52:8300) (DC: us-west-2)

Consul info for both Client and Server

Server info:

consul info
agent:
	check_monitors = 0
	check_ttls = 0
	checks = 0
	services = 0
build:
	prerelease =
	revision = 48d287ef
	version = 1.2.3
consul:
	bootstrap = false
	known_datacenters = 3
	leader = false
	leader_addr = 10.16.3.52:8300
	server = true
raft:
	applied_index = 24715
	commit_index = 24715
	fsm_pending = 0
	last_contact = 4.435646ms
	last_log_index = 24715
	last_log_term = 2
	last_snapshot_index = 16387
	last_snapshot_term = 2
	latest_configuration = [{Suffrage:Voter ID:6eb86dd1-007c-4809-f9f5-c334de952aa8 Address:10.16.3.52:8300} {Suffrage:Voter ID:d066550e-4c3e-ed14-7de1-5073e11bede4 Address:10.16.4.17:8300} {Suffrage:Voter ID:3670437a-fe5e-8558-f198-0ad66a3a09a8 Address:10.16.3.238:8300}]
	latest_configuration_index = 362
	num_peers = 2
	protocol_version = 3
	protocol_version_max = 3
	protocol_version_min = 0
	snapshot_version_max = 1
	snapshot_version_min = 0
	state = Follower
	term = 2
runtime:
	arch = amd64
	cpu_count = 4
	goroutines = 85
	max_procs = 4
	os = linux
	version = go1.10.1
serf_lan:
	coordinate_resets = 0
	encrypted = true
	event_queue = 0
	event_time = 2
	failed = 0
	health_score = 0
	intent_queue = 0
	left = 0
	member_time = 12
	members = 4
	query_queue = 0
	query_time = 1
serf_wan:
	coordinate_resets = 0
	encrypted = true
	event_queue = 0
	event_time = 1
	failed = 1
	health_score = 0
	intent_queue = 0
	left = 0
	member_time = 2721
	members = 8
	query_queue = 0
	query_time = 1

Operating system and Environment details

Amazon Linux AMI release 2018.03

Log Fragments

Included in reproduction steps

Источник

Понравилась статья? Поделить с друзьями:
  • Error was not found on peds rpf
  • Error was caught in klstd
  • Error warning minimum system requirements not met
  • Error waiting for wifi mortal kombat mobile
  • Error waiting for process with pid zabbix