Документация

gRPC-монитор вызывает на вашем сервере стандартный health-сервис — один унарный Check у grpc.health.v1.Health — и записывает, что пришло в ответ. SERVING значит «работает». NOT_SERVING значит, что сервер жив и сам говорит, что обслуживать запросы не готов, а это совсем другой сигнал, чем мёртвый порт.

Для чего подходит

Для чего не подходит

Монитор делает ровно один вызов, и это всегда health-вызов. Это не gRPC-клиент для ваших собственных методов:

Что делает проверка

1. Собирает цель из адреса, подставляя порт 50051, если вы его не указали.
2. Открывает канал — с TLS, если вы его включили, иначе обычный HTTP/2. Каналы переиспользуются между проверками, поэтому соединение обычно устанавливается один раз, а не каждый раз заново.
3. Вызывает Check у grpc.health.v1.Health, передавая имя сервиса, с таймаутом монитора в качестве дедлайна вызова.
4. Превращает статус обслуживания — или ошибку gRPC — в результат проверки.

Числовой код сохраняется с каждой проверкой и отдаётся через API: номер статуса обслуживания, если сервер ответил на health-вызов, и код статуса gRPC, если не удался сам вызов. На странице монитора вы читаете сообщение рядом с ним, например «Service is NOT_SERVING» или «Health check not implemented by service».

Записанное время отклика покрывает вызов, включая установку соединения, если её пришлось делать. Когда соединение уже прогрето, это время самого health-вызова туда и обратно.

Имя сервиса

Health-протокол принимает имя сервиса, и пустое имя тоже осмысленно: это вопрос о здоровье сервера целиком. Именно его монитор и отправляет, когда поле пустое, и для большинства серверов это правильный выбор.

Заполняйте поле только именем, которое сервер действительно зарегистрировал, — вашим полным именем сервиса вроде orders.v1.Orders. Неизвестное серверу имя — не ошибка на вашей стороне провода: сервер вежливо отвечает SERVICE_UNKNOWN, а монитор считает это неудачей, потому что монитор, который не может назвать то, за чем следит, не следит ни за чем.

Серый текст-пример в форме — это только пример. Если скопировать его или любое другое имя, которого на сервере нет, вы получите вечно красный монитор на совершенно здоровом сервисе.

TLS и клиентские сертификаты

TLS — это один переключатель: Использовать TLS в настройках монитора. Включён — соединение идёт по TLS, а сертификат сервера проверяется по системному хранилищу доверенных корней; выключен — соединение идёт обычным HTTP/2 без шифрования.

Две вещи стоит знать заранее, до того как вы начнёте разбираться с красным монитором:

• Схема в адресе TLS не включает. Написанное grpcs:// выбирает тип монитора gRPC и задаёт хост с портом — и больше ничего. Если переключатель выключен, проверка всё равно подключится открытым текстом, и ваш TLS-сервер её отвергнет. Включайте переключатель.
• Поля для своего корневого сертификата нет. Сертификаты проверяются по публичному хранилищу доверия, поэтому сервер с самоподписанным сертификатом или с внутренним CA доверия не получает и соединение не устанавливается. Такие эндпоинты мониторьте без TLS изнутри сети, с приватной пробы.

Взаимный TLS — недоделанная функция. Проверяющий код поддерживает клиентский сертификат с ключом и использует их, если они есть, но задать их нельзя ни через интерфейс, ни через REST API, ни через инструменты MCP — так что эндпоинт, требующий клиентский сертификат, сейчас мониторить не получится. Он будет падать с «Authentication required (missing credentials)» или «Permission denied (check mTLS certificates)», и то и другое красное.

Логика статусов

Состояния деградации у gRPC-монитора нет. Любая проверка заканчивается как «работает», «не работает» или «таймаут».

Обратите внимание на случай, который отличается от HTTP-мониторинга: ограничение по скорости здесь приходит как RESOURCE_EXHAUSTED и считается простоем. HTTP-ответ 429 делает монитор DEGRADED и не стоит ни процента аптайма, а у gRPC-эквивалента такого обращения нет.

DOWN и TIMEOUT считаются простоем и открывают инцидент — после порога подтверждения, по умолчанию это три неудачные проверки подряд.

Настройки

Поля для метода в форме нет. Проверка всегда вызывает Check: health-протокол определяет только его и Watch, а для вызова вашего собственного метода нужны ваши protobuf-описания.

Ключевые возможности

• Стандартный протокол проверки здоровья grpc.health.v1 — тот же, которым пользуются пробы Kubernetes
• Здоровье отдельного сервиса или сервера целиком, если имя сервиса оставить пустым
• Соединение с TLS или без, с пулом каналов — повторные проверки не делают рукопожатие заново
• Каждый код статуса gRPC превращается в читаемое сообщение: не обслуживает, неизвестный сервис, нет health-сервиса, недоступен, нет аутентификации
• Работает из регионов PingZen или с приватной пробы внутри вашей сети