Модуль 10. Эксплуатация и мониторинг StarRocks
Методологическое понимание эксплуатации
StarRocks — это распределённая MPP-система, и её эксплуатация — это не только «следить, чтобы сервис был в онлайне».
Хорошая эксплуатация включает:
- Мониторинг: состояния FE/BE, ingest, compaction, ресурсов.
- Плановое обслуживание: обновления, ребалансировка, чистка.
- Управление ростом данных: TTL, агрегация, контроль партиций.
- Предотвращение деградации: выявление проблем до того, как пользователи их заметят.
Методология:
- Автоматизировать сбор метрик — человек не успеет «глазами» отследить.
- Вести операционный журнал — все изменения конфигураций фиксировать.
- Проводить тесты восстановления — заранее проверять сценарии отказа.
Основные зоны мониторинга
1. Состояние кластера
- FE/BE должны быть в Alive статусе.
- Команды:
SHOW PROC '/frontends'; SHOW PROC '/backends';
-
Проверяем:
- Alive=true
- LastStartTime — нет частых рестартов
- Версии FE/BE совпадают
2. Ресурсы
- CPU, RAM, диск, сеть.
-
Мониторить:
- CPU load — пики >80% длительное время → масштабировать.
- Memory usage — OutOfMemory на BE при join/aggregation.
- Disk usage — держать минимум 30% свободного.
- Network throughput — особенно между FE и BE.
3. Ingestion
- Lag в Kafka/Routine Load.
- Очередь задач в Broker Load.
- Ошибки загрузки.
4. Компакшн
- Очередь compaction на BE.
- Время компакшна и его конкуренция с ingest.
-
Метрики:
- base_compaction_score
- cumulative_compaction_score
5. Запросы
- Время выполнения (P50, P95, P99).
- Количество одновременных запросов.
- Top-N тяжёлых запросов (по CPU и времени).
Инструменты мониторинга
Prometheus + Grafana
- Экспорт метрик с FE/BE.
-
Дашборды:
- Cluster Overview — Alive/Dead nodes, CPU/RAM/disk.
- Ingestion — lag, errors.
- Query Performance — latency, slow queries.
- Compaction — очередь и длительность.
Логи StarRocks
-
FE:
- fe.log — общие события.
- fe.warn.log — предупреждения.
- audit.log — запросы пользователей.
- BE:
- be.INFO
- be.WARNING
- be.ERROR
SIEM (Splunk, ELK)
- Интеграция для аудита и безопасности.
Плановое обслуживание
-
Обновление версии
- FE и BE обновляем согласованно.
- На кластере с HA обновляем поочерёдно (rolling update).
- Проверка: SELECT VERSION();
- Ребалансировка данных
- При добавлении/удалении BE:
ADMIN REBALANCE TABLE sales;
- Мониторинг прогресса.
- Чистка старых данных
- TTL на партиции.
- DROP старых MVs.
- ANALYZE TABLE после больших перезагрузок.
- Обновление статистики
Практические кейсы
Кейс 1. Рост задержки BI-отчётов
- Симптом: P95 latency вырос с 2 до 10 сек.
- Диагностика: PROFILE показал рост времени shuffle.
- Решение: перераспределили таблицы по ключу join, очистили старые партиции.
- Результат: SLA восстановлен.
Кейс 2. Lag в ingestion из Kafka
- Симптом: задержка ingestion > 30 минут.
- Диагностика: compaction занимал CPU в часы пиков.
- Решение: вынесли compaction в ночное окно, увеличили max_batch_rows.
- Результат: lag снизился до < 2 минут.
Кейс 3. Заполнение диска на BE
- Симптом: один BE 95% full, ingest остановился.
- Диагностика: неравномерная дистрибуция данных.
- Решение: rebalance, настройка hash key, добавление BE.
- Результат: нагрузка распределена.
Риски и защита
|
Риск |
Симптом |
Как избежать |
|---|---|---|
|
Переполнение диска |
Ошибки записи, остановка ingestion |
Headroom ≥30%, алерты |
|
Долгий compaction |
Lag ingestion |
Развести по времени |
|
Падение FE |
BI не работает |
Минимум 3 FE в HA |
|
Неравномерная дистрибуция |
BE перегружен |
Равномерный hash key, ребаланс |
|
Устаревшая статистика |
Плохие планы |
ANALYZE TABLE |
Методологические рекомендации
- Автоматизировать алерты: диски, CPU, ingestion lag, dead nodes.
- Отдельные дашборды для BI и ingestion — разные метрики важны для разных команд.
- Тестировать обновления на dev перед продом.
- Раз в квартал — аудит MVs и партиций.
- Вести документацию по изменениям конфигов и структуры кластера.
