Мониторинг инфраструктуры Open edX 2026: полный стек для стабильной работы платформы | AdminWiki
Logo

Мониторинг инфраструктуры Open edX 2026: полный стек для стабильной работы платформы

23 июля 2026 10 мин. чтения
Содержание статьи

Платформа Open edX состоит из десятков взаимосвязанных сервисов: LMS и CMS обрабатывают пользовательские запросы, Celery выполняет фоновые задачи, MySQL и MongoDB хранят данные, RabbitMQ передает сообщения между компонентами. Отказ одного элемента вызывает каскадный сбой всей системы. Мониторинг превращает хаос микросервисов в контролируемую среду, где администратор видит состояние каждого узла до того, как проблема затронет студентов.

Эта статья дает готовую схему развертывания мониторинга для кастомных инсталляций Open edX. Вы получите конкретные конфигурации для сбора метрик с LMS, CMS, XQueue, баз данных и брокера сообщений, сравните два промышленных стека - Telegraf + InfluxDB + Chronograf и Prometheus + Grafana - и настроите алерты, которые предупредят о деградации за 5 минут до инцидента.

Если вы проектируете систему наблюдения с нуля, начните с обзора архитектуры мониторинга EdTech-инфраструктуры, где разобраны ключевые метрики доступности и нагрузки. Для тех, кто работает с контейнеризованными средами, пригодится руководство по наблюдаемости высоконагруженных систем с готовыми шаблонами дашбордов Grafana.

Зачем нужен мониторинг Open edX: ключевые метрики стабильности

Типичный инцидент на неподготовленной инсталляции выглядит так: студенты жалуются на долгую загрузку тестов, администратор заходит на сервер и обнаруживает, что очередь RabbitMQ выросла до 50 000 сообщений, воркеры Celery упали три часа назад, а диск с логами MongoDB заполнен под завязку. Мониторинг предотвращает этот сценарий, фиксируя аномалии на ранней стадии.

Критические компоненты Open edX, требующие постоянного наблюдения:

  • LMS и CMS - веб-интерфейсы платформы. Падение любого из них блокирует доступ пользователей и авторов курсов.
  • XQueue - сервис очереди для внешних grader'ов. Задержки здесь ломают процесс проверки заданий.
  • MySQL - основная реляционная база. Медленные запросы или исчерпание пула соединений тормозят всю платформу.
  • MongoDB - хранилище структуры курсов и контента. Проблемы с репликацией ведут к рассинхронизации данных между нодами.
  • RabbitMQ - брокер сообщений для Celery. Переполнение очередей останавливает отправку писем, расчет оценок и другие фоновые задачи.

Архитектура сбора метрик строится вокруг двух моделей. Push-модель (Telegraf) отправляет данные в центральное хранилище по расписанию - подходит для статичных сред с фиксированным списком хостов. Pull-модель (Prometheus) опрашивает целевые сервисы через HTTP-эндпоинты - удобна для динамических окружений Docker, где контейнеры появляются и исчезают. Выбор модели определяет стек инструментов, который мы разберем в следующем разделе.

Выбор стека мониторинга: Telegraf + InfluxDB + Chronograf vs Prometheus + Grafana

Оба стека покрывают полный цикл наблюдения: сбор метрик, хранение, визуализацию и алертинг. Разница в архитектуре и кривой обучения. Для небольших инсталляций Open edX (до 5 серверов, до 1000 активных пользователей) стек TICK разворачивается за час и требует минимум настройки. Для крупных кластеров с автоскейлингом контейнеров Prometheus дает нативную интеграцию с Docker и Kubernetes.

Детальное сравнение Zabbix, Prometheus и Netdata с точки зрения стоимости и поддержки контейнерных сред вы найдете в отдельном материале. Здесь сосредоточимся на практической настройке применительно к Open edX.

Стек TICK: простота и быстрый старт

Telegraf - агент, написанный на Go, с минимальным потреблением ресурсов (около 50 МБ ОЗУ). Он собирает метрики через плагины: системные (CPU, память, диск), Docker, MySQL, MongoDB, RabbitMQ, HTTP-ответы. Данные отправляются в InfluxDB - базу временных рядов, оптимизированную под запись миллионов точек в секунду. Chronograf предоставляет веб-интерфейс для построения дашбордов и настройки алертов через Kapacitor.

