Настройка мониторинга Moodle с Prometheus и Grafana: пошаговое руководство 2026 | AdminWiki

Настройка мониторинга Moodle с Prometheus и Grafana: пошаговое руководство 2026

23 июля 2026 9 мин. чтения

Зачем нужен мониторинг Moodle и почему Prometheus + Grafana

Moodle работает на стеке PHP-FPM, MySQL/MariaDB и Nginx. Каждый из этих компонентов может стать узким местом. Медленные SQL-запросы, переполнение пула PHP-процессов, всплеск 5xx ошибок Nginx - эти проблемы приводят к деградации образовательного процесса. Без мониторинга вы узнаете о сбое от пользователей.

Связка Prometheus и Grafana решает эту задачу. Prometheus собирает и хранит временные ряды метрик, опрашивая экспортеры по HTTP. Grafana визуализирует данные через дашборды. Этот стек стал стандартом инфраструктурного мониторинга по трём причинам: гибкая модель pull-сбора метрик, сотни готовых экспортеров под любое ПО, мощный язык PromQL для запросов и алертинга. Вы получаете единую панель для контроля PHP-FPM, MySQL, Nginx и серверных ресурсов.

Если вы только начинаете разворачивать мониторинг с нуля, изучите полное руководство по настройке стека Prometheus и Grafana. В нём разобрана базовая установка, настройка node_exporter и алертинг в Telegram.

Архитектура мониторинга: какие метрики собираем и как

Поток данных выглядит так: каждый компонент Moodle отдаёт метрики через свой экспортер, Prometheus опрашивает экспортеры по расписанию, Grafana забирает агрегированные данные из Prometheus для отображения на дашбордах. Все компоненты работают независимо - их можно разнести по разным хостам или упаковать в Docker-контейнеры.

Компоненты мониторинга: Prometheus, экспортеры, Grafana

Prometheus - time-series база данных и система опроса. Он хранит метрики в собственной БД на диске, выполняет правила алертинга и отвечает на запросы Grafana. Не требует внешней базы данных. Конфигурация задаётся в одном YAML-файле.

Экспортеры - агенты, которые преобразуют внутренние метрики сервиса в формат Prometheus. Каждый экспортер отдаёт HTTP-эндпоинт /metrics с plain-text данными. Для Moodle нам нужны три экспортера: php-fpm_exporter для PHP-FPM, mysqld_exporter для MySQL/MariaDB, nginx-prometheus-exporter для Nginx.

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

Ключевые метрики, которые мы будем собирать:

  • PHP-FPM: активные процессы, время ответа, очередь запросов, использование памяти
  • MySQL/MariaDB: количество запросов в секунду, медленные запросы, блокировки, использование буферного пула InnoDB
  • Nginx: количество запросов, коды ответов 4xx/5xx, активные соединения

Подготовка сервера Moodle к мониторингу

Экспортеры не собирают метрики из воздуха. Каждый сервис должен отдавать внутреннюю статистику через статус-страницу или сокет. Настроим это для PHP-FPM, MySQL и Nginx.

Настройка PHP-FPM exporter для мониторинга пула процессов

Включаем статус-страницу PHP-FPM. Откройте конфигурацию пула (обычно /etc/php/8.3/fpm/pool.d/www.conf) и добавьте или раскомментируйте директиву:

pm.status_path = /status

Убедитесь, что пул слушает TCP-порт или Unix-сокет. Для TCP найдите директиву listen:

listen = 127.0.0.1:9000

Перезапустите PHP-FPM:

systemctl restart php8.3-fpm

Проверьте доступность статус-страницы через curl:

curl http://127.0.0.1:9000/status

Теперь установите php-fpm_exporter. Скачайте актуальный релиз с GitHub и создайте systemd-юнит:

[Unit]
Description=PHP-FPM Exporter
After=network.target

[Service]
User=nobody
ExecStart=/usr/local/bin/php-fpm_exporter \
  --phpfpm.scrape-uri=http://127.0.0.1:9000/status
Restart=always

[Install]
WantedBy=multi-user.target

Запустите экспортер:

