# Qdrant health check: как проверить сервер и готовность к запросам

Источник: https://modelium.tech/zhurnal/qdrant-health-check/

Для проверки собственного локального Qdrant запросите `/healthz` и `/readyz`: первый отвечает за базовую доступность процесса, второй проверяет готовность принимать трафик с учётом шардов. Ответ 200 не доказывает, что нужная коллекция существует и поиск в ней работает. Ниже — чтение только с localhost, без изменения данных; настоящий Qdrant редакция не запускала.

**Инженерный уровень.** Нужен уже запущенный собственный Qdrant и терминал Linux или macOS с `curl`. Пример обращается только к `127.0.0.1:6333` на вашем компьютере; если у вас Docker или удалённый узел, адрес и сетевой доступ могут отличаться. Шаги сверены по документации Qdrant v1.19.x и исходнику v1.19.0 на 20 октября 2026 года, но **редакция не запускала настоящий сервер**. Это не домашний рецепт запуска AI-модели. [s1](#src-s1) [s2](#src-s2)

## Как увидеть, отвечает ли локальный сервер?

Представьте: приложение не находит документы в Qdrant. Сначала убедитесь, что сам сервер отвечает, а затем отдельно проверьте готовность и нужную коллекцию. В терминале выполните `curl -i --max-time 5 'http://127.0.0.1:6333/healthz'`. Ищите строку статуса `HTTP/1.1 200 OK` или `HTTP/2 200` и короткий текст проверки. Если соединение отвергнуто или время вышло, эта проверка **не прошла**: сначала проверьте запуск Qdrant, адрес и проброс порта по [гайду локальной установки](/zhurnal/qdrant-lokalno/). [s1](#src-s1) [s4](#src-s4)

`/healthz` — простая проверка ответа процесса. `/livez` предназначен для проверки, что контейнер отвечает; в закреплённом исходнике оба адреса используют один базовый обработчик. Если система мониторинга просит именно liveness probe, используйте `/livez`, но не выдавайте его HTTP 200 за проверку своих документов. [s2](#src-s2) [s4](#src-s4) [s5](#src-s5)

## Как проверить готовность, а не только ответ процесса?

В том же терминале выполните `curl -i --max-time 5 'http://127.0.0.1:6333/readyz'`. **Probe** — короткий запрос-проверка. Для Qdrant v1.19.0 этот адрес при успешной проверке возвращает HTTP 200; когда проверка готовности шардов отрицательна, возвращает HTTP 503. Шард — часть данных коллекции, размещённая на узле. В исходнике есть особый случай: если проверяющий компонент не задан, `/readyz` тоже отвечает 200. Поэтому даже 200 означает только прохождение именно этого probe, а не гарантию исправного поиска для вашей коллекции. [s2](#src-s2) [s3](#src-s3)

Если `/healthz` дал 200, а `/readyz` — 503, сервер откликается, но готовность не подтверждена: **не отправляйте ему рабочую нагрузку, опираясь только на healthz**. Если оба дали 200, откройте [проверку существования конкретной коллекции](/zhurnal/qdrant-proverit-sushchestvovanie-kollekcii/), а затем выполните безопасный контрольный поиск в собственной учебной коллекции. Ни один из трёх probe не принимает имя коллекции и не выполняет такой поиск. [s2](#src-s2) [s6](#src-s6)

## Что означают ошибка и отсутствие ключа?

Команды выше только читают состояние; они не создают и не удаляют точки. Пример результата — `healthz: 200`, `readyz: 503`: это **условный пример для чтения статусов**, не результат запуска Modelium. При `connection refused` сначала проверьте локальный адрес и работающий процесс; при 503 на `/readyz` не подменяйте его успешным `/livez` и выясните причину неготовности на своём узле. [s2](#src-s2) [s3](#src-s3)

Официальная страница мониторинга говорит, что `/healthz`, `/livez` и `/readyz` доступны даже при настроенном API-ключе; типовая карточка API при этом помечает заголовок `api-key` как обязательный. В закреплённых обработчиках этих трёх адресов нет проверки `ActixAuth`. Не считайте API-ключ защитой публично выставленных probe или остальных маршрутов: ограничьте сетевой доступ к серверу и проверьте реальные права отдельно. Не вставляйте секрет в публичную команду, лог или скриншот. [s1](#src-s1) [s2](#src-s2) [s3](#src-s3) [s4](#src-s4)

## Источники

1. [Qdrant — Monitoring & Telemetry, Kubernetes Health Endpoints](https://qdrant.tech/documentation/ops-monitoring/monitoring/) — получено 2026-10-20
2. [Qdrant v1.19.0 — service_api.rs](https://github.com/qdrant/qdrant/blob/74f3e85b9473c62560006c043e13737ce6b48412/src/actix/api/service_api.rs) — получено 2026-10-20
3. [Qdrant API v1.19.x — Kubernetes readiness probe](https://api.qdrant.tech/v-1-19-x/api-reference/service/readyz.md) — получено 2026-10-20
4. [Qdrant API v1.19.x — Kubernetes health check](https://api.qdrant.tech/v-1-19-x/api-reference/service/healthz.md) — получено 2026-10-20
5. [Qdrant API v1.19.x — Kubernetes liveness probe](https://api.qdrant.tech/v-1-19-x/api-reference/service/livez.md) — получено 2026-10-20
6. [Qdrant API v1.19.x — Check collection existence](https://api.qdrant.tech/v-1-19-x/api-reference/collections/collection-exists.md) — получено 2026-10-20