Чек-лист аудита сервиса Glaber (раз в 1–3 месяца)

Архитектура: ClickHouse, C++-демон, PostgreSQL, Nginx

1. Общесистемные проверки сервиса

Проверка очереди
В GUI: Администрирование → Очередь. Наличие цифр до ~5% от общего числа метрик в первых двух колонках обычно нормально; если задержки растут в колонках с большим временем ожидания — разбираться (например, увеличивать число поллеров).
Если используются прокси-серверы — смотреть очередь по каждому прокси отдельно; на проблемных прокси так же решать вопросы производительности (увеличение поллеров или переход на асинхронные поллеры).
Графики и непрерывность данных
Выборочно на разных узлах просмотреть графики за 7–30 дней: они должны соответствовать реальности (нет необъяснимых провалов и скачков), не должно быть длительных провалов по данным. При аномалиях снять отладку по элементу данных (Администрирование → Отладка) так, чтобы в период съёма попали участки с аномалиями, и передать материалы в поддержку.
Проблемы и события
Открыть список проблем и несколько раз в течение часа просмотреть полный список — не должно быть массовых срабатываний.
Выборочно открыть 3–4 проблемы и проверить отсутствие «звона» (частых переключений триггеров on/off). Обычно на этом шаге всплывают ошибки в конфигурации триггеров. При ложных срабатываниях — пересмотреть условия, данные и при необходимости срок усреднения.
Просмотреть историю проблем за длительный период (2–3 месяца назад): нет ли старых незакрытых проблем — это часто сигнал об отсутствии реакции и требует административного решения.
Прочие проверки
Открыть служебный отчёт по количеству объектов (Отчёты → Информация о системе). Число неподдерживаемых элементов данных должно быть объяснимо текущей ситуацией (например, недоступность части устройств). Если неподдерживаемых элементов подозрительно много — в списке элементов любого узла снять фильтр по имени узла и оставить только неподдерживаемые; убедиться, что недоступность ожидаема.

2. C++-демон (ядро Glaber)

Стабильность процесса
Проверить uptime процесса glaber_server (в старых версиях — zabbix_server). Если uptime существенно меньше ожидаемого — по логам выяснить причины рестарта:
```
grep -i 'Glaber server' /var/log/glaber/glaber_server.log
```
При падениях — отправить разработчикам бэктрейсы. Если в логах есть остановка системным процессом (PID 1) — посмотреть dmesg -T (часто там OOM Killer и нехватка памяти).
Если собирается метрика Server Uptime (стандартный шаблон Zabbix) — посмотреть график за месяц: не должно быть необоснованных рестартов.
Утечки ресурсов
Смотреть метрики свободной памяти: краткосрочные колебания нормальны, но не должно быть монотонного роста потребления с последующим падением и рестартом. Если картина похожа на утечку — на узел, с которого мониторится Glaber Server, повесить шаблон Glaber process info (при необходимости добавить ссылку на документацию); через 2–4 дня оценить графики памяти по типам процессов. Важна динамика: из-за учёта памяти одни и те же сегменты у разных процессов могут суммироваться; высокое «статическое» потребление у множества процессов — норма. Нарастание памяти в первые сутки после старта (в т.ч. у history_syncer, glb_preproc_worker) — тоже ожидаемо.
Если снимается метрика открытых файлов — не должно быть непрерывного роста.
Проверить зомби-процессы (ps aux | grep defunct); если они относятся к Glaber — передать разработчикам вместе с выводом команды.
Задержки во внутренних пайплайнах
В логах искать переполнение буферов при передаче в препроцессинг или процессинг:
```
grep preprocessing /var/log/glaber/glaber_server.log
grep processing /var/log/glaber/glaber_server.log
```
Такие записи могут указывать на массовые блокировки. - Утилизация ключевых ресурсов - CPU: целесообразно держать CPU idle выше ~40% (запас по процессору). При высокой загрузке — top -c и понять, что грузит систему; дальнейшие шаги зависят от числа пользователей и объёма метрик. - Диск (операции): не должно быть устойчивой «полки» по дисковым операциям. - Диск (место): остаток и динамика по разделам: логи, том с ClickHouse, том с PostgreSQL, временный каталог (/tmp или иной), при использовании — /var/state/glaber. - Сеть: загрузка интерфейсов — без устойчивой полки по трафику. - Ключевые метрики сервера — шаблон «Zabbix server»; детализация по хосту — «Linux by Zabbix agent». Если чего-то нет — добавить и вернуться к проверке в следующем цикле.