systemctl daemon-reload
systemctl enable --now php-fpm_exporter

Метрики доступны на порту 9253:

curl http://127.0.0.1:9253/metrics

Настройка MySQL/MariaDB exporter для мониторинга базы данных

Создайте пользователя для экспортера в MySQL:

CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'strong_password';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
FLUSH PRIVILEGES;

Создайте файл /etc/mysqld_exporter.cnf с учётными данными:

[client]
user=exporter
password=strong_password
host=localhost

Установите mysqld_exporter и настройте systemd-юнит:

[Unit]
Description=MySQL Exporter
After=network.target

[Service]
User=nobody
ExecStart=/usr/local/bin/mysqld_exporter \
  --config.my-cnf=/etc/mysqld_exporter.cnf
Restart=always

[Install]
WantedBy=multi-user.target

Запустите и проверьте метрики на порту 9104:

systemctl enable --now mysqld_exporter
curl http://127.0.0.1:9104/metrics | head -20

Настройка Nginx exporter для мониторинга веб-сервера

Включите stub_status в конфигурации Nginx. Добавьте location-блок в server-секцию:

server {
    listen 127.0.0.1:80;
    server_name localhost;

    location /nginx_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }
}

Проверьте конфигурацию и перезагрузите Nginx:

nginx -t && systemctl reload nginx
curl http://127.0.0.1/nginx_status

Установите nginx-prometheus-exporter. Systemd-юнит:

[Unit]
Description=Nginx Prometheus Exporter
After=network.target

[Service]
User=nobody
ExecStart=/usr/local/bin/nginx-prometheus-exporter \
  -nginx.scrape-uri=http://127.0.0.1/nginx_status
Restart=always

[Install]
WantedBy=multi-user.target

Метрики доступны на порту 9113:

systemctl enable --now nginx-prometheus-exporter
curl http://127.0.0.1:9113/metrics | grep nginx_

Для углублённого анализа логов Nginx и настройки алертинга на ошибки 502/504 используйте готовые конфигурации из руководства по мониторингу Nginx.

Установка и конфигурация Prometheus

Установите Prometheus через пакетный менеджер или Docker. Для Debian/Ubuntu:

apt update && apt install prometheus -y

Основной конфигурационный файл - /etc/prometheus/prometheus.yml. В секции global задаются параметры опроса по умолчанию:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_interval определяет, как часто Prometheus опрашивает экспортеры. Значение 15 секунд - баланс между детализацией данных и нагрузкой на диск. evaluation_interval задаёт периодичность проверки правил алертинга.

Базовая конфигурация prometheus.yml для Moodle

Добавьте три job'а в секцию scrape_configs:

scrape_configs:
  - job_name: 'php-fpm'
    static_configs:
      - targets: ['localhost:9253']
        labels:
          service: 'moodle-php-fpm'

  - job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']
        labels:
          service: 'moodle-mysql'

  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']
        labels:
          service: 'moodle-nginx'

Метки (labels) помогают фильтровать метрики в PromQL-запросах и группировать их на дашбордах. После изменения конфигурации перезапустите Prometheus:

systemctl restart prometheus

Откройте веб-интерфейс Prometheus по адресу http://your-server:9090. Перейдите в Status → Targets. Все три эндпоинта должны быть в состоянии UP. Если target красный - проверьте сетевую доступность порта и логи Prometheus.

Если вы планируете мониторить кластерную инфраструктуру, посмотрите руководство по мониторингу кластеров. Там разобраны специфичные дашборды для Pacemaker и Ceph.

Установка Grafana и импорт дашбордов для Moodle

Установите Grafana:

apt install -y software-properties-common wget
wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key
echo "deb [signed-by=/usr/share/keyrings/grafana.key] https://apt.grafana.com stable main" | tee /etc/apt/sources.list.d/grafana.list
apt update && apt install grafana -y
systemctl enable --now grafana-server

Grafana слушает порт 3000. Откройте http://your-server:3000, войдите с admin/admin и задайте новый пароль.

