Qdrant - Vector Database
Мониторинг и Метрики
Qdrant в production работает 2 недели без проблем - вы уверены что всё хорошо. Но Grafana показала бы: память выросла на 40% за неделю, pending_optimizations спайкует ночью, P99 латентность удвоилась в пятницу вечером. Мониторинг превращает «кажется всё работает» в «знаю что работает».
- **Plannable scaling:** Grafana-тренд memory_usage предупредил за 2 недели до OOM - успели добавить квантизацию без инцидента
- **Performance regression:** после деплоя P99 latency выросла с 80ms до 400ms. Метрики показали: новая версия изменила дефолтный hnsw_ef
- **Kubernetes автомасштабирование:** HPA на метрике pending_optimizations добавляет ноды при пиковой нагрузке на индексирование
Предварительные знания
Prometheus метрики: что смотреть в первую очередь
**Qdrant экспортирует метрики** в формате Prometheus на эндпоинте `/metrics`. Более 50 метрик: состояние коллекций, очереди оптимизации, потребление RAM, latency запросов. Это единственный надёжный способ понять что происходит внутри.
| Метрика | Тип | Что значит | Порог для алерта |
|---|---|---|---|
| app_info | gauge | Версия приложения (всегда 1) | Если 0 - процесс упал |
| collections_total | gauge | Число коллекций | Неожиданное изменение |
| collection_vectors_count | gauge | Векторов в коллекции | Стагнация при активной индексации |
| rest_response_duration_seconds_p99 | histogram | P99 latency REST запросов | > 500ms |
| grpc_response_duration_seconds_p99 | histogram | P99 latency gRPC запросов | > 200ms |
| pending_optimizations | gauge | Сегменты ждут оптимизации | > 10 долго |
| wal_sequence_number | gauge | Позиция Write-Ahead Log | Зависание (не растёт при записи) |
Метрика `pending_optimizations` показывает значение 15 и не уменьшается 30 минут. Что это означает и что делать?
Health Checks: /health, /readyz, /livez
**Три эндпоинта здоровья** в Qdrant для разных целей: `/health` - базовая доступность, `/readyz` - готовность принимать трафик (liveness + readiness), `/livez` - нода жива. Используются Kubernetes, load balancers, мониторинг-системами.
**Разница readiness и liveness:** `livez` отвечает «нода запущена» - используйте для livenessProbe (Kubernetes перезапустит pod если он завис). `readyz` отвечает «нода готова принимать трафик» - используйте для readinessProbe (Kubernetes убирает pod из балансировки пока он восстанавливается). Без правильных probe - rolling update сломает сервис.
После rolling update Qdrant нода начала отвечать на /livez (200), но /readyz возвращает 503. Kubernetes направляет трафик на эту ноду или нет?
Grafana Dashboard: настройка и ключевые алерты
**Grafana + Prometheus** - стандартный стек для мониторинга Qdrant. Qdrant предоставляет официальный Grafana dashboard (ID: 20650 на grafana.com). Настройка занимает 15 минут.
**Важные панели в Grafana dashboard:** 1) «Vectors indexed» - должен расти при активной индексации. 2) «Search requests rate» - аномальные пики могут указывать на DDoS или баги клиента. 3) «Memory usage» - тренд роста предупреждает о необходимости квантизации или масштабирования. 4) «Pending optimizations» - должен стремиться к 0 в спокойном состоянии.
Grafana показывает: `pending_optimizations` = 0, `rest_response_duration_seconds_p99` = 2.3 сек. Нода здорова по /readyz. Что скорее всего вызывает высокую latency?
Ключевые идеи
- **GET /metrics** - Prometheus-формат, 50+ метрик. Основные: pending_optimizations, rest_response_duration_seconds, process_resident_memory_bytes
- **/livez** - нода жива (livenessProbe). **/readyz** - готова к трафику (readinessProbe). Разница критична для Kubernetes
- **Grafana dashboard ID 20650** - официальный дашборд Qdrant. Подключается за 15 минут через Prometheus datasource
- **5 ключевых алертов:** нода down, P99 > 500ms, pending_optimizations > 20 (15m), RAM > 85%, Dead shards
- **Телеметрия** (`/telemetry`) - детальная статистика по коллекциям и запросам. Удобна для отладки
Что дальше
Мониторинг показал проблемы - теперь разберём как оптимизировать производительность Qdrant.
- Настройка производительности — Метрики выявляют bottleneck - оптимизация решает
- Репликация — Мониторинг Dead shards и состояния реплик
- Квантизация — process_resident_memory_bytes растёт - время включать квантизацию
Вопросы для размышления
- В чём разница между /health, /livez и /readyz? Приведите конкретный сценарий когда нода возвращает 200 на /livez но 503 на /readyz - что происходит в этот момент?
- Метрика pending_optimizations = 0, но поиск медленный. Какие ещё метрики вы проверите? Составьте план диагностики latency.
- Как настроить мониторинг для distributed Qdrant (3 ноды)? Нужны ли отдельные Prometheus targets для каждой ноды? Как агрегировать метрики кластера?