Пример конфигурации Telegraf для сбора системных метрик и ответа LMS:

[[inputs.cpu]]
  percpu = true
  totalcpu = true

[[inputs.mem]]

[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

[[inputs.http_response]]
  urls = ["https://lms.example.com/heartbeat"]
  response_timeout = "5s"
  method = "GET"
  response_string_match = "OK"

[[outputs.influxdb]]
  urls = ["http://influxdb.example.com:8086"]
  database = "open_edx_metrics"

Этот конфиг проверяет эндпоинт /heartbeat LMS, ожидая ответ "OK" за 5 секунд. При таймауте или несовпадении строки Telegraf помечает проверку как неуспешную, и Kapacitor генерирует алерт.

Сильные стороны TICK для Open edX: быстрая установка (один бинарник Telegraf на хост), простой язык запросов InfluxQL, встроенные шаблоны дашбордов в Chronograf. Слабые: ограниченная поддержка service discovery, необходимость ручного добавления новых целей при масштабировании.

Стек Prometheus + Grafana: гибкость и масштабируемость

Prometheus опрашивает цели через HTTP, забирая метрики с экспортеров - специализированных агентов, которые преобразуют внутренние метрики сервиса в формат Prometheus. Для каждого компонента Open edX существует готовый экспортер: mysqld_exporter, mongodb_exporter, rabbitmq_prometheus (встроен в RabbitMQ начиная с версии 3.8).

Базовая конфигурация Prometheus для сбора метрик с сервисов Open edX:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'lms'
    metrics_path: '/heartbeat'
    static_configs:
      - targets: ['lms.example.com:80']

  - job_name: 'mysql'
    static_configs:
      - targets: ['mysql-exporter.example.com:9104']

  - job_name: 'mongodb'
    static_configs:
      - targets: ['mongodb-exporter.example.com:9216']

  - job_name: 'rabbitmq'
    static_configs:
      - targets: ['rabbitmq.example.com:15692']

Service discovery для Docker настраивается через отдельный блок dockerswarm_sd_configs или docker_sd_configs, что позволяет Prometheus автоматически находить новые контейнеры по меткам. Это критично для сред, где воркеры Celery масштабируются горизонтально под нагрузкой.

Grafana подключается к Prometheus как к источнику данных. Готовые дашборды для MySQL (ID 7362), MongoDB (ID 2583) и RabbitMQ (ID 4279) импортируются из каталога Grafana Labs за минуту. Для LMS и CMS создаются кастомные панели на основе метрик из Blackbox Exporter: время ответа, коды HTTP, доступность эндпоинтов.

Сильные стороны Prometheus: pull-модель не требует открытия портов на агентах, мощный язык PromQL для анализа, нативная интеграция с Kubernetes. Слабые: более сложная начальная настройка, необходимость разворачивать отдельные экспортеры для каждого сервиса.

Мониторинг основных сервисов Open edX

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

LMS и CMS: отслеживание ответов и ошибок

Ключевые метрики веб-интерфейсов: latency (p50, p95, p99), процент ошибок (5xx), количество запросов в секунду. В Telegraf используется плагин http_response, в Prometheus - Blackbox Exporter.

Настройка Blackbox Exporter для проверки LMS:

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: [200, 301, 302]
      method: GET

В Prometheus добавляется задача:

- job_name: 'blackbox'
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
      - https://lms.example.com
      - https://studio.example.com
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - target_label: __address__
      replacement: blackbox-exporter:9115

Эндпоинт /heartbeat в Open edX возвращает 200 OK, если LMS может подключиться к базам данных и брокеру. Проверяйте его каждые 15 секунд. Алерт генерируется при трех последовательных ошибках - это исключает ложные срабатывания при кратковременных всплесках.

XQueue: контроль очереди задач

XQueue обрабатывает задания от внешних grader'ов через RabbitMQ. Задержка в этой очереди означает, что студенты не получают результаты проверки работ. Мониторинг сводится к отслеживанию очереди xqueue в RabbitMQ: количество сообщений, скорость поступления и потребления.

В Prometheus метрики RabbitMQ включают все очереди автоматически при включении встроенного плагина:

rabbitmq-plugins enable rabbitmq_prometheus

Запрос PromQL для алерта на рост очереди XQueue:

rate(rabbitmq_queue_messages_published_total{queue="xqueue"}[5m]) 
> 
rate(rabbitmq_queue_messages_consumed_total{queue="xqueue"}[5m]) * 1.5

Это правило срабатывает, когда скорость публикации сообщений превышает скорость потребления в полтора раза на протяжении 5 минут - верный признак, что воркеры не справляются.

MySQL и MongoDB: здоровье баз данных

Для MySQL критичны: количество активных соединений (порог - 80% от max_connections), медленные запросы (более 10 в минуту), задержка репликации (более 5 секунд). mysqld_exporter собирает эти метрики через SHOW GLOBAL STATUS и SHOW SLAVE STATUS.

Пример алерта на исчерпание пула соединений в Prometheus:

mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8

Для MongoDB отслеживаются: операции CRUD в секунду (opcounters), использование памяти WiredTiger (cache usage), задержка репликации (replication lag). mongodb_exporter подключается к инстансу и отдает метрики на порту 9216.

Типичная проблема инсталляций Open edX - неоптимальные индексы MongoDB, приводящие к полному сканированию коллекций. Метрика mongodb_mongod_metrics_query_executor_scanned_objects_per_sec в сочетании с mongodb_mongod_metrics_query_executor_returned_per_sec показывает соотношение просканированных и возвращенных документов. Значение выше 100:1 указывает на отсутствующий индекс.

RabbitMQ: мониторинг брокера сообщений

RabbitMQ - центральный узел асинхронной архитектуры Open edX. Его отказ парализует Celery, XQueue и межсервисное взаимодействие. Ключевые метрики: готовые сообщения в очередях (messages_ready), количество потребителей (consumers), использование файловых дескрипторов и сокетов.

Встроенный Prometheus-плагин RabbitMQ отдает метрики на порту 15692 без дополнительных экспортеров. Для стека TICK плагин Telegraf rabbitmq подключается к Management API:

[[inputs.rabbitmq]]
  url = "http://rabbitmq.example.com:15672"
  username = "monitoring"
  password = "secure_password"
  queue_name_include = ["celery", "xqueue", "edx.*"]

Алерт на очередь с непринятыми сообщениями (нет потребителей):

rabbitmq_queue_messages_ready > 100 AND rabbitmq_queue_consumers == 0

Такая ситуация возникает при падении всех воркеров Celery - сообщения накапливаются, но обрабатывать их некому.

Мониторинг очередей задач Celery

Celery выполняет фоновые задачи Open edX: отправку email, расчет оценок, генерацию сертификатов, синхронизацию курсов. Архитектура включает брокер (RabbitMQ или Redis), воркеры и планировщик Celery Beat для периодических задач.

Flower - веб-интерфейс для Celery, показывающий активные, запланированные и упавшие задачи в реальном времени. Он разворачивается отдельным контейнером и подключается к тому же брокеру, что и воркеры:

celery -A proj flower --broker=amqp://user:pass@rabbitmq:5672//

Для интеграции с Prometheus используется celery-exporter, который через HTTP отдает метрики о времени выполнения задач, количестве успешных и проваленных операций. Запрос для выявления задач с растущим временем выполнения:

rate(celery_task_runtime_seconds_sum[10m]) / rate(celery_task_runtime_seconds_count[10m])

Рост этого показателя сигнализирует о деградации - возможно, база данных тормозит, и задачи, зависящие от нее, занимают все больше времени.

Мониторинг контейнеров Docker

Open edX в продакшене почти всегда разворачивается в Docker-контейнерах. cAdvisor - агент от Google, собирающий метрики использования ресурсов на уровне контейнеров: CPU, память, сетевой ввод-вывод, дисковые операции. Он запускается как контейнер с монтированием системных директорий:

docker run -d \
  --name=cadvisor \
  -p 8080:8080 \
  -v /:/rootfs:ro \
  -v /var/run:/var/run:ro \
  -v /sys:/sys:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  gcr.io/cadvisor/cadvisor:latest

Prometheus забирает метрики с cAdvisor через эндпоинт /metrics. Алерт на контейнер, потребляющий больше 90% выделенной памяти:

container_memory_usage_bytes{container_name!=""} 
/ 
container_spec_memory_limit_bytes{container_name!=""} > 0.9

Отдельное внимание - статусу контейнеров. Метрика container_last_seen позволяет детектировать упавшие контейнеры: если Prometheus не видит контейнер более 60 секунд, генерируется алерт. Для стека TICK плагин Telegraf docker собирает аналогичные метрики через Docker API.

Выявление узких мест производительности

Собранные метрики превращаются в инструмент диагностики, когда администратор сопоставляет данные из разных источников. Методика поиска узких мест строится на корреляции: медленный ответ LMS → рост активных соединений MySQL → появление медленных запросов в slow query log.

Типичные узкие места Open edX и их индикаторы:

  • База данных MySQL - p95 latency LMS растет, Threads_running стабильно выше 10, Innodb_row_lock_waits увеличивается. Решение: оптимизация запросов, увеличение пула соединений, добавление реплик для чтения.
  • Очереди Celery - messages_ready в очереди celery монотонно растет, количество воркеров неизменно. Решение: горизонтальное масштабирование воркеров, вынос тяжелых задач в отдельную очередь.
  • Файловое хранилище - операции ввода-вывода на диске (iowait) превышают 30%, при этом LMS активно работает с файлами курсов. Решение: перенос статики на объектное хранилище (S3), увеличение IOPS диска.

В Grafana панель корреляции строится через связанные запросы: клик на точку графика latency LMS фильтрует панель MySQL-запросов по тому же временному интервалу. Chronograf предоставляет аналогичную функциональность через dashboard variables.

Настройка алертов и уведомлений

Алерты делятся на три уровня критичности. P1 (критический) - полная недоступность LMS или CMS, переполнение очереди RabbitMQ (> 10 000 сообщений), отказ базы данных. P2 (высокий) - p95 ответа LMS > 2 секунд, использование CPU > 90% более 5 минут, задержка репликации MongoDB > 10 секунд. P3 (средний) - рост медленных запросов MySQL, свободное место на диске < 20%, количество воркеров Celery ниже ожидаемого.

В Prometheus алерты настраиваются через Alertmanager с маршрутизацией по severity:

groups:
  - name: open_edx_critical
    rules:
      - alert: LMSDown
        expr: probe_success{job="blackbox", instance="https://lms.example.com"} == 0
        for: 1m
        labels:
          severity: P1
        annotations:
          summary: "LMS недоступна"
          description: "Эндпоинт /heartbeat не отвечает более 1 минуты"

Alertmanager направляет P1 в Telegram и Slack, P2 - в email и Slack, P3 - только в email-дайджест раз в час. Каналы уведомлений настраиваются в конфигурации Alertmanager:

route:
  receiver: 'slack-critical'
  routes:
    - match:
        severity: P1
      receiver: 'slack-critical'
    - match:
        severity: P2
      receiver: 'email-slack'
    - match:
        severity: P3
      receiver: 'email-digest'

В стеке TICK за алертинг отвечает Kapacitor. Правила пишутся на TICKscript или через визуальный редактор Chronograf. Пример правила для очереди RabbitMQ:

var ready = stream
    |from()
        .measurement('rabbitmq_queues')
    |alert()
        .crit(lambda: "messages_ready" > 5000)
        .message('Очередь {{ .queue }} содержит {{ .messages_ready }} сообщений')

Обеспечение отказоустойчивости мониторинга

Система мониторинга сама становится точкой отказа, если развернута в единственном экземпляре. Базовые меры повышения надежности: резервирование базы данных временных рядов, репликация Grafana, мета-мониторинг.

Для Prometheus настройка федерации позволяет центральному серверу собирать агрегированные метрики с нескольких экземпляров. InfluxDB поддерживает кластеризацию в коммерческой версии; для открытой версии практикуется запуск двух независимых инстансов с параллельной записью от Telegraf через [[outputs.influxdb]] с разными URL.

Мета-мониторинг - проверка самого мониторинга. Blackbox Exporter опрашивает эндпоинты Prometheus и Grafana, отдельный Prometheus следит за основным. Минимальная конфигурация: алерт на недоступность Prometheus более 60 секунд, алерт на превышение 80% дискового пространства в хранилище метрик.

Развертывание инфраструктуры мониторинга требует вычислительных ресурсов. Для небольших инсталляций подойдут облачные серверы - например, Timeweb Cloud предоставляет VDS с предустановленными шаблонами Docker и Kubernetes, что ускоряет запуск Prometheus и Grafana. Для команд, которые хотят автоматизировать создание документации по настройке мониторинга, сервис генерации SEO-сайтов помогает быстро публиковать инструкции для внутреннего использования.

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