Мониторинг и оптимизация производительности СЭД: метрики, Prometheus, Grafana и Zabbix

Проблемы производительности СЭД почти никогда не выглядят как полное падение сервиса. Сначала растёт время открытия карточки документа, потом копятся задачи в очереди согласования, а через неделю пользователи жалуются, что поиск по архиву «задумался» на 15-20 секунд. Причина в большинстве случаев лежит в одном из четырёх слоёв: приложение, СУБД, файловая система или сеть между ними. Задача администратора - не угадать слой, а измерить его и подтвердить гипотезу метрикой.

Рабочий порядок разбора для высоконагруженной СЭД: снять пользовательские метрики (время отклика, пропускная способность), затем ресурсные (CPU, диск, память, сеть), после чего спуститься на уровень СУБД и файловой системы. Такой проход сверху вниз отсекает ложные версии за минуты. Ниже - конкретные метрики с порогами, готовые конфигурации Prometheus, Grafana и Zabbix, пошаговая диагностика узких мест и методы ускорения с указанием условий, в которых они дают прирост.

Ключевые метрики производительности СЭД: что измерять и как интерпретировать

Метрики СЭД делятся на четыре группы: пользовательские (время отклика, пропускная способность), ресурсные (CPU, память, диск, сеть), метрики СУБД (медленные запросы, блокировки, объём WAL) и прикладные (очередь заданий, ошибки API, число активных сессий). Первые две группы показывают симптом, две последние - причину.

Пороги не заменяют ваш SLA, но дают точку отсчёта. Если p95 времени отклика уходит за 200 мс, пользователь уже замечает паузу при открытии карточки, а при p99 выше секунды начинает обновлять страницу, добавляя нагрузку и без того загруженному серверу.

Средние значения скрывают проблему: одиночный пик в 30 секунд на 1% запросов почти не сдвинет среднее, но именно он вызывает жалобы. Снимайте гистограммы и считайте p50, p95 и p99. Базовый набор команд и пороговых значений для Linux-сервера разобран в материале о мониторинге производительности сервера: метриках CPU, памяти, диска и сети.

Время отклика и пропускная способность: как связаны и что важнее

Закон Литтла связывает три величины: L = λ × W, где L - число задач в системе, λ - интенсивность поступления запросов, W - время обработки одного запроса. СЭД, принимающая 200 запросов в секунду при отклике 150 мс, держит в работе примерно 30 одновременных операций. Если время обработки вырастет до 1,5 секунды при той же интенсивности, в системе окажутся уже 300 задач, и появятся очереди, таймауты соединений и рост потребления памяти.

Высокая пропускная способность при плохом времени отклика - обычное дело для пакетных сценариев: массовая загрузка документов, индексация поиска, выгрузка архива. Пользователь взаимодействует с системой в режиме одиночных операций, поэтому для него важнее latency, а throughput критичен для регламентных задач.

Наглядный пример разницы архитектур даёт 1С:Предприятие 8.3. В синтетическом тесте Гилёва, который измеряет короткие последовательные транзакции в один поток, серверная конфигурация показывает 12-18 баллов, тогда как локальная файловая база на обычном ПК - 70-90 баллов. Объяснение в накладных расходах клиент-серверного режима: сериализация и контекстные переходы по RPC, трансляция запроса в SQL с построением плана выполнения, запись страницы журнала (WAL в PostgreSQL или LDF в MS SQL Server) на накопитель с ожиданием подтверждения контроллера. В файловом режиме операции выполняет один процесс через Memory-Mapped I/O и системный кэш ОС, полноценного WAL с синхронным fsync нет. Отсюда вывод: синтетический однопоточный тест подходит для сравнения движков, а не для прогноза многопользовательской нагрузки СЭД.

Каждый commit с fsync добавляет к отклику задержку накопителя: типичные значения 0,05-0,15 мс для NVMe, 0,3-0,7 мс для SATA SSD и 5-12 мс для жёсткого диска. Проверяйте эти цифры на своём железе через fio, прежде чем винить код приложения.

Загрузка CPU и дисковые операции: где искать узкое место

