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

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

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

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

/healthz — простая проверка ответа процесса. /livez предназначен для проверки, что контейнер отвечает; в закреплённом исходнике оба адреса используют один базовый обработчик. Если система мониторинга просит именно liveness probe, используйте /livez, но не выдавайте его HTTP 200 за проверку своих документов. s2 s4 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 s3

Если /healthz дал 200, а /readyz — 503, сервер откликается, но готовность не подтверждена: не отправляйте ему рабочую нагрузку, опираясь только на healthz. Если оба дали 200, откройте проверку существования конкретной коллекции, а затем выполните безопасный контрольный поиск в собственной учебной коллекции. Ни один из трёх probe не принимает имя коллекции и не выполняет такой поиск. s2 s6

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

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

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