---
title: "\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u2014 Dinext"
description: "\u043d\u0430\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u0435 \u0437\u0430 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435\u043c \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b, \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c\u044e \u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044f\u043c\u0438 \u0440\u0430\u0431\u043e\u0442\u044b."
space: "Docs"
url: "https://docs.dinext.ru/docs/servisy-platformy/monitoring"
updated: "2026-07-09"
---

# Мониторинг

## Назначение

Сервис описывает наблюдение за состоянием платформы, производительностью и техническими показателями работы. Включает профилирование , технический мониторинг (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).

## Основные сценарии / процессов

### Профилирование медленной страницы

1. Включить профилирование в настройках разработки или через параметр запроса (если реализовано).
2. Открыть медленную страницу; дождаться загрузки.
3. Просмотреть отчет профилирования: время по функциям и запросам к БД; определить узкое место.
4. Оптимизировать запросы (индексы, уменьшение N+1, кэш) или вынести тяжелую логику в фоновую задачу.
5. В production профилирование обычно отключают или ограничивают из-за накладных расходов.

### Мониторинг доступности и очередей

1. Настроить внешний мониторинг (ping, HTTP check) на главную страницу или специальный health-эндпоинт.
2. Мониторить очередь заданий (Redis или используемый брокер): при росте длины очереди сверх порога — алерт; проверить воркеры и время выполнения заданий.
3. При использовании Dinext просматривать статус сайтов и последние бэкапы; настроить уведомления при сбое бэкапа по возможности приложения.
4. Собирать метрики (RPS, latency, ошибки) в Prometheus/Grafana или аналоге для построения трендов и алертов.

### Реагирование на инциденты

1. При алерте недоступности проверить: веб-сервер, воркеры, БД, диск. Просмотреть логи приложения и воркеров за последние минуты.
2. При деградации производительности — проверить очередь заданий, нагрузку на БД, медленные запросы в логах СУБД.
3. Документировать шаги восстановления и проводить постмортем при повторяющихся сбоях.
4. Резервное копирование и тесты восстановления выполнять по регламенту (см. «Отказоустойчивость»).

## Правила и ограничения

- Встроенный мониторинг 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).

## Связанные темы

- [Отказоустойчивость](/docs/servisy-platformy/otkazoustoychivost)
- [Фоновые задания](/docs/servisy-platformy/fonovye-zadaniya)
- [Высокие нагрузки](/docs/servisy-platformy/vysokie-nagruzki)
- [Логи и журналы](/docs/servisy-platformy/logi-i-zhurnaly)