Добавление монитора

Для добавления нового монитора в систему 5А выполните следующие шаги:

1. Откройте раздел Главная → Кластеры балансировки.

2. Перейдите в кластер, в котором находится конфигурация балансировки сервиса, для которого будет добавлен новый монитор.

3. Откройте раздел Мониторы.

4. Нажмите Добавить монитор.

5. Заполните форму Новый монитор. Все поля, отмеченные , являются обязательными для заполнения.

Пример заполнения формы "Новый монитор"

• Название — название для добавляемого монитора, которое будет использоваться в системе 5А.

• Протокол — протокол доступа к проверяемому серверу сервиса. Доступные варианты:

  • TACACS,
  • FTP,
  • SMTP,
  • LDAP,
  • DNS,
  • HTTP,
  • HTTPS,
  • XML,
  • TCP,
  • UDP,
  • ICMP,
  • PostgreSQL (pgsql),
  • MySQL,
  • MSSQL,
  • Oracle,
  • SIP.
  ⚠️

  Для корректной работы ICMP-мониторов агенту 5А в операционной системе должна быть выдана привилегия CAP_NET_RAW. Сделать это можно следующей командой:

  sudo setcap CAP_NET_RAW+eip /путь_к_агенту

• Версия протокола — версия для выбранного протокола доступа.

• Описание — краткое описание назначения и особенностей работы монитора.

• Перегрузка порта — опция определяет использование перегрузки порта:

  • если опция выключена, то используется порт сервера, к которому подключается монитор;
  • если опция включена, используется порт, указанный в поле Порт.

• Таймаут проверки, мс — время ожидания одной попытки проверки, от 1000 до 60000 мс. По умолчанию 5000. По истечении таймаута монитор считает сервер недоступным.

Секция Запрос:

• Для протоколов TACACS:

• Имя пользователя — логин учётной записи, от имени которой выполняется проверка аутентификации на сервере TACACS+.

• Пароль — пароль учётной записи, указанной в поле «Имя пользователя».

• Shared secret — общий секретный ключ, известный монитору и серверу TACACS+ заранее. Обязательный параметр.

• Тип аутентификации — метод проверки логина и пароля на сервере. Доступны два варианта:

  • PAP (по умолчанию) — учётные данные передаются за один обмен;
  • ASCII — интерактивный диалог: сервер поочерёдно запрашивает имя пользователя и пароль отдельными сообщениями.

• Для протоколов FTP:

• Имя пользователя — логин учётной записи, от имени которой выполняется проверка аутентификации на FTP-сервере. Если поле не заполнено, монитор считает сервер доступным уже после успешного подключения, без попытки входа.

• Пароль — пароль учётной записи, указанной в поле «Имя пользователя».

• Использовать FTPS (implicit TLS, порт 990) — опция определяет, что соединение с сервером устанавливается сразу через TLS (FTPS). Взаимоисключает параметр «Использовать FTPS (explicit TLS / AUTH TLS, порт 21)».

• Использовать FTPS (explicit TLS / AUTH TLS, порт 21) — опция определяет, что соединение начинается как обычное FTP (порт 21), а затем повышается до защищённого командой AUTH TLS. Взаимоисключает параметр «Использовать FTPS (implicit TLS, порт 990)».

• Для протоколов SMTP:

• EHLO-домен — доменное имя, передаваемое серверу в команде EHLO при установлении сессии. Если поле не заполнено, используется значение по умолчанию — healthcheck.

• Имя пользователя — логин учётной записи, от имени которой выполняется проверка аутентификации на SMTP-сервере. Если поле не заполнено, монитор считает сервер доступным уже после успешного установления сессии, без попытки аутентификации.

• Пароль — пароль учётной записи, указанной в поле «Имя пользователя».

• Использовать SMTPS (implicit TLS, порт 465) — опция определяет, что соединение с сервером устанавливается сразу через TLS (SMTPS). Взаимоисключает параметр «Использовать STARTTLS (explicit upgrade, порт 587/25)».

• Использовать STARTTLS (explicit upgrade, порт 587/25) — опция определяет, что соединение начинается как обычное SMTP (порт 25 или 587), а затем повышается до защищённого командой STARTTLS. Взаимоисключает параметр «Использовать SMTPS (implicit TLS, порт 465)».

• Для протоколов LDAP:

• Bind DN — DN учётной записи, от имени которой выполняется проверка аутентификации на LDAP-сервере. Если поле не заполнено, выполняется анонимный bind.

• Пароль — пароль учётной записи, указанной в поле «Bind DN».

• Использовать TLS — опция определяет, что соединение с LDAP-сервером устанавливается через TLS.

• Для протоколов PostgreSQL (pgsql):

  • Имя пользователя — логин учётной записи, от имени которой выполняется подключение к PostgreSQL-серверу. Поле обязательно для заполнения.
  • Пароль — пароль учётной записи, указанной в поле «Имя пользователя».
  • Имя БД — имя базы данных, к которой выполняется подключение. Поле обязательно для заполнения.
  • Использовать TLS — опция определяет, что соединение с PostgreSQL-сервером устанавливается через TLS-шифрование.