3. ClickHouse

Проверка роста базы
Метрики занятого/свободного места на дисках: тенденция должна быть ожидаемой; при необходимости скорректировать TTL таблиц или увеличить диск.
Свободное место: прогноз заполнения; менее 90 дней до переполнения — нужно действие.
Служебные таблицы и их размер
В clickhouse-client посмотреть, какие таблицы занимают больше всего места:
```
SELECT
  database,
  table,
  formatReadableSize(sum(bytes)) AS size
FROM system.parts
WHERE active
GROUP BY database, table;
```
В типичной установке лишние служебные логи отключены — на диске в основном таблицы glaber*. Если есть лишние таблицы с базой system и суффиксом _log, которые не включали намеренно — отключить по рекомендациям по настройке ClickHouse и очистить накопленные данные, например: TRUNCATE TABLE system.part_log;. - Дополнительно: фоновые процессы - Очередь слияний: SELECT count() FROM system.merges. Более пяти долгих (например, более 24 ч) задач — признак проблемы; часто помогает перезапуск clickhouse-server. - Дополнительно: кластер - Отставание репликации: SELECT absolute_delay FROM system.replicas. Задержка должна быть в ожидаемых пределах. При сильной географической распределённости (задержка сети 100–150 мс) до ~1 минуты возможно; при вводе новой ноды отставание может быть заметным. В штатном режиме обычно 10–15 с и меньше. - Дополнительно: производительность - Загрузка процессов ClickHouse (top -c и аналоги). При небольшом числе пользователей (порядка 1–10) типично нет постоянной перегрузки одного ядра свыше 100%; при большом числе пользователей (30+) или сразу после запуска нагрузка может быть существенно выше.

4. PostgreSQL

Размер данных и рост
Оценить размер и тренд роста тома/раздела с PostgreSQL или каталога данных (например, du -skh /var/lib/postgresql). Обычно после 3–4 месяцев стабильной работы суммарный объём не должен непрерывно расти без причины. Проверить сроки хранения аудита и истории в GUI (Администрирование).
Подключения
При жалобах пользователей, записях во фронтенд- или glaber_server-логах вида too many connections — увеличить max_connections в конфигурации PostgreSQL. Для небольших установок часто хватает порядка 100, для крупных — до 1000 и выше.
Отставание репликации (если используется)
На реплике выполнить:
```
SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;
```
Существенное отставание по времени (на порядки выше нормы для вашей среды) нужно разбирать вручную: часто это ошибка репликации и разрастание WAL/данных для догона.

5. Nginx

Ошибки фронтенда
Просмотреть error.log (часто /var/log/nginx/error.log). Падения с backtrace — в техподдержку. Сообщения о нехватке памяти, лимитах параметров, таймаутах — увеличить ресурсы или передать полный лог, если лимиты уже выглядят завышенными.
SSL/TLS и сертификаты
Ошибки handshake: grep 'SSL_do_handshake.*failed' /path/to/error.log
Срок действия сертификата: openssl x509 -enddate -noout -in /path/to/cert.pem. Если до истечения срока осталось менее 60 дней — запланировать обновление.

6. Резервное копирование и восстановление

Проверить наличие бэкапов:

ClickHouse
PostgreSQL
Конфигурация: /etc/glaber/, /etc/nginx/, /etc/postgresql/, /etc/php/

7. Планирование мощностей

Дисковая подсистема
Прогноз заполнения при текущем темпе роста: менее 90 дней — планировать расширение.
CPU демона
Устойчивая загрузка свыше 70% пользовательского времени — масштабировать сервер или переносить часть опроса на прокси.
Сеть
Загрузка интерфейсов на хостах приёма данных (vnstat, iftop и т.п.) — без устойчивой полки.