Мониторинг производительности и доступности СУБД МИС/ЭМК: настройка и пороги срабатывания

Почему стандартные пороги мониторинга не подходят для медицинских систем

Медицинские информационные системы (МИС) и системы электронных медицинских карт (ЭМК) генерируют нагрузку, кардинально отличающуюся от типовых веб-приложений. Утренняя массовая запись к врачам создает лавинообразный рост запросов: за первые 15 минут работы регистратуры количество транзакций может увеличиться в 5-10 раз относительно среднечасового значения. Загрузка результатов МРТ и КТ в часы работы диагностических служб порождает пиковые вставки бинарных объектов размером от 200 до 800 МБ каждый.

Стандартный порог «время ответа > 1 секунда» будет постоянно срабатывать в такие периоды, вызывая alert fatigue - состояние, при котором администратор перестает реагировать на оповещения из-за их избыточности. Пропуск реального инцидента среди сотен ложных срабатываний - прямой путь к деградации системы, которую первыми заметят врачи, а не инженеры.

Адаптация порогов под бизнес-ритм медицинской организации - не рекомендация, а обязательное требование. Часы пик предсказуемы: 7:30-10:00 для записи, 11:00-15:00 для диагностических загрузок, 16:00-18:00 для выгрузки отчетов. Мониторинг должен учитывать это расписание. Если ваша система уже развернута на облачной инфраструктуре, например, Timeweb Cloud, вы можете гибко масштабировать ресурсы под пиковые интервалы, но алерты все равно должны быть настроены с поправкой на предсказуемые всплески.

Ключевые метрики СУБД для МИС и ЭМК: что мониторить в первую очередь

Четыре группы метрик закрывают 90% инцидентов, связанных с производительностью баз данных медицинских систем. Каждая метрика напрямую влияет на скорость работы врачей с картами пациентов, загрузку результатов обследований и формирование отчетности.

Время выполнения запросов: среднее, максимальное и перцентили

Среднее время выполнения запроса - обманчивая метрика. Представьте: 99% запросов открытия карты пациента выполняются за 50 мс, а 1% - за 12 секунд. Среднее арифметическое покажет около 170 мс, и график будет выглядеть приемлемо. Но именно эти 12-секундные запросы видит врач, пытаясь открыть карту сложного пациента с длительной историей болезни.

Мониторинг перцентилей p95 и p99 выявляет «длинный хвост» медленных запросов. p95 = 500 мс означает, что 5% запросов выполняются дольше полусекунды. Для врача, открывающего 50 карт за смену, это 2-3 ощутимые задержки. p99 показывает худшие случаи, которые разрушают пользовательский опыт.

Практическая рекомендация: включите модуль pg_stat_statements для PostgreSQL или Performance Schema для MySQL. Снимайте метрики с разбивкой по типам запросов: открытие карты, сохранение осмотра, загрузка результатов, формирование отчета. Разные сценарии имеют разные допустимые пороги.

Пул соединений: мониторинг утилизации и очередей

Исчерпание пула соединений приводит к отказам в обслуживании - врач просто не может войти в систему. Типичная конфигурация для МИС: PgBouncer в режиме transaction pooling перед PostgreSQL, с лимитом в 200-500 соединений в зависимости от количества одновременно работающих пользователей.

Ключевые метрики пула:

• active - соединения, выполняющие запрос прямо сейчас
• idle - открытые, но неактивные соединения
• waiting - запросы в очереди на получение соединения

Рост waiting - самый тревожный сигнал. Даже если active не достиг максимума, появление очереди означает, что пул не справляется с темпом поступления запросов. При настройке алертов учитывайте, что пиковое количество одновременных пользователей МИС обычно приходится на 9:00-10:30 утра.

Журналы транзакций: скорость наполнения и задержки сброса

Загрузка 1000 снимков МРТ генерирует большой объем WAL (Write-Ahead Log) в PostgreSQL или transaction log в MySQL. Скорость генерации WAL может достигать 100-200 МБ/с при массовых вставках, и если диск не справляется с записью, СУБД замедляет все операции.

Метрики для отслеживания:

• Скорость генерации WAL (МБ/с) - показывает интенсивность записи
• Задержки fsync - время, затрачиваемое на сброс данных на диск
• Объем накопленного, но не заархивированного WAL - риск заполнения диска

Заполнение диска с WAL - аварийная ситуация: СУБД останавливается. Алерт должен срабатывать задолго до критического уровня, с прогнозированием времени до заполнения на основе текущей скорости роста.

Дисковые задержки: iowait и latency на уровне СУБД

Мониторинг дисковой подсистемы требует двух уровней: операционная система и сама СУБД. На уровне ОС отслеживайте iowait - процент времени, которое CPU проводит в ожидании завершения операций ввода-вывода. Значение выше 10% в течение 5 минут указывает на дисковое узкое место.

