Мониторинг
Назначение
Сервис описывает наблюдение за состоянием платформы, производительностью и техническими показателями работы. Включает профилирование , технический мониторинг (monitor.py), а также мониторинг bench, сайтов и резервных копий через Dinext.
Цели и задачи
- Отслеживать доступность приложения и время отклика.
- Выявлять узкие места по производительности (профилирование, медленные запросы).
- Мониторить очередь заданий, воркеры и планировщик.
- Контролировать состояние сайтов, бэкапов и ресурсов сервера через Dinext при установке.
- Обеспечивать оперативное реагирование на сбои и деградацию сервиса.
Для кого
- Администраторы и DevOps при настройке и анализе метрик.
- Разработчики при оптимизации медленных страниц и запросов.
- Руководители ИТ при планировании ресурсов и SLA.
Основные понятия
- monitor.py — модуль технического мониторинга (health check, метрики при наличии).
- Dinext — приложение для мониторинга bench, сайтов, бэкапов (README).
- Health check — эндпоинт или скрипт проверки доступности приложения и зависимостей (БД, Redis).
- Метрики — количество запросов, время ответа, размер очереди заданий, использование CPU/RAM; сбор через внешние системы (Prometheus, Grafana) или встроенные средства при настройке.
Основные сущности / объекты
- monitor.py .
- Dinext (README).
Основные сценарии / процессов
Профилирование медленной страницы
- Включить профилирование в настройках разработки или через параметр запроса (если реализовано).
- Открыть медленную страницу; дождаться загрузки.
- Просмотреть отчет профилирования: время по функциям и запросам к БД; определить узкое место.
- Оптимизировать запросы (индексы, уменьшение N+1, кэш) или вынести тяжелую логику в фоновую задачу.
- В production профилирование обычно отключают или ограничивают из-за накладных расходов.
Мониторинг доступности и очередей
- Настроить внешний мониторинг (ping, HTTP check) на главную страницу или специальный health-эндпоинт.
- Мониторить очередь заданий (Redis или используемый брокер): при росте длины очереди сверх порога — алерт; проверить воркеры и время выполнения заданий.
- При использовании Dinext просматривать статус сайтов и последние бэкапы; настроить уведомления при сбое бэкапа по возможности приложения.
- Собирать метрики (RPS, latency, ошибки) в Prometheus/Grafana или аналоге для построения трендов и алертов.
Реагирование на инциденты
- При алерте недоступности проверить: веб-сервер, воркеры, БД, диск. Просмотреть логи приложения и воркеров за последние минуты.
- При деградации производительности — проверить очередь заданий, нагрузку на БД, медленные запросы в логах СУБД.
- Документировать шаги восстановления и проводить постмортем при повторяющихся сбоях.
- Резервное копирование и тесты восстановления выполнять по регламенту (см. «Отказоустойчивость»).
Правила и ограничения
- Встроенный мониторинг Dinext ограничен; для полноценного наблюдения за production рекомендуется интеграция с системами мониторинга (Prometheus, Nagios, облачные мониторинги).
- Профилирование в production может влиять на производительность; использовать выборочно или на копии нагрузки.
- Dinext может требовать прав супер-администратора; не открывать его публично.
Результаты / отчетность
- Дашборды метрик (внешние или встроенные): доступность, RPS, время ответа, очередь заданий.
- Отчеты профилирования для оптимизации кода.
- Журнал алертов и инцидентов для анализа и улучшения стабильности.
Типовые вопросы и ошибки (FAQ)
Где смотреть медленные запросы к БД?
В логах приложения при включенном логировании SQL или в логах СУБД (slow query log). В некоторых версиях Dinext есть страница или отчет с последними запросами и временем выполнения; уточните в документации. Внешние APM-инструменты также могут перехватывать запросы.
Как настроить health check для балансировщика?
Создайте простой эндпоинт (например, /api/method/ping или /health), возвращающий 200 при доступности приложения и БД. Настройте проверку балансировщика на этот URL. Реализация ping/health может быть в приложении или в конфигурации веб-сервера.
Dinext не показывает статус воркеров
Воркеры могут быть запущены вне bench (например, через systemd); Dinext мониторит то, что запущено через bench. Проверьте, как у вас запущены воркеры, и при необходимости настройте мониторинг процессов отдельно (systemd status, supervisor, или метрики процесса в Prometheus).