Простой алгоритм разделения проблем: откройте top или htop и посмотрите распределение по режимам. Высокий wa при низкой загрузке us означает, что процессы ждут диск. Высокий sy вместе с большим числом переключений контекста указывает на накладные расходы межпроцессного взаимодействия и сетевого обмена. Высокий us при низкой пропускной способности говорит о неэффективном коде или отсутствии нужных индексов.

• vmstat 1 - колонки r и b показывают очередь на CPU и число процессов в блокировке ввода-вывода, si и so фиксируют активность swap.
• iostat -x 1 - смотрите await (среднее время ожидания операции), %util (утилизация), aqu-sz (глубина очереди). Рост await при утилизации ниже 80% часто означает проблему на уровне массива или контроллера.
• iotop -oPa - покажет конкретные процессы, которые генерируют дисковую нагрузку.

Разница между режимами хранения документов проявляется именно здесь. В клиент-серверной архитектуре каждая транзакция завершается записью в журнал с обязательным fsync, и при большом числе мелких операций диск становится ограничителем раньше процессора. В файловом режиме 1С страницы базы 1Cv8.1CD отображаются в память, кэш ОС сглаживает большинство чтений, зато появляется конкуренция за блокировки файла между сеансами и риск потери данных при отключении питания.

Настройка мониторинга и алертов для СЭД: Prometheus, Grafana, Zabbix

Инструменты дополняют друг друга: Prometheus собирает числовые метрики и считает правила, Grafana визуализирует, Zabbix закрывает доступность, инвентаризацию и уведомления там, где агенты уже развёрнуты. Нормальная схема для СЭД - системные метрики через node_exporter или windows_exporter, метрики СУБД через специализированные экспортеры, метрики приложения через собственный endpoint.

Обязательный набор сборщиков:

• node_exporter и windows_exporter: CPU, память, диск, сеть, свободное место, inode, состояние сервисов.
• postgres_exporter: соединения, транзакции, блокировки, размер WAL, статистика pg_stat_statements.
• mssql_exporter или SQL exporter с собственными запросами к sys.dm_os_wait_stats и sys.dm_exec_query_stats.
• blackbox_exporter: HTTP-проба карточки документа, проверка TCP-порта СУБД, контроль доступности узлов кластера.
• Собственный endpoint /metrics в приложении: счётчик операций с документами, гистограммы времени, число ошибок.

Интервал сбора 15 секунд подходит для инфраструктуры, но для времени отклика приложения берите 5-10 секунд, иначе короткие пики останутся незамеченными. Локальную ретенцию держите в диапазоне 30-90 дней, а для годовой динамики настройте remote write во внешнее хранилище.

Стенд под мониторинг или тестовый контур с копией базы быстрее развернуть в облаке: Timeweb Cloud даёт серверы, managed-базы данных, хранилище и Kubernetes с гибким изменением ресурсов, что удобно для проверки влияния изменений на производительность без риска для продакшена.

Пример конфигурации Prometheus и правил алертов

Минимальный prometheus.yml с задачами для системных метрик и PostgreSQL:

global:
scrape_interval: 15s
evaluation_interval: 15s