На уровне СУБД pg_stat_statements показывает read/write latency для конкретных запросов. Это позволяет сопоставить всплеск iowait с конкретной операцией: например, массовое чтение бинарных файлов из таблицы результатов обследований. Без этой корреляции вы знаете, что диск тормозит, но не знаете, какой именно процесс вызывает проблему.

Для медицинских систем критично раздельное хранение данных: индексы и WAL на быстрых SSD (NVMe), бинарные файлы обследований - на емких дисках. Мониторинг дисковой latency должен учитывать это разделение и алертить отдельно по каждому тому.

Пороги срабатывания алертов: от теории к практике

Приведенные ниже пороги - результат анализа нагрузок реальных МИС с количеством одновременных пользователей от 50 до 500. Корректируйте значения под свой профиль нагрузки, но сохраняйте градацию Warning/Critical и учет временных интервалов.

Динамические пороги: учет расписания пиковых нагрузок

В Zabbix динамические пороги реализуются через гибкие интервалы и макросы. Создайте два шаблона триггеров: один для обычного времени, второй для часов пик. Макрос {$PEAK_HOURS} определяет временной диапазон, а триггер выбирает соответствующий порог.

В Prometheus используйте условия по времени в правилах алертов. Функция hour() возвращает текущий час в UTC, и вы можете задать разные пороги для разных интервалов. Пример правила, которое применяет порог 2 секунды для p95 в часы пик и 500 мс в остальное время, приведен в разделе конфигураций.

Определение часов пик - не гадание. Соберите исторические данные за 2-4 недели, постройте график количества активных соединений по часам. Пики будут очевидны. Для большинства медицинских организаций характерна описанная выше картина, но в стационарах с круглосуточным режимом работы пики могут быть сглажены.

Алерты на основе трендов: прогнозирование проблем

Реактивный алерт сообщает о проблеме, которая уже произошла. Проактивный - предсказывает ее за 30-60 минут до наступления. PromQL предоставляет функции derivative() и predict_linear() для работы с трендами.

Пример: скорость роста WAL-директории составляет 80 МБ/с, свободно 50 ГБ. Линейная экстраполяция показывает, что место закончится через 10 минут. Алерт должен сработать, когда прогнозируемое время до заполнения меньше 2 часов. Это дает запас на реакцию: подключить дополнительный диск, запустить архивацию или ограничить загрузку данных.

Аналогичный подход применяется к росту пула соединений: если за последний час количество активных соединений выросло на 40%, а текущая утилизация 60%, прогноз показывает достижение 90% через 45 минут. Алерт на тренд сработает раньше, чем алерт на абсолютное значение.

Настройка оповещений в Zabbix, Prometheus и собственных скриптах

Пример конфигурации для Zabbix: шаблон СУБД МИС

Zabbix-шаблон для мониторинга СУБД МИС должен включать элементы данных, собираемые через внешние скрипты или агент. Ключевые элементы:

• db.pool.utilization - процент утилизации пула от максимума
• db.query.p95 - 95-й перцентиль времени выполнения за 5 минут
• db.query.p99 - 99-й перцентиль времени выполнения за 5 минут
• db.wal.growth_rate - скорость роста WAL в МБ/с
• db.connections.waiting - количество запросов в очереди

Триггер для динамического порога времени запроса:

{
  "trigger": "db.query.p95",
  "expression": "{Template DB MIS:db.query.p95.last()}>{$P95_WARNING}",
  "dependencies": [],
  "priority": "WARNING",
  "flexible_intervals": [
    {"time": "7:30-10:00", "macro": "{$P95_WARNING}", "value": "2000"},
    {"time": "11:00-15:00", "macro": "{$P95_WARNING}", "value": "2000"},
    {"time": "default", "macro": "{$P95_WARNING}", "value": "500"}
  ]
}

Настройка уведомлений - через действия (Actions) в Zabbix. Рекомендуется эскалация: сначала Telegram/почта дежурному администратору, при отсутствии реакции в течение 15 минут - звонок или SMS. Для интеграции с внешними сервисами используйте webhook-уведомления.

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

Сбор метрик PostgreSQL - через postgres_exporter. Он отдает метрики pg_stat_statements, информацию о соединениях, репликации и WAL. Правила алертов описываются в YAML и загружаются в Prometheus.

Алерт на время выполнения запросов с динамическим порогом:

groups:
  - name: mis_db_alerts
    rules:
      - alert: HighQueryLatency
        expr: |
          (
            histogram_quantile(0.95, rate(pg_stat_statements_seconds_bucket[5m])) > 0.5
            and hour() < 7
          ) or (
            histogram_quantile(0.95, rate(pg_stat_statements_seconds_bucket[5m])) > 0.5
            and hour() > 18
          ) or (
            histogram_quantile(0.95, rate(pg_stat_statements_seconds_bucket[5m])) > 2.0
            and hour() >= 7
            and hour() <= 10
          ) or (
            histogram_quantile(0.95, rate(pg_stat_statements_seconds_bucket[5m])) > 2.0
            and hour() >= 11
            and hour() <= 15
          )
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "p95 latency превышает порог"
          description: "Текущее значение: {{ $value }}с"

      - alert: ConnectionPoolUtilization
        expr: pg_stat_database_numbackends / pg_settings_max_connections * 100 > 70
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Утилизация пула соединений > 70%"

      - alert: WALGrowthRate
        expr: rate(pg_stat_bgwriter_buffers_clean[5m]) * 8192 / 1024 / 1024 > 50
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Скорость роста WAL > 50 МБ/с"

      - alert: DiskFillPrediction
        expr: predict_linear(pg_stat_database_blks_hit[1h], 7200) < 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Прогнозируется заполнение диска через 2 часа"

Alertmanager маршрутизирует алерты по каналам: критические - в Telegram и на телефон, warning - в почту и корпоративный мессенджер. Настройте группировку по меткам, чтобы избежать дублирования при массовых срабатываниях.

Собственный скрипт мониторинга: быстрый старт

Для небольших инсталляций, где развертывание Zabbix или Prometheus избыточно, работает связка bash-скрипта и cron. Скрипт подключается к СУБД, собирает ключевые метрики и отправляет алерт при превышении порогов.

#!/bin/bash
# Простой мониторинг СУБД МИС
# Запуск: */5 * * * * /usr/local/bin/db_monitor.sh

DB_HOST="localhost"
DB_USER="monitor"
DB_NAME="mis"
WEBHOOK_URL="https://your-webhook-url"

# Пороги
MAX_CONNECTIONS_PCT=70
MAX_QUERY_TIME_MS=500
MAX_WAL_GROWTH_MB=50

# Проверка утилизации пула соединений
CONNECTIONS=$(psql -h $DB_HOST -U $DB_USER -d $DB_NAME -t -c \
  "SELECT count(*) FROM pg_stat_activity;")
MAX_CONN=$(psql -h $DB_HOST -U $DB_USER -d $DB_NAME -t -c \
  "SELECT setting FROM pg_settings WHERE name='max_connections';")
UTILIZATION=$(( CONNECTIONS * 100 / MAX_CONN ))

if [ $UTILIZATION -gt $MAX_CONNECTIONS_PCT ]; then
  curl -X POST $WEBHOOK_URL \
    -H "Content-Type: application/json" \
    -d "{\"alert\": \"Connection pool utilization: ${UTILIZATION}%\"}"
fi

# Проверка медленных запросов (p95 за последние 5 минут)
SLOW_QUERIES=$(psql -h $DB_HOST -U $DB_USER -d $DB_NAME -t -c \
  "SELECT count(*) FROM pg_stat_activity \
   WHERE state='active' \
   AND now() - query_start > interval '${MAX_QUERY_TIME_MS} milliseconds';")

if [ $SLOW_QUERIES -gt 0 ]; then
  curl -X POST $WEBHOOK_URL \
    -H "Content-Type: application/json" \
    -d "{\"alert\": \"Active slow queries: ${SLOW_QUERIES}\"}"
fi

echo "$(date): Monitor check completed. Connections: ${UTILIZATION}%, Slow queries: ${SLOW_QUERIES}"

Скрипт покрывает базовые метрики и запускается каждые 5 минут. Для продакшн-среды расширьте его проверкой WAL, дисковой latency через iostat и добавьте логирование в файл для последующего анализа трендов.

Предотвращение деградации: проактивный мониторинг и анализ трендов

Реактивный мониторинг фиксирует факт: «p95 latency превысил 500 мс». Проактивный выявляет паттерн: «p95 latency рос на 10% в неделю последние три недели, через две недели достигнет критического порога». Второй подход дает время на плановую оптимизацию без авралов.

Методика еженедельного анализа:

• Соберите топ-10 медленных запросов из pg_stat_statements за неделю
• Сравните планы выполнения с предыдущей неделей - изменение плана часто указывает на проблему с индексами или статистикой
• Отследите рост размера таблиц и индексов - линейный рост нормален, экспоненциальный требует внимания
• Проверьте количество последовательных сканирований (seq scan) - резкий рост означает, что индекс перестал использоваться

Алерты на аномалии в трендах настраиваются через те же инструменты. PromQL-выражение для обнаружения роста последовательных сканирований на 50% за час:

rate(pg_stat_user_tables_seq_scan[1h]) / rate(pg_stat_user_tables_seq_scan[1h] offset 1h) > 1.5

Такие алерты не требуют немедленной реакции, но должны попадать в еженедельный отчет и разбираться планово.

Дашборд для визуализации здоровья СУБД

Информативная панель в Grafana позволяет за 10 секунд оценить состояние СУБД. Структура дашборда для МИС:

• Верхний ряд (общая картина): p50/p95/p99 latency на одном графике, утилизация пула соединений, скорость WAL, дисковая latency чтения/записи
• Средний ряд (детализация): топ-5 медленных запросов за последний час, количество активных/idle/waiting соединений, объем WAL-файлов
• Нижний ряд (тренды): недельный график роста БД, суточный профиль нагрузки, прогноз заполнения диска

Используйте PostgreSQL datasource в Grafana для прямых запросов к системным представлениям. Это дает гибкость в построении специфичных для МИС панелей, например, «количество открытых карт пациентов в час» или «объем загруженных результатов обследований за смену». Готовый пример интеграции медицинских метрик в Grafana с подключением Prometheus и Elasticsearch разобран в руководстве по созданию единого дашборда мониторинга медицинских систем.

Особенности мониторинга под нагрузкой: кейсы из практики

Кейс 1: Массовая запись к врачам. В поликлинике на 300 врачей утренняя запись начинается в 7:30. За первые 10 минут регистратура создает около 2000 записей на прием. Стандартный алерт на p95 > 500 мс срабатывал каждое утро, и администраторы игнорировали его. После внедрения динамических порогов (2 секунды для интервала 7:30-10:00) ложные срабатывания прекратились. Реальный инцидент - p95 вырос до 4 секунд в 9:15 - был зафиксирован и отработан: выяснилось, что ночная перестройка индекса не завершилась из-за блокировки. Без динамических порогов этот алерт затерялся бы среди десятка ложных.

Кейс 2: Загрузка результатов МРТ. Диагностический центр загружает в МИС до 500 исследований в час, каждое - серия DICOM-файлов общим объемом 300-600 МБ. Мониторинг скорости генерации WAL показал устойчивые 80 МБ/с в часы загрузки. Алерт на прогноз заполнения диска (predict_linear) сработал за 3 часа до критического момента: свободное место на WAL-разделе заканчивалось быстрее обычного из-за сбоя архивации. Администратор успел запустить ручную архивацию и предотвратил остановку СУБД.

Кейс 3: Медленная выгрузка отчетов. Главный врач пожаловался, что месячный отчет формируется 40 минут вместо обычных 5. Среднее время запросов было в норме - основная масса транзакций шла быстро. Анализ p99 выявил проблемный запрос: он выполнялся 35 минут из-за изменения плана выполнения после обновления статистики. Оптимизация индекса сократила время до 3 минут. Без мониторинга перцентилей проблема осталась бы незамеченной до жалобы пользователя.

Мониторинг виртуальных машин, на которых работают СУБД МИС, требует отдельного внимания к ресурсам гипервизора. Детальные пороги для vCPU Ready, дисковой latency на уровне VM и настройка алертов для VMware, Hyper-V и Proxmox описаны в руководстве по мониторингу ВМ с медицинским ПО.

Заключение: чек-лист внедрения мониторинга СУБД МИС/ЭМК

Внедрение мониторинга по этому руководству занимает от одного до трех рабочих дней в зависимости от размера инфраструктуры. Порядок действий:

1. Определите часы пиковой нагрузки. Соберите данные за 2-4 недели, постройте почасовой профиль активных соединений и объема транзакций.
2. Включите сбор метрик. Активируйте pg_stat_statements (PostgreSQL) или Performance Schema (MySQL), настройте postgres_exporter или mysqld_exporter.
3. Настройте базовые алерты. Используйте пороги из таблицы выше, адаптируйте под свои пиковые интервалы.
4. Создайте дашборд. Минимальный набор: latency (p50/p95/p99), соединения, WAL, дисковая latency. Добавьте топ медленных запросов.
5. Проведите тестовый прогон. Сымитируйте пиковую нагрузку (массовая запись, загрузка результатов) и проверьте, что алерты срабатывают адекватно. Скорректируйте пороги.
6. Настройте еженедельный отчет. Автоматизируйте выгрузку топ-10 медленных запросов, графиков роста БД и аномалий планов выполнения.

Система мониторинга - не статичная настройка. Пересматривайте пороги раз в квартал с учетом роста нагрузки и изменений в бизнес-процессах медорганизации. Принципы построения отказоустойчивого мониторинга для высоконагруженных систем, включая настройку алертов в Prometheus и Grafana, детально разобраны в руководстве по наблюдаемости для высоконагруженных систем.