• Для протоколов MySQL:

  • Имя пользователя — логин учётной записи, от имени которой выполняется подключение к MySQL-серверу. Поле обязательно для заполнения.
  • Пароль — пароль учётной записи, указанной в поле «Имя пользователя».
  • Имя БД — имя базы данных, к которой выполняется подключение. Если поле не заполнено, монитор проверяет доступность сервера без подключения к конкретной БД.
  • Использовать TLS — опция определяет, что соединение с MySQL-сервером устанавливается через TLS-шифрование.

• Для протоколов MSSQL:

  • Имя пользователя — логин учётной записи, от имени которой выполняется подключение к Microsoft SQL Server. Поле обязательно для заполнения.
  • Пароль — пароль учётной записи, указанной в поле «Имя пользователя».
  • Имя БД — имя базы данных, к которой выполняется подключение. Если поле не заполнено, монитор проверяет доступность сервера без подключения к конкретной БД.
  • Использовать TLS — опция определяет, что соединение с MS SQL Server устанавливается через TLS-шифрование.

• Для протоколов Oracle:

  • Имя пользователя — логин учётной записи, от имени которой выполняется подключение к Oracle Database. Поле обязательно для заполнения.
  • Пароль — пароль учётной записи, указанной в поле «Имя пользователя».
  • Service name БД — SID или Service Name базы данных Oracle, к которой выполняется подключение. Поле обязательно для заполнения.
  • Использовать TLS — опция определяет, что соединение с Oracle Database устанавливается через TLS-шифрование.

• Для протоколов DNS:

  • Тип записи — тип DNS-записи.
  • Имя записи — доменное имя, к которому привязана DNS-запись.

• Для протоколов HTTP/HTTPS:

• Метод — вид HTTP-метода, используемого для взаимодействия с сервером сервиса для отправки запроса о его состоянии.

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

• Host (переопределение) — значение заголовка Host в запросе проверки. Пусто — Host берётся из адреса сервера сервиса (URL или IP). Явное значение приоритетнее заголовка Host из списка заголовков запроса. Применяется для проверки виртуальных хостов, когда за одним адресом сервера стоит несколько доменов.

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

• Тело запроса — тело запроса к серверу сервиса.

• Для протокола XML:

• Метод — HTTP-метод запроса. По умолчанию — POST.

• URI — эндпоинт веб-сервиса, к которому отправляется запрос. Обязательное поле.

• Использовать HTTPS — запрос выполняется по HTTPS. По умолчанию используется обычный HTTP. Сертификат сервера при этом не проверяется.

• SOAPAction — значение заголовка SOAPAction SOAP-запроса. Требуется для эндпоинтов, которым нужно явно указывать вызываемый метод. Значение из этого поля приоритетнее строки SOAPAction из списка заголовков запроса.

• Host (переопределение) и Заголовки запроса — ведут себя как для HTTP/HTTPS (см. выше). Для XML-мониторов заголовок Content-Type по умолчанию равен text/xml; charset=utf-8 и может быть переопределён в списке заголовков.

• Валидация XML/SOAP — при сохранении монитора тело запроса проверяется на корректность XML. Снимите отметку, если монитор отправляет не XML (например, JSON). На проверки ответа (XPath, регулярные выражения, полное совпадение) эта опция не влияет — они выполняются всегда.

• Тело запроса — тело, отправляемое серверу. При включённой валидации должно быть корректным XML.

• Для протоколов TCP и UDP:

• Тело запроса — данные, которые отправляются серверу при каждой проверке. Если поле пустое, серверу отправляется пустое сообщение.

• Для протоколов ICMP:

• Количество пакетов — количество сетевых пакетов, которые будут отправлены по протоколу ICMP для диагностики соединения с сервером.

• Для протокола SIP:

• Метод — метод SIP-запроса проверки: OPTIONS или REGISTER. По умолчанию — OPTIONS. REGISTER отправляется без заголовка Contact и без аутентификации: сервер не регистрирует монитор, а только отвечает кодом состояния.

• Транспорт — протокол доставки запроса: UDP или TCP. По умолчанию — UDP.

• Использовать TLS — запрос передаётся по защищённому соединению поверх транспорта TCP. Отображается только при выбранном TCP. Сертификат сервера не проверяется, имя сервера (SNI) берётся из хоста поля SIP URI; для IP-адреса SNI не передаётся.

• SIP URI — адрес вызова вида sip:example.com, не длиннее 255 символов, без пробелов. Задаёт домен в заголовках запроса; на адрес и порт назначения не влияет — запрос отправляется на сервер из группы. Если поле пустое, домен берётся из адреса проверяемого сервера. Схема sips: допустима только с включённым Использовать TLS.