Добавьте Prometheus как источник данных: Connections → Data Sources → Add data source → Prometheus. В поле URL укажите http://localhost:9090. Нажмите Save & Test. При успешном подключении появится зелёная галочка.

Импорт готовых дашбордов: PHP-FPM, MySQL, Nginx

Grafana.com содержит тысячи готовых дашбордов. Для импорта перейдите в Dashboards → New → Import. Вставьте ID дашборда и нажмите Load. Выберите созданный ранее Prometheus data source и нажмите Import.

Рекомендованные дашборды для стека Moodle:

  • PHP-FPM: ID 3901 - показывает активные процессы, очередь, использование памяти, время ответа
  • MySQL Overview: ID 7362 - запросы в секунду, медленные запросы, блокировки, буферный пул InnoDB
  • NGINX: ID 12708 - RPS, коды ответов 2xx/3xx/4xx/5xx, активные соединения

После импорта проверьте, что графики отображают данные. Если панели пустые - убедитесь, что job_name в запросах PromQL совпадает с тем, что вы задали в prometheus.yml.

Создание сводного дашборда для мониторинга Moodle

Импортированные дашборды удобны по отдельности, но для оперативного контроля нужен единый экран. Создайте новый дашборд: Dashboards → New → New Dashboard → Add Visualization.

Минимальный набор панелей для сводного дашборда Moodle:

  • Активные процессы PHP-FPM - метрика php_fpm_processes_active. Порог: 80% от pm.max_children
  • Запросы MySQL в секунду - rate(mysql_global_status_queries[1m]). Показывает реальную нагрузку на БД
  • Ошибки Nginx 4xx и 5xx - rate(nginx_http_requests_total{status=~"^[45]"}[1m]). Мгновенная индикация проблем с доступностью Moodle
  • Время ответа PHP-FPM - histogram_quantile(0.95, rate(php_fpm_request_duration_seconds_bucket[5m])). 95-й перцентиль времени обработки запросов

Каждую панель можно скопировать из импортированных дашбордов через меню Share → Embed и адаптировать PromQL-запрос под свои метки.

Для оценки эффективности мониторинга после внедрения используйте метрики из руководства по оценке инфраструктурных проектов. Это поможет понять, насколько мониторинг снизил время обнаружения инцидентов.

Настройка алертинга в Prometheus для критических событий Moodle

Алертинг в Prometheus работает по цепочке: правила алертинга → генерация алертов → Alertmanager → маршрутизация → уведомление. Правила описываются в YAML-файле и ссылаются на PromQL-выражения. Alertmanager принимает алерты, группирует их и отправляет получателям.

Правила алертинга: PHP-FPM, Nginx, MySQL, cron

Создайте файл /etc/prometheus/rules/moodle_alerts.yml и подключите его в prometheus.yml:

rule_files:
  - "rules/moodle_alerts.yml"

Содержимое файла с правилами:

groups:
  - name: moodle_alerts
    rules:
      - alert: PHPFPMHighProcesses
        expr: php_fpm_processes_active / php_fpm_max_children > 0.8
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "PHP-FPM pool заполнен на 80%"
          description: "Активных процессов: {{ $value | humanizePercentage }}. Возможна очередь запросов."

      - alert: NginxHigh5xxRate
        expr: rate(nginx_http_requests_total{status=~"^5"}[5m]) > 0.1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Высокий уровень 5xx ошибок Nginx"
          description: "Количество 5xx ошибок: {{ $value }} в секунду за последние 5 минут."

      - alert: MySQLSlowQueries
        expr: rate(mysql_global_status_slow_queries[10m]) > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Обнаружены медленные запросы MySQL"
          description: "Медленных запросов в секунду: {{ $value }}. Проверьте таблицы Moodle на отсутствие индексов."

      - alert: MoodleCronFailure
        expr: time() - moodle_last_cron_run > 600
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Cron Moodle не выполнялся более 10 минут"
          description: "Последний запуск cron был {{ $value }} секунд назад. Задачи очистки сессий и рассылки уведомлений могут быть остановлены."

