Агент consul ведет наблюдение за системой и зарегистрированными сервисами. Периодические "Health-check" проверки выявляют проблемы на раннем этапе:

Consul разделяет Health-check проверки по зоне ответственности: системные или сервиса. В зависимости от зоны провал проверки приостанавливает регистрацию всей системы или отдельного сервиса до восстановления работоспособности.

Регистрация Health-check

Подход к проверке показателей системы или специфичных атрибутов сервиса может различаться. Проверить свободный объем ОЗУ можно с помощью обычного bash скрипта. Веб приложение требует использование протокола HTTP. Короткоживущие операции, такие как cron, должны сами оповещать о своем запуске.

Агент consul поддерживает 5 типов проверок:

1. Time to Live (TTL)
2. TCP
3. HTTP
4. Docker
5. Скрипт

Health-check записывается в формате JSON. В зависимости от типа формат может незначительно меняться. Параметры id,name указываются всегда.

Набор проверок может быть задан при регистрации сервиса

/etc/consul.d/redis.json

{
    "name": "redis",
    "tags": ["primary"],
    "address": "",
    "port": 8000,
    "enableTagOverride": false,
    "checks": [
      {
        "script": "/usr/local/bin/check_redis.py",
        "interval": "10s"
      }
    ]
}

или с помощью конфигурационного файла

/etc/consul.d/redis_check.json

{
  "check": {
    "id": "redis_check",
    "service_id": "redis",
    "script": "/usr/local/bin/check_redis.py",
    "interval": "10s"
  }
}

или с помощью REST_API

curl 
    -H 'Content-Type: application/json' 
    -X PUT -d 'check: {"id": "redis_check", "service_id": "redis", "script":"/usr/local/bin/check_redis.py", "interval": "10s"}' 
    http://consul.service.domain.ltd/v1/agent/check/register

Time to Live (TTL)

Сервис сообщает состояние агенту в заданном интервале. Превышение TTL переводит проверку в состояние failing.

Сценарий для проверки web-app приложения:

{
  "check": {
    "id": "web-app",
    "name": "Web App Status",
    "notes": "Web app does a curl internally every 10 seconds",
    "ttl": "30s"
  }
}

Оповещение состояния приложения производится по HTTP API:

• /v1/agent/check/pass/web-app
• /v1/agent/check/warn/web-app
• /v1/agent/check/fail/web-app

Дополнительное сообщение о статусе проверки передается через параметр ?note= в url запроса.

TCP

Агент пытается установить TCP соединение в заданном интервале. Проверка считается пройденной в случае принятия подключения сервером.

Сценарий для проверки TCP порта:

{
  "check": {
    "id": "ssh",
    "name": "SSH TCP on port 22",
    "tcp": "localhost:22",
    "interval": "10s",
    "timeout": "1s"
  }
}

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

HTTP

Агент выполняет GET запрос в заданном интервале. Состояние проверки зависит от кода возврата: любой 2хх код считается успешным, 429 (Слишком много запросов) - предупреждение, а все остальные - ошибка.

Сценарий для проверки HTTP подключения:

{
  "check": {
    "id": "api",
    "name": "HTTP API on port 5000",
    "http": "http://localhost:5000/health",
    "header": {"x-foo": ["bar", "baz"]},
    "interval": "10s",
    "timeout": "1s"
  }
}

По умолчанию сценарий использует GET запрос. Метод проверки можно изменить с помощью параметра method.

В тело запроса возможно включить дополнительные заголовки. Для этого используется параметр header и мап листов строк (map of lists of strings).

Docker

Проверка базируется на выполнении команды внутри docker контейнера. Проверка запускается с помощью docker exec API. Consul использует переменную $DOCKER_HOST при коммуникации с Docker API.

Сценарий для проверки контейнера:

{
"check": {
    "id": "mem-util",
    "name": "Memory utilization",
    "docker_container_id": "f972c95ebf0e",
    "shell": "/bin/bash",
    "script": "/usr/local/bin/check_mem.py",
    "interval": "10s"
  }
}

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

Скрипт

Проверка базируется на выполнении команды в командной строке. Статус проверки зависит от кода возврата: 0 - проверка пройдена, 1 - предупреждение, любой другой - провалена.

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

{
  "check": {
    "id": "mem-util",
    "name": "Memory utilization",
    "script": "/usr/local/bin/check_mem.py",
    "interval": "10s",
    "timeout": "1s"
  }
}

Ещё раз о главном

Health-check не мониторинг. Его нельзя сравнивать с prometheus, zabbix и прочими системами. Вывод таких проверок слишком скуден для анализа или оповещения ответственных за инфраструктуру людей.

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