200 OK обычно показывает, что сервис ответил — а не то, что он работоспособен.
Типичная проверка работоспособности отправляет запрос к эндпоинту, видит ответ 200 и помечает сервис работоспособным. В современных приложениях этого недостаточно. Главная страница приложения может отвечать, пока соединение с базой данных медленное, слой кэша сломан, нижестоящая зависимость отключилась или процесс входа в систему перестал работать. Если балансировщик нагрузки не может видеть эту разницу, он продолжает направлять трафик к backend, которые отвечают, но не могут выполнять реальную работу.
Одношаговые проверки ещё более недостаточны для протоколов на основе сессий. Для FTP, LDAP, Oracle или пользовательских TCP-протоколов открытость порта не означает работоспособность сервиса. Реальная проверка работоспособности должна входить в систему, отправлять команду, получать ожидаемый ответ, при необходимости выходить и валидировать содержимое ответа. Иначе сервис выглядит доступным, пока реальные пользовательские операции завершаются ошибкой.
Валидация контента становится хрупкой, когда ограничивается только сопоставлением простого текста. API может всегда возвращать слово «OK», пока состояние зависимости, метрика задержки или бизнес-правило внутри JSON не выполняются. Когда проверка работоспособности не может запросить смысл ответа, деградации уровня приложения обнаруживаются поздно.
Правильный подход — решать вопросы проверки работоспособности с глубиной протокола, многошаговыми сценариями, запросами контента и настраиваемыми порогами rise/fall. Операции probe должны выполняться изолированно от основного потока трафика, чтобы медленные или зависшие проверки работоспособности не задерживали пользовательский трафик.
TR7 Активный мониторинг работоспособности реализует эту модель: мониторит 11 протоколов из единой конфигурации, выполняет многошаговые сценарии, валидирует смысл контента с помощью JSONata и держит в ротации только действительно работоспособные backend.
Наш подход
TR7 трансформирует проверку работоспособности из единственного протокольного контроля в многопротокольную, сценарийную и контентно-валидированную систему принятия решений.
Единая модель конфигурации охватывает 11 типов протоколов
Проверки TCP, TCPS, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS, SMTP, SMTPS и Oracle управляются из одного объекта проверки работоспособности. В зависимости от выбранного checkType отображаются только соответствующие поля, поэтому операторы не перегружены несоответствующими параметрами.
Многошаговые сценарии симулируют реальное поведение протокола
Для проверок TCP, UDP и Oracle упорядоченные потоки управления строятся с использованием шагов send, expect, regex и wait. Если какой-либо шаг не выполняется, probe помечается неудавшимся и состояние работоспособности backend обновляется соответственно.
JSONata валидирует тело ответа на семантическом уровне
Для проверок HTTP и HTTPS JSONata-запросы используются для чтения реального состояния внутри JSON-ответа. Backend не считается работоспособным просто за возврат 200 — поля, такие как статус зависимости, оценка, задержка или состояние бизнеса, также могут проверяться.
Пороги rise и fall фильтруют поведение флаппинга
Количество последовательных неудачных ответов, необходимых для пометки backend нездоровым, и количество последовательных успешных ответов, необходимых для его возврата, настраиваются независимо. Это предотвращает циклическое включение и исключение backend из ротации из-за временных сетевых колебаний.
Возможности
Активный мониторинг работоспособности делает разнообразные типы сервисов определяемыми, тестируемыми и управляемыми с операционными порогами — всё из одного редактора.
11 типов протоколов управляются с единого экрана проверки работоспособности
TR7 поддерживает проверки работоспособности TCP, TCPS, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS, SMTP, SMTPS и Oracle. Операторам не нужны отдельные инструменты для базы данных Oracle, директории LDAP, DNS-сервера, FTPS-репозитория или HTTP API. Соответствующие поля появляются в зависимости от выбранного типа протокола; несоответствующие поля скрыты. Эта модель делает проверку работоспособности гетерогенных backend стандартизированной и поддерживаемой.
История состояния — «почему этот сервер выпал во вторник в 03:40?»
Состояние здоровья не просто держится в памяти, а сохраняется: переходы состояний каждого сервера можно прочитать задним числом вместе с тем, что проба фактически получила в тот момент. Платформа, которая держит здоровье только в памяти, на этот вопрос ответить не может — свидетельство перезаписала следующая успешная проверка. И проверка TCP здесь настоящая: цепочка отправить/ожидать/повторить с полезной нагрузкой в hex и Base64, поэтому сервер, который отвечает на порту, но уже не говорит на протоколе, находится раньше, чем его найдут пользователи.
Язык сценариев TCP поддерживает проверки баннеров, команд и регулярных выражений
Для проверок TCP шаги sendText, expectText, expectRegex и wait могут выполняться последовательно. SMTP-баннеры, запросы возможностей IMAP, обмены Redis PING/PONG, ответы MQTT и пользовательские сообщения TCP-протокола — всё это тестируемо с этой моделью. Вместо простого открытия соединения выполняется реальный диалог протокола. Если какой-либо шаг не производит ожидаемый результат, backend помечается нездоровым.
UDP-сценарии работают с текстовыми, hex- и base64-полезными нагрузками
Для проверок UDP доступны шаги send, wait, expectText и expectRegex. Данные для отправки могут быть определены в формате text, hex или base64, обеспечивая гибкость для probe двоичных протоколов. Для DNS, NTP, RADIUS, SIP и аналогичных UDP-сервисов валидируется ожидаемый ответ протокола, а не просто открытость порта. Это делает UDP-сервисы активно и содержательно отслеживаемыми.
Проверки HTTP и HTTPS настраиваются как реальные клиентские запросы
Проверки работоспособности HTTP/HTTPS поддерживают метод, URI, пользовательский список заголовков, тело запроса и виртуальный хост. Эндпоинт API может проверяться с заголовком Authorization, телом JSON или пользовательским заголовком Host. Допустимые коды статусов не обязательно должны быть одним значением — 200, 204 или 304 все могут считаться работоспособными. Этот дизайн приближает проверку работоспособности к реальному использованию приложения.
JSONata-запросы валидируют фактический смысл ответа сервиса
Когда contentCheckMode установлен в jsonata, тело ответа оценивается как JSON и выполняется JSONata-выражение. Статус сервиса, результат зависимости, задержка базы данных или бизнес-метрика — всё это может проверяться в рамках одного выражения. Если выражение производит истинный результат, backend работоспособен; ложный результат помечает его неудавшимся. Ошибки JSONata логируются, чтобы неверное выражение или неожиданная структура ответа стали видимыми.
Базовая проверка контента обеспечивает быструю и простую валидацию маркеров
Для простых сценариев, не требующих JSONata, contentQuery выполняет поиск текста внутри тела ответа. Строки маркеров, такие как «Welcome», «UP» или «Service Ready», — или специфичный для приложения текст — могут быть быстро проверены. Этот режим предлагает решение с низкой сложностью для простых эндпоинтов работоспособности или устаревших приложений. Операторы выбирают между базовой проверкой и JSONata в зависимости от сценария.
Тесты LDAP и LDAPS bind измеряют работоспособность аутентификации
Проверки LDAP/LDAPS могут тестировать не только доступность порта, но и реальную операцию bind. Bind, выполненный с именем пользователя и паролем, валидирует службу каталогов на уровне аутентификации. Даже если порт открыт, backend может быть помечен нездоровым, если существует проблема с очередью bind, авторизацией или сервисом. Это обеспечивает критическую видимость особенно для AAM и корпоративных потоков доступа.
Проверки Oracle валидируют SQL-команды и ожидаемые количества строк
Проверки работоспособности Oracle поддерживают детали соединения, имя пользователя, пароль и шаги сценария. SQL выполняется через executeCmd и проверяется ожидаемый текст или минимальное количество строк. Вместо простого теста соединения могут запрашиваться реальный доступ к данным и бизнес-метрики. Этот подход делает вопрос доступности базы данных значимым с точки зрения приложения.
SMTP EHLO со STARTTLS — почтовый тракт проверяется так, как он реально используется
Проверка SMTP выполняет EHLO и согласует STARTTLS, поэтому почтовый релей, отвечающий на порту 25, но не проходящий переход на TLS, помечается как неработоспособный, а не как здоровый. Обычное TCP-подключение такой сбой не увидит — эта проверка увидит.
Операционная глубина
Проверки работоспособности работают совместно с интервалом, тайм-аутом, порогами, составлением сценариев, идентификацией экземпляра и специализированными системными контролями.
Конфигурация интервала и тайм-аута
testInterval настраивается от 0.5 до 3600 секунд; значение по умолчанию — 1 секунда. timeout настраивается от 0.01 до 3600 секунд. Агрессивный тайм-аут обеспечивает более быстрый failover, но может увеличить риск ложных срабатываний и должен настраиваться в соответствии с поведением сервиса.
Пороги rise и fall
requiredFailure по умолчанию равен 2; requiredSuccess по умолчанию равен 3. Эти пороги определяют, как быстро сервис исключается из ротации и насколько осторожно возвращается. Обе стороны порога управляются независимо для фильтрации временных колебаний.
Многоуровневое составление условий
Одна проверка работоспособности может комбинировать несколько атомарных проверок с использованием логики AND/OR. Это означает, что оцениваться могут не только результат одного probe, но и несколько зависимостей или протокольных шагов совместно. Сложное состояние работоспособности сервиса моделируется более реалистично.
Состояние экземпляра на уровне цели
Одна проверка работоспособности поддерживает отдельное состояние для каждого backend. Идентификатор экземпляра проверки работоспособности дифференцируется по проверке и цели. Это означает, что даже когда один профиль проверки применяется к нескольким целям, история работоспособности каждой цели отслеживается независимо.
Режим отрицательного ожидания
Настройка negate инвертирует нормальную логику успеха. Этот режим используется, когда определённый URL ожидается недоступным, определённый ответ ожидается не возвращаемым или путь сервиса ожидается недоступным. Ответ, который обычно считается успехом, рассматривается как сбой; неудавшийся ответ рассматривается как успех.
Системные специализированные проверки
Системные проверки работоспособности, такие как мониторы шлюзов и проверки соединения кластерных IP, могут генерироваться автоматически. Эти проверки используются для мониторинга не только backend приложений, но и соединения и доступности upstream вокруг TR7. Модель может быть расширена дополнительными типами проверок, такими как проверки датацентров на стороне GTM.
Когда применять
Измерение реальной работоспособности сервиса корзины e-commerce
Команда e-commerce может использовать HTTP-проверку с JSONata для верификации не только того, что сервис корзины возвращает 200, но и того, что метрики задержки базы данных и доступности находятся в пределах нормы. Медленный или деградировавший по зависимостям backend автоматически исключается из ротации.
Функциональные проверки на банковском кластере Oracle
Банковские команды могут использовать проверки Oracle, чтобы выйти за рамки открытия соединения и реально выполнять SQL-запросы. Если ожидаемое количество строк или результат запроса не выполняются, backend помечается нездоровым и трафик направляется к безопасным целям.
Валидация LDAPS bind на государственном портале
Государственные приложения могут проверять, что служба каталогов работает не только на уровне порта, но и через реальную операцию bind. Если порт открыт, но аутентификация не удаётся, система рассматривает это как проблему работоспособности.
Реальные запросы записей на телекоммуникационной ферме DNS
Телекоммуникационные команды могут выполнять реальные запросы записей для критического домена с помощью проверки DNS. Открытость порта DNS недостаточна — резолвер должен производить ожидаемый ответ, чтобы считаться работоспособным.
Часто задаваемые вопросы
Какие протоколы охватывает активный мониторинг работоспособности?
Как работает валидация контента JSONata?
Как проверки работоспособности влияют на основной поток трафика?
Что делают пороги rise и fall?
Тестирует ли LDAP-проверка только доступность порта?
Когда используется режим отрицательного ожидания?
Убедитесь, что ваши backend действительно работоспособны
Основывайте свои решения по трафику на надёжных данных о работоспособности по 11 протоколам, многошаговым сценариям и JSONata валидации контента. Давайте разберём живую настройку на ваших собственных сервисах.