• Пользователь в From — пользователь в заголовке From, при REGISTER он же попадает в To. Не длиннее 64 символов, без пробелов и символов @ < > ; :. По умолчанию — 5a-monitor.

• Заголовки запроса — работают как для HTTP/HTTPS (см. выше), поле Host (переопределение) для SIP не отображается. Монитор формирует заголовки Via, From, To, Call-ID, CSeq, Max-Forwards и Content-Length — переопределить их нельзя, запись не сохранится.

• Версия протокола для SIP отключена, Тело запроса не отображается: сообщение собирает монитор.

Секция Ожидаемый ответ:

• Для протоколов HTTP/HTTPS:

• Код — код состояния (HTTP-статус) ответа, который должен быть получен с сервера в качестве подтверждения его корректной работы.

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

• Полное совпадение — опция определяет способ проверки поля Тело ответа при анализе ответа сервера сервиса:

  • если опция выключена (по умолчанию), проверка выполняется по принципу частичного совпадения: монитор считает сервер доступным, если значение, указанное в поле Тело ответа, содержится в теле ответа сервера;
  • если опция включена, проверка выполняется по принципу полного совпадения: монитор считает сервер доступным только в случае точного совпадения тела ответа сервера со значением, указанным в поле Тело ответа.

• Для протоколов TCP и UDP:

• Тело ответа и Полное совпадение — работают как для HTTP/HTTPS (см. выше).

• Для протокола XML:

• Код — код состояния HTTP-ответа, при котором проверка считается успешной. Пусто — код не проверяется.

• Полное совпадение — способ проверки поля Тело ответа: если опция выключена, достаточно вхождения подстроки или совпадения по регулярному выражению; если включена — тело ответа должно полностью совпасть с указанным значением.

• Тело ответа — подстрока или регулярное выражение, которое должно присутствовать в теле ответа. Пусто — тело не проверяется.

• Ожидать SOAP Fault — если опция включена, проверка успешна только при наличии в ответе элемента Fault. Если опция выключена, наличие Fault в ответе трактуется как ошибка.

• Проверки по XPath — набор правил, применяемых к телу XML-ответа. Проверка проходит, только если выполнены все правила:

  • XPath-выражение — выражение, по которому выбираются узлы в теле ответа, например //status. Сопоставление имён элементов идёт по локальному имени, поэтому префиксы пространств имён (ns2: и подобные) можно не указывать.
  • Ожидаемое значение — ожидаемое содержимое узла. Если оставить пустым, для выполнения правила достаточно факта наличия узла.
  • Способ сравнения — способ сверки содержимого узла с ожидаемым значением: «Точное совпадение», «Содержит» или «Регулярное выражение».

Если тело ответа не является корректным XML, проверка завершается ошибкой только тогда, когда включена опция Ожидать SOAP Fault или задано хотя бы одно правило XPath. В остальных случаях некорректный XML в ответе к ошибке не приводит.

• Для протоколов DNS:

• Ожидаемый ответ — значение проверяемого параметра DNS-записи согласно её типу, которое должно быть получено в качестве подтверждения корректной работы сервера.

• Для протоколов ICMP:

• Потери пакетов, %, не более — процент допустимой потери ICMP-пакетов. Если процент потерь не превышает указанное значение, то соединение с сервером считается успешным.

• Среднее время отклика, мс, не более — среднее допустимое значение времени отклика от сервера в миллисекундах. Если среднее время отклика не превышает указанное значение, то соединение с сервером считается успешным.

• Для протоколов FTP:

• Ожидаемый код FTP — код ответа FTP-сервера на команду входа (например, 230), который должен быть получен в качестве подтверждения успешной аутентификации. Если поле не заполнено, используется значение по умолчанию — 230. Проверяется только в том случае, если указано имя пользователя.

• Для протоколов SMTP:

• Ожидаемый код SMTP AUTH PLAIN — код ответа SMTP-сервера на команду аутентификации (например, 235), который должен быть получен в качестве подтверждения её успешного прохождения. Если поле не заполнено, используется значение по умолчанию — 235. Проверяется только в том случае, если указано имя пользователя.

• Для протоколов LDAP:

• Ожидаемый код LDAP bind-операции — ожидаемый числовой код результата операции bind (например, 0 — success), который должен быть получен от сервера в качестве подтверждения корректной работы. Если поле не заполнено, используется значение по умолчанию — 0.

• Для протокола SIP:
• Допустимые коды ответа — коды, при которых сервер считается доступным. Укажите коды через запятую: 200, диапазон 200-299, класс 2xx или any. Допустимо не более 32 значений в диапазоне от 100 до 699. Если поле пустое, подходит любой SIP-ответ.

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

1. Нажмите Сохранить для добавления монитора в систему 5А.

Примеры настройки SIP-монитора

Монитор начинает проверять серверы после подключения к группе серверов — в секции Проверка здоровья, поле Подключенные мониторы. Проверка отправляется на адрес и порт сервера группы: SIP URI задаёт домен в заголовках запроса, но не адрес назначения.