Мониторинг gRPC
gRPC-монитор вызывает на вашем сервере стандартный health-сервис — один унарный Check у grpc.health.v1.Health — и записывает, что пришло в ответ. SERVING значит «работает». NOT_SERVING значит, что сервер жив и сам говорит, что обслуживать запросы не готов, а это совсем другой сигнал, чем мёртвый порт.
Для чего подходит
Бэкенд, который говорит только по gRPC
Внутренний сервис без HTTP вообще: нет адреса, который можно запросить, нет страницы, которую можно загрузить, браузеру открывать нечего. Health-сервис — единственное, что отвечает на вопрос «да или нет», и этот монитор его и спрашивает.
Та же проверка, которую уже делает ваш оркестратор
Если у подов есть gRPC-проба readiness или liveness, сервер уже реализует grpc.health.v1.Health. Монитор делает тот же вызов снаружи кластера, поэтому вы видите то же, что видит Kubernetes, плюс всё, что стоит между вами и кластером и чего Kubernetes не касается.
Один сервис внутри сервера, где их несколько
Health-протокол работает по имени сервиса: процесс может сообщать, что orders.v1.Orders обслуживает запросы, а billing.v1.Billing — нет. Укажите монитору имя сервиса, и он спросит именно про него: наполовину сломанный процесс станет красным монитором, а не зелёным.
Сервисы, доступные только изнутри
Обычно gRPC живёт в приватной сети и наружу не выставляется. Приватный чекер умеет и gRPC-проверки, так что сервис в своём кластере можно мониторить, не открывая порт всему интернету.
Для чего не подходит
Монитор делает ровно один вызов, и это всегда health-вызов. Это не gRPC-клиент для ваших собственных методов:
| Что нужно узнать | Что использовать |
|---|---|
| Отвечает ли мой REST- или JSON-API? Он говорит по HTTP, а не по gRPC, и health-вызову там ответить некому | Монитор HTTP / HTTPS |
| Открыт ли порт вообще? На сервере не зарегистрирован health-сервис, и gRPC-проверке нечего вызывать | Монитор TCP на порт gRPC |
| Когда истекает сертификат на моём gRPC-эндпоинте с TLS? Health-вызов на сертификат не смотрит — только на то, получилось ли рукопожатие сегодня | Монитор TLS/SSL-сертификата |
| Работает ли цепочка вызовов целиком, когда значение из одного вызова нужно в следующем? | Монитор API-проверки — он выстраивает запросы в цепочку и передаёт значения между ними |
Возвращает ли мой собственный RPC правильные данные? PingZen вызывает только Check: ваших protobuf-описаний у него нет и ваши методы он вызвать не может | Монитор Heartbeat — его зовёт ваша задача, которая и делает настоящий вызов |
Что делает проверка
- Собирает цель из адреса, подставляя порт
50051, если вы его не указали. - Открывает канал — с TLS, если вы его включили, иначе обычный HTTP/2. Каналы переиспользуются между проверками, поэтому соединение обычно устанавливается один раз, а не каждый раз заново.
- Вызывает
Checkуgrpc.health.v1.Health, передавая имя сервиса, с таймаутом монитора в качестве дедлайна вызова. - Превращает статус обслуживания — или ошибку 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-монитора нет. Любая проверка заканчивается как «работает», «не работает» или «таймаут».
| Что ответил сервер | Статус |
|---|---|
| SERVING | UP |
| NOT_SERVING — сервер жив и говорит, что обслуживать запросы не готов | DOWN |
| SERVICE_UNKNOWN — health-сервис на сервере есть, а такого имени сервиса нет | DOWN |
| UNIMPLEMENTED — health-сервис на сервере не реализован вообще («Health check not implemented by service») | DOWN |
| UNAVAILABLE — соединение установить не удалось («Service unavailable (connection failed)») | DOWN |
| UNAUTHENTICATED или PERMISSION_DENIED — эндпоинт требует учётные данные, которых монитор отправить не может | DOWN |
| RESOURCE_EXHAUSTED, INTERNAL и любой другой код ошибки gRPC | DOWN |
| Имя не разрезолвилось, в соединении отказано или что-то ещё пошло не так до ответа | DOWN |
| DEADLINE_EXCEEDED — ответа не было в пределах таймаута монитора | TIMEOUT |
Обратите внимание на случай, который отличается от HTTP-мониторинга: ограничение по скорости здесь приходит как RESOURCE_EXHAUSTED и считается простоем. HTTP-ответ 429 делает монитор DEGRADED и не стоит ни процента аптайма, а у gRPC-эквивалента такого обращения нет.
DOWN и TIMEOUT считаются простоем и открывают инцидент — после порога подтверждения, по умолчанию это три неудачные проверки подряд.
Настройки
Адрес
Хост и порт в виде api.example.com:50051. Схема grpc:// или grpcs:// принимается и отбрасывается, IPv6 пишется в квадратных скобках: [2001:db8::1]:50051, а голый хост без порта получает порт 50051. Адрес вида http:// или https:// тоже принимается: из него остаются только хост и порт (https:// по умолчанию 443, http:// — 80), путь отбрасывается, потому что gRPC подключается к хосту и порту, а не к URL. Схема никогда не решает, будет ли TLS, — это делает переключатель TLS.
gRPC сервис
Имя сервиса, про который спрашивать, до 255 символов. Пусто — значит сервер целиком, и это разумное значение по умолчанию. Указывайте имя, только если сервер зарегистрировал ровно его.
Использовать TLS
По умолчанию выключено. Включено — соединение идёт по TLS, а сертификат сервера проверяется по публичному хранилищу доверия. Выключено — обычный HTTP/2. Решает это только этот переключатель.
Таймаут
По умолчанию пять секунд, и это дедлайн health-вызова. Сервер, который отвечает медленнее, получает таймаут, а не медленный успех.
Интервал
По умолчанию шестьдесят секунд. Своего минимума у gRPC нет: health-вызов дешёвый, соединение переиспользуется, поэтому короткий интервал почти ничего не стоит вашему серверу.
Поля для метода в форме нет. Проверка всегда вызывает Check: health-протокол определяет только его и Watch, а для вызова вашего собственного метода нужны ваши protobuf-описания.
Ключевые возможности
- Стандартный протокол проверки здоровья
grpc.health.v1— тот же, которым пользуются пробы Kubernetes - Здоровье отдельного сервиса или сервера целиком, если имя сервиса оставить пустым
- Соединение с TLS или без, с пулом каналов — повторные проверки не делают рукопожатие заново
- Каждый код статуса gRPC превращается в читаемое сообщение: не обслуживает, неизвестный сервис, нет health-сервиса, недоступен, нет аутентификации
- Работает из регионов PingZen или с приватного чекера внутри вашей сети