rule_files:
- /etc/prometheus/rules/*.yml

scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['sed-app-01:9100', 'sed-db-01:9100']
- job_name: 'postgres'
static_configs:
- targets: ['sed-db-01:9187']
params:
collect[]: ['stat_database', 'stat_user_tables', 'locks']

Правила алертов для latency приложения и свободного места на диске:

groups:
- name: sed-latency
rules:
- alert: HighRequestLatency
expr: histogram_quantile(0.95, sum(rate(sed_request_duration_seconds_bucket[5m])) by (le)) > 0.2
for: 5m
labels: {severity: warning}
annotations: {summary: 'p95 отклика СЭД выше 200 мс'}
- alert: LowDiskSpace
expr: node_filesystem_avail_bytes{fstype!='tmpfs'} / node_filesystem_size_bytes{fstype!='tmpfs'} < 0.15
for: 10m
labels: {severity: critical}
annotations: {summary: 'Свободного места меньше 15% на {{ $labels.mountpoint }}'}

Условие for обязательно: без него правило сработает на разовом скачке во время регламентной выгрузки. Для СЭД полезно добавить алерт на рост числа активных соединений с СУБД и на превышение размера очереди заданий, если такие метрики публикует приложение.

Дашборды Grafana для визуализации метрик СЭД

Рабочий дашборд СЭД содержит шесть блоков: график latency с линиями p50, p95 и p99, пропускную способность в RPS, загрузку CPU по режимам, дисковые IOPS и await, использование памяти с учётом page cache, сетевой трафик и ретрансмиты. Для СУБД добавьте панели активных соединений, блокировок, скорости генерации WAL и попаданий в кэш.

Запрос для панели latency приложения:

histogram_quantile(0.95, sum(rate(sed_request_duration_seconds_bucket{service="doc-api"}[$__rate_interval])) by (le))

Дашборды храните в Git вместе с provisioning-файлами Grafana, тогда конфигурация восстанавливается одной командой. Переменные instance и service позволят переключаться между стендами и узлами без копирования панелей. Полезно совместить две методики: RED для сервиса (Rate, Errors, Duration) и USE для ресурсов (Utilization, Saturation, Errors).

Для файлового режима 1С дисковые панели менее информативны из-за кэширования ОС, зато обязательно выводите свободное место на разделе с 1Cv8.1CD и число сеансов, удерживающих файл.

Настройка триггеров в Zabbix: практический пример

Триггер на число активных соединений к PostgreSQL с гистерезисом, чтобы событие не закрывалось сразу после краткого снижения:

{SED DB:pg.stat.activity.count.last()} > 100
{SED DB:pg.stat.activity.count.min(5m)} < 80

Первое выражение описывает проблему, второе задаёт условие восстановления. В настройках action выберите условие по severity (Warning и выше), операцию отправки сообщения в Telegram или Slack через media type и эскалацию: если событие не закрыто за 30 минут, уведомление уходит дежурному инженеру. Перед включением любого триггера прогоните его на исторических данных за две-три недели: Zabbix покажет, сколько раз он сработал бы, и вы сразу увидите шумные правила.

Пошаговая диагностика узких мест в СЭД

Последовательность проверок держите одинаковой, чтобы не пропускать слои:

1. Системные метрики: uptime и load average с поправкой на число ядер, vmstat 1, free -m, iostat -x 1.
2. СУБД: медленные запросы, блокировки, размер и скорость записи WAL, состояние autovacuum.
3. Файловая система: свободное место и inode, ошибки в dmesg, состояние накопителей, режимы монтирования.
4. Сеть: задержки и потери пакетов между сервисами, число TCP-соединений, ретрансмиты.

Общий алгоритм поиска источника деградации с подтверждением причины по метрикам разобран в статье как найти узкое место в системе и повысить производительность без лишних затрат.

Диагностика на уровне базы данных

В PostgreSQL начинайте с расширения pg_stat_statements:

SELECT queryid, calls, round(mean_exec_time::numeric, 2) AS mean_ms,
round(total_exec_time::numeric) AS total_ms
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

Запрос из верхней строки с большим total_exec_time и высоким mean_exec_time - первый кандидат на оптимизацию. Дальше смотрите план: EXPLAIN (ANALYZE, BUFFERS) покажет, где теряется время, читается ли таблица последовательно вместо индекса и сколько страниц берётся из кэша. Блокировки ищите в pg_locks и pg_stat_activity по состоянию wait_event_type = 'Lock'.

В MS SQL Server ту же роль играют Query Store и динамические представления:

SELECT TOP 10 qs.execution_count,
qs.total_worker_time / qs.execution_count AS avg_cpu_time,
SUBSTRING(st.text, 1, 200) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY qs.total_worker_time DESC;

Помните про архитектурную особенность СЭД на базе 1С в клиент-серверном режиме: каждая прикладная операция превращается в цепочку системных вызовов, включая сериализацию, трансляцию в SQL, построение плана и запись журнала. При тысячах мелких транзакций в секунду узким местом становится не отдельный запрос, а накладные расходы на их обработку. Полезные приёмы работы с этой спецификой собраны в руководстве как база данных влияет на производительность автоматизированных систем.

Диагностика файловой системы и дисков

Набор команд для быстрой проверки хранилища: df -h и df -i показывают заполнение места и inode, iostat -x 1 даёт утилизацию и задержки по устройствам, iotop -oPa выводит активные процессы, smartctl -a /dev/nvme0 возвращает атрибуты здоровья накопителя, dmesg -T | tail -50 ловит ошибки ввода-вывода и сбои файловой системы.

Отдельное внимание разделу с базой файлового режима 1С. Проверьте, что он не заполнен больше чем на 80%, что с ним не работают резервное копирование, антивирус и индексатор поиска одновременно, и что файл не удерживается зависшим сеансом. На файловых системах с журналированием оцените режим монтирования: noatime снижает число лишних операций записи.

Накопители с высокой производительностью снимают часть проблем с задержками. Производитель заявляет для Goodram Master на PCIe 5.0 x4 последовательное чтение до 14 000 МБ/с, запись до 13 000 МБ/с и до 2 000 000 IOPS, а также до 27% меньшее энергопотребление по сравнению с отдельными SSD предыдущего поколения. Эти цифры получены в ходе внутреннего тестирования, а не независимых измерений, и относятся к потребительскому сегменту. Быстрый NVMe сократит await, но не исправит отсутствующий индекс или лишние блокировки. Технология Microsoft DirectStorage, которую поддерживает этот класс устройств, ускоряет загрузку данных в играх и в серверных сценариях СЭД не применяется.

Диагностика сетевых задержек

Проверка сети начинается с ping -c 100 -i 0.2 между сервером приложений и СУБД: смотрите не только среднее время, но и разброс, потери и джиттер. Команда mtr -rw показывает маршрут и потери по хопам, ss -s даёт сводку по сокетам, sar -n DEV 1 показывает трафик по интерфейсам, а счётчик ретрансмитов из netstat -s или ss -ti указывает на перегрузку канала.

Для разбора конкретного соединения используйте tcpdump -i eth0 port 5432 с ограничением по времени: длительная запись дампа сама создаёт нагрузку. Целевые значения в локальной сети - меньше 1 мс RTT и джиттер до 0,2 мс, между площадками в пределах 5-10 мс. В клиент-серверном режиме 1С сетевые накладные расходы складываются с RPC-вызовами, поэтому рост RTT на 1-2 мс заметно увеличивает время отклика на операциях с большим числом мелких запросов.

Методы оптимизации производительности СЭД: кэширование, индексация, шардирование

Три метода решают разные задачи и работают на разной глубине: кэш разгружает часто читаемые данные, индексы ускоряют выборки по условиям, шардирование распределяет объём и нагрузку записи. Любой из них применяйте после профилирования, иначе получите усложнение архитектуры без прироста.

Кэширование: когда ускоряет, а когда создаёт проблемы

Redis или Memcached снижают нагрузку на PostgreSQL при повторяющихся запросах: справочники, права доступа, метаданные карточек документов, результаты поиска по частым фильтрам. Ориентир по эффективности - доля попаданий выше 90% для кэшируемых сущностей. При TTL 30-300 секунд для метаданных документов разгрузка СУБД заметна уже при нескольких сотнях запросов в секунду.

Обратная сторона проявляется при частом обновлении документов: кэш устаревает, пользователь видит старую версию, а инвалидация по каждому изменению съедает выигрыш. Схема с версионированием ключей (версия документа в имени ключа) проще в поддержке, чем точечное удаление записей. Данные о статусах согласования и правах доступа кэшировать не стоит: цена ошибки выше экономии. При массовом истечении TTL защищайте БД от одновременных промахов через блокировку на пересчёт и режим stale-while-revalidate.

Индексация: как не навредить

Для таблицы документов типовой рабочий индекс выглядит так:

CREATE INDEX CONCURRENTLY idx_doc_org_created
ON documents (org_id, created_at DESC)
WHERE deleted = false;

Частичный индекс по неотмеченным документам занимает меньше места и быстрее обновляется. Ключевое слово CONCURRENTLY в PostgreSQL позволяет строить индекс без блокировки записи, что критично для продуктивной СЭД.

Каждый дополнительный индекс замедляет вставку и обновление, увеличивает объём WAL и нагрузку на autovacuum. Раз в месяц проверяйте статистику использования: индексы с нулевым idx_scan в pg_stat_user_indexes кандидаты на удаление. В MS SQL Server подсказки по отсутствующим индексам из sys.dm_db_missing_index_details стоит рассматривать как черновик, а не как готовое решение: они предлагают состав ключа без учёта реального профиля нагрузки. Практические настройки памяти, tempdb и индексов для 1С собраны в руководстве оптимизация Microsoft SQL Server для 1С:Предприятие 8.3.

Шардирование: стратегии и ограничения

Три стратегии покрывают большинство задач СЭД: по диапазону (документы группируются по году или месяцу регистрации), по хэшу (равномерное распределение по ключу организации) и по списку (явное закрепление подразделений за узлами). Для архива документов партиционирование по году даёт быстрый эффект: старые партиции не участвуют в горячих запросах, а их обслуживание сводится к переносу на медленный уровень хранения.

Шардирование по организациям или подразделениям требует изменений в приложении: маршрутизация запросов, сбор данных для сводных отчётов, распределённые транзакции и усложнённое резервное копирование. Оценивайте выигрыш по метрикам: если диск и процессор загружены меньше 60%, а время отклика растёт из-за блокировок или планов запросов, горизонтальное разделение не поможет.

Техническое ограничение важно для СЭД на 1С: шардирование возможно только в клиент-серверном режиме с PostgreSQL или MS SQL Server. Файловая база 1Cv8.1CD остаётся единым файлом, её нельзя разделить между узлами, единственный путь - миграция на клиент-серверную архитектуру.

Типичные ошибки при внедрении мониторинга и оптимизации

Собрали ошибки, которые чаще всего обнуляют результат работы.

• Слишком чувствительные алерты. Порог без временного окна даёт десятки уведомлений в день, и команда перестаёт реагировать. Ограничьте правила перцентилями, параметром for и разделением severity.
• Оптимизация без профилирования. Изменения конфигурации до снятия замеров не позволяют доказать эффект. Фиксируйте базовые значения latency и IOPS, затем сравнивайте.
• Избыточная индексация. Десяток индексов на таблице документов замедляет запись и раздувает WAL. Ревизия idx_scan покажет лишние.
• Анализ только средних значений. Без p95 и p99 деградация на части запросов остаётся незамеченной до жалоб пользователей.
• Отсутствие нагрузочного стенда. Проверка на копии базы с реалистичным профилем операций выявляет проблемы до продакшена.
• Нет контроля свободного места и inode. Заполнение раздела с журналами или базой останавливает СЭД быстрее любой ошибки в коде.
• Недооценка fsync. Синхронный сброс журнала добавляет задержку на каждый commit: учитывайте это при планировании нагрузки и проверяйте состояние батареи кэша контроллера.

Разбор шумных правил, высокой кардинальности меток и разрыва между логами и трассировками с практическим чек-листом приведён в статье типовые ошибки при разработке систем мониторинга. Для разбора больших объёмов логов и корреляции событий часть команд подключает языковые модели через единый API: AiTunnel агрегирует доступ более чем к 200 моделям с OpenAI-совместимым интерфейсом и оплатой в рублях.

Заключение: чек-лист для поддержания производительности СЭД

Регулярность важнее разовых кампаний по ускорению. Готовый набор действий по периодам:

• Ежедневно: просмотр активных алертов, дашборд latency, свободное место на разделах с базой и журналами, длина очереди заданий.
• Еженедельно: топ-20 медленных запросов, ожидания блокировок, состояние autovacuum, ошибки в логах приложения и СУБД.
• Ежемесячно: ревизия неиспользуемых индексов, оценка роста объёма документов, проверка плана партиционирования, состояние накопителей по SMART.
• Ежеквартально: нагрузочное тестирование на стенде, аудит порогов алертов, проверка процедуры восстановления из резервной копии, обновление версий СУБД и приложения.

Начните с одного шага: включите сбор p95 времени отклика и дисковых задержек, поставьте алерты на свободное место и рост блокировок. Через неделю данных у вас появится объективная картина, и решения по кэшу, индексам или шардированию будут опираться на измерения, а не на предположения.