Директива for задаёт время, в течение которого условие должно выполняться до отправки алерта. Это фильтрует кратковременные всплески. Для метрики moodle_last_cron_run потребуется дополнительный экспортер или кастомный скрипт, который записывает время последнего успешного выполнения cron в текстовый файл и отдаёт его через node_exporter textfile collector.

Интеграция с Alertmanager и настройка уведомлений

Установите Alertmanager:

apt install alertmanager -y

Отредактируйте /etc/alertmanager/alertmanager.yml. Пример конфигурации с отправкой в Telegram:

route:
  receiver: 'telegram'
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h

receivers:
  - name: 'telegram'
    telegram_configs:
      - bot_token: 'YOUR_BOT_TOKEN'
        chat_id: YOUR_CHAT_ID
        parse_mode: 'HTML'
        message: '{{ range .Alerts }}{{ .Annotations.summary }}
{{ .Annotations.description }}
{{ end }}'

В конфигурации Prometheus укажите адрес Alertmanager в секции alerting:

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

Перезапустите оба сервиса. Для проверки временно измените порог в правиле на заведомо срабатывающий и дождитесь уведомления в Telegram.

Типичные проблемы и их решение

Экспортер не отдаёт метрики. Проверьте, что сервис запущен: systemctl status php-fpm_exporter. Проверьте доступность порта: ss -tlnp | grep 9253. Убедитесь, что статус-страница PHP-FPM доступна: curl http://127.0.0.1:9000/status. Частая причина - pm.status_path не настроен или пул слушает Unix-сокет, а экспортер стучится на TCP.

Prometheus не видит targets. В веб-интерфейсе Prometheus перейдите в Status → Targets. Состояние DOWN с ошибкой "connection refused" - экспортер не запущен или слушает другой порт. Ошибка "context deadline exceeded" - firewall блокирует порт. Проверьте iptables: iptables -L -n | grep PORT.

Дашборд Grafana пустой. Откройте панель в режиме редактирования и проверьте PromQL-запрос. Убедитесь, что метки в запросе совпадают с теми, что заданы в prometheus.yml. Проверьте data source - он должен указывать на правильный URL Prometheus и проходить тест соединения. Включите временной диапазон дашборда, соответствующий периоду сбора метрик.

Алерты не приходят. Проверьте вкладку Alerts в Prometheus - алерт должен быть в состоянии FIRING. Если состояние PENDING, условие выполняется меньше времени, заданного в for. Проверьте логи Alertmanager: journalctl -u alertmanager -f. Убедитесь, что bot_token и chat_id Telegram корректны.

Заключение: дальнейшие шаги по улучшению мониторинга

Вы развернули базовый мониторинг Moodle: метрики PHP-FPM, MySQL и Nginx поступают в Prometheus, Grafana отображает их на дашбордах, Alertmanager отправляет уведомления о критических событиях. Эта система даёт видимость состояния образовательной платформы в реальном времени.

Следующие шаги для усиления мониторинга:

  • Добавьте node_exporter для мониторинга CPU, памяти, дисков и сети сервера. Это закроет уровень инфраструктуры.
  • Настройте сбор логов Moodle и Nginx через Loki с интеграцией в Grafana. Единый интерфейс для метрик и логов ускоряет расследование инцидентов.
  • Внедрите мониторинг крон-задач Moodle через кастомный экспортер или textfile collector node_exporter. Сбои cron критичны для работы платформы.
  • Настройте дашборды для бизнес-метрик: количество активных пользователей, завершённых курсов, отправленных заданий. Эти данные можно получать из API Moodle и экспортировать в Prometheus.

Если вы сравниваете подходы к мониторингу или хотите расширить стек, изучите обзор систем мониторинга 2026 года. Там разобраны CLI-утилиты для срочной диагностики и продвинутые сценарии Prometheus/Grafana.

Для размещения инфраструктуры мониторинга и самого Moodle рассмотрите облачные серверы Timeweb Cloud. Они предоставляют VDS/VPS с гибким масштабированием ресурсов и управляемые базы данных, что упрощает развёртывание production-окружения.

Поделиться:
Сохранить гайд? В закладки браузера