Мониторинг MySQL с помощью Proto Observability

На этой странице:

• Сбор основных метрик MySQL
  • Конфигурация MySQL
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка
• Сбор метрик уровня SQL-запросов
  • Конфигурация MySQL
    • Включение performance_schema
    • Создание или изменение служебного пользователя
    • Создание служебных таблиц в базе
  • Конфигурация ProtoOBP агента
  • Проверка
• Собираемые метрики
  • Лейблы
  • Соединения и потоки
  • Запросы и команды
  • Обработчики и временные таблицы
  • InnoDB
  • Кэши и буферы (MyISAM, query cache)
  • Binlog
  • Репликация
  • Размеры схем и таблиц
  • Метрики уровня SQL-запросов
• Ключевые метрики для дашбордов и алертов
• Сбор логов MySQL
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор основных метрик MySQL

Убедитесь, что у вас установлен и настроен ProtoOBP агент.

Конфигурация MySQL

Для подключения агента ProtoOBP к MySQL необходимо создать пользователя с правами только на чтение для этого:

1. Создайте нового пользователя protoobp:

   CREATE USER 'protoobp'@'%' IDENTIFIED BY '<пароль>';
   

2. Задайте права для сбора метрик пользователю protoobp:

   • Для MySQL 5.6 и 5.7:

     ALTER USER 'protoobp'@'%' WITH MAX_USER_CONNECTIONS 5;
     GRANT REPLICATION CLIENT ON *.* TO 'protoobp'@'%';
     GRANT PROCESS ON *.* TO 'protoobp'@'%';
     

   • Для MySQL 8.0+ (MAX_USER_CONNECTIONS задаётся через ALTER USER):

     ALTER USER 'protoobp'@'%' WITH MAX_USER_CONNECTIONS 5;
     GRANT REPLICATION CLIENT ON *.* TO 'protoobp'@'%';
     GRANT PROCESS ON *.* TO 'protoobp'@'%';
     

3. Если на сервере MySQL включена performance_schema (в MySQL 8.0 — по умолчанию), для сбора метрик добавьте соответствующие права пользователю protoobp:

   GRANT SELECT ON performance_schema.* TO 'protoobp'@'%';
   

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. Создайте файл /etc/protoobp-agent/conf.d/mysql.d/conf.yaml:

   init_config:
   
   instances:
     - host: 127.0.0.1            # Не используйте localhost
       port: 3306                 # Порт MySQL
       username: protoobp
       password: "<пароль>"       # Пароль пользователя protoobp
       options:
         replication: false       # true — если экземпляр в репликации
         galera_cluster: false    # true — для узла Galera/PXC
         extra_status_metrics: true     # доп. метрики из SHOW GLOBAL STATUS
         extra_innodb_metrics: true     # доп. метрики SHOW ENGINE INNODB STATUS
         extra_performance_metrics: true   # per-schema метрики из performance_schema
         schema_size_metrics: false        # размеры схем (тяжёлый запрос — выключено)
         disable_innodb_metrics: false
   

2. Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Добавьте autodiscovery-лейблы к контейнеру MySQL. В docker-compose.yaml:

labels:
  com.protoobp.ad.check_names: '["mysql"]'
  com.protoobp.ad.init_configs: '[{}]'
  com.protoobp.ad.instances: '[{"host": "%%host%%", "port": 3306, "username": "protoobp", "password": "<пароль>", "options": {"replication": false, "extra_status_metrics": true, "extra_innodb_metrics": true, "extra_performance_metrics": true, "schema_size_metrics": false}}]'

или в Dockerfile:

LABEL "com.protoobp.ad.check_names"='["mysql"]'
LABEL "com.protoobp.ad.init_configs"='[{}]'
LABEL "com.protoobp.ad.instances"='[{"host": "%%host%%", "port": 3306, "username": "protoobp", "password": "<пароль>", "options": {"replication": false, "extra_status_metrics": true, "extra_innodb_metrics": true, "extra_performance_metrics": true, "schema_size_metrics": false}}]'

%%host%% — шаблонная переменная autodiscovery, агент подставляет IP контейнера MySQL в общей docker network.

Проверка

Убедитесь, что проверка запустилась и собирает метрики:

docker exec protoobp-agent agent status | grep -A 8 "mysql ("

Ожидаемый вывод — Instance ID: ... [OK] и ненулевое число Metric Samples (например, около 153 уникальных метрик mysql_*):

    mysql (8.5.1)
    -------------
      Instance ID: mysql:21409e6f77f7014b [OK]
      Total Runs: 12
      Metric Samples: Last Run: 154, Total: 1,845
      Service Checks: Last Run: 1, Total: 12
      Average Execution Time : 48ms

Сервис-проверка подключения должна быть OK:

docker exec protoobp-agent agent check mysql | grep -A2 mysql.can_connect

Полный список собранных серий и их значения:

docker exec protoobp-agent agent check mysql --check-rate

В веб-интерфейсе ProtoOBP метрики появятся в разделе Базы данных > MySQL (новый сервис именуется по хосту; на появление данных нужно около 1 минуты).

Сбор метрик уровня SQL-запросов

Данная опция позволяет видеть метрики по каждому SQL-запросу используя performance_schema.

Конфигурация MySQL

Включение performance_schema

Измените файл конфигурации MySQL (обычно /etc/my.cnf) и включите performance_schema, а также необходимые параметры:

[mysqld]
performance_schema=ON
max_digest_length=4096
performance_schema_max_digest_length=4096
performance_schema_max_sql_text_length=4096
performance-schema-consumer-events-statements-current=ON
performance-schema-consumer-events-waits-current=ON
performance-schema-consumer-events-statements-history-long=ON
performance-schema-consumer-events-statements-history=ON

Примените конфигурацию, перезапустив MySQL.

Создание или изменение служебного пользователя

CREATE USER protoobp@'%' IDENTIFIED by '<пароль>';
ALTER USER protoobp@'%' WITH MAX_USER_CONNECTIONS 5;
GRANT REPLICATION CLIENT ON *.* TO protoobp@'%';
GRANT PROCESS ON *.* TO protoobp@'%';
GRANT SELECT ON performance_schema.* TO protoobp@'%';

Создание служебных таблиц в базе

CREATE SCHEMA IF NOT EXISTS protoobp;
GRANT EXECUTE ON protoobp.* to protoobp@'%';
GRANT CREATE TEMPORARY TABLES ON protoobp.* TO protoobp@'%';

DELIMITER $$
CREATE PROCEDURE protoobp.explain_statement(IN query TEXT)
    SQL SECURITY DEFINER
BEGIN
    SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
    PREPARE stmt FROM @explain;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;


DELIMITER $$
CREATE PROCEDURE protoobp.enable_events_statements_consumers()
    SQL SECURITY DEFINER
BEGIN
    UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name LIKE 'events_statements_%';
    UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name = 'events_waits_current';
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE protoobp.enable_events_statements_consumers TO protoobp@'%';

Для каждой БД выполните:

DELIMITER $$
CREATE PROCEDURE <ИМЯ-БД>.explain_statement(IN query TEXT)
    SQL SECURITY DEFINER
BEGIN
    SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
    PREPARE stmt FROM @explain;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE <ИМЯ-БД>.explain_statement TO protoobp@'%';

Конфигурация ProtoOBP агента

• Тип установки агента:
• Хост
• Docker

Проверка

В agent status проверка mysql должна быть status : OK с ненулевым metric_count, а в разделе Database Monitoring — без ошибок:

docker exec protoobp-agent agent status | grep -A 8 "^    mysql$"
docker exec protoobp-agent agent status | sed -n '/Database Monitoring/,/^=/p'

В веб-интерфейсе ProtoOBP перейдите в раздел Базы данных > MySQL > имя сервера > вкладка SQL запросы и убедитесь, что в дашборде отображаются данные по производительности SQL-запросов. Для отображения данных может потребоваться около 1 минуты.

Собираемые метрики

Проверка mysql собирает метрики через клиентское подключение к MySQL: основной источник — SHOW GLOBAL STATUS и SHOW GLOBAL VARIABLES, плюс SHOW ENGINE INNODB STATUS (при extra_innodb_metrics), SHOW SLAVE STATUS (при replication: true) и performance_schema (per-schema метрики при extra_performance_metrics, метрики уровня запросов при dbm: true).

Большинство метрик имеют тип gauge. Часть из них — это «дельта в секунду» от кумулятивных счётчиков MySQL (агент сам конвертирует прирост счётчика в rate); такие помечены единицей <единица>/секунду. Несколько метрик публикуются как count (кумулятивный счётчик, бэкенд считает дельту сам) — это отдельно отмечено в таблицах.

Ниже — основные группы. Метрики, перечисленные с пометкой «(extra_*)», появляются только при включённой соответствующей опции.

Лейблы

Соединения и потоки

Запросы и команды

Обработчики и временные таблицы

Метрики mysql_performance_handler_* (rate из Handler_*) появляются при extra_status_metrics и показывают внутреннюю активность storage engine.

InnoDB

Появляются при extra_innodb_metrics (поверх базового набора Innodb_* из SHOW GLOBAL STATUS). Часть значений берётся из секций SHOW ENGINE INNODB STATUS.

Buffer pool

Строки, транзакции, блокировки

I/O, redo log, прочее

Кэши и буферы (MyISAM, query cache)

Binlog

Репликация

Появляются при replication: true (SHOW SLAVE STATUS / SHOW REPLICA STATUS) либо в окружении group replication.

Размеры схем и таблиц

Появляются при schema_size_metrics: true (запрос к information_schema — относительно тяжёлый, по умолчанию выключен).

Метрики уровня SQL-запросов

Появляются при dbm: true и включённой performance_schema с digest-консьюмерами; все несут лейблы query_signature/digest (+ schema). Тип — count (кумулятив, дельту считает бэкенд).

Ключевые метрики для дашбордов и алертов

Доступность

• Отсутствие свежих серий по сервису mysql — алерт: сервер недоступен или агент не может подключиться (проверьте права пользователя protoobp и MAX_USER_CONNECTIONS).
• Сервис-проверка mysql_can_connect со статусом CRITICAL — то же.

Соединения

• mysql_performance_threads_connected / mysql_net_max_connections_available — приближение к лимиту → отказ новым клиентам. Алерт по доле (например > 80 %).
• mysql_net_aborted_connects > 0 устойчиво — проблемы аутентификации/сети/таймаутов.
• mysql_performance_threads_running стабильно высокий — затык: блокировки, тяжёлые запросы, нехватка CPU.

Производительность запросов

• mysql_performance_queries / questions — базовая пропускная способность; резкое падение при ожидаемой нагрузке = деградация.
• mysql_performance_slow_queries rate > 0 — медленные запросы; смотрите slow query log.
• mysql_performance_created_tmp_disk_tables rate — временные таблицы уходят на диск (мал tmp_table_size / неоптимальные запросы).
• mysql_performance_handler_read_rnd_next высокий относительно handler_read_key — много full scans, не хватает индексов.
• mysql_performance_select_full_join / select_scan > 0 устойчиво — join’ы без индексов.
• При dbm: true: топ по mysql_queries_time / mysql_queries_count / mysql_queries_rows_examined per query_signature — какие запросы дороже всего.

InnoDB

• mysql_innodb_buffer_pool_utilization близко к 1 + рост mysql_innodb_buffer_pool_reads — buffer pool мал, растут чтения с диска.
• mysql_innodb_row_lock_waits rate и mysql_innodb_row_lock_time — рост = контеншн по строкам; mysql_innodb_deadlocks > 0 — дедлоки.
• mysql_innodb_history_list_length растёт и не падает — purge не успевает (длинные транзакции держат старые версии строк).
• mysql_innodb_log_waits rate > 0 — мал innodb_log_buffer_size.
• mysql_innodb_data_pending_fsyncs / pending_* устойчиво ненулевые — диск не справляется с I/O.

Репликация

• mysql_replication_seconds_behind_source (или ..._behind_master) растёт — реплика отстаёт; алерт по порогу.
• mysql_replication_slave_running == 0 / сервис-проверка mysql_replication_replica_running не OK — поток репликации остановлен.
• mysql_replication_group_conflicts_detected > 0 — конфликты в group replication.

Сбор логов MySQL

Логи MySQL собираются ProtoOBP агентом и отправляются в бэкенд ProtoOBP. Здесь — только специфичные для MySQL настройки. Включение логов на стороне агента (logs_enabled, logs_pobp_url) описано в Получение данных логов.

У MySQL есть несколько логов:

• error log — старт/стоп сервера, ошибки, предупреждения. В пакетной установке обычно /var/log/mysql/error.log; в официальном образе mysql:8.0 по умолчанию пишется в stdout контейнера.
• slow query log — запросы дольше long_query_time. Включается отдельно (--slow_query_log=ON --slow_query_log_file=... --long_query_time=...), обычно /var/log/mysql/mysql-slow.log.
• general query log — все запросы; для продакшна, как правило, выключен.

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

Дополните /etc/protoobp-agent/conf.d/mysql.d/conf.yaml (тот же файл, в котором лежит instances:) блоком logs::

logs:
  - type: file
    path: /var/log/mysql/error.log
    source: mysql
    service: mysql
    log_processing_rules:
      - type: multi_line
        name: log_start_with_date
        pattern: \d{4}-\d{2}-\d{2}
  - type: file
    path: /var/log/mysql/mysql-slow.log
    source: mysql
    service: mysql
    log_processing_rules:
      - type: multi_line
        name: new_slow_query_log_entry
        # Записи slow query log начинаются со строки "# Time: ..." либо
        # "# User@Host: ..." — склеиваем многострочную запись по ним.
        pattern: '# Time: |# User@Host: '

Пути зависят от дистрибутива (см. log_error / slow_query_log_file в SHOW GLOBAL VARIABLES). Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Шаг 1 — включите сбор логов в самом агенте через переменные окружения и смонтируйте директорию JSON-логов docker-демона:

services:
  protoobp-agent:
    environment:
      POBP_LOGS_ENABLED: "true"
      POBP_LOGS_CONFIG_USE_HTTP: "true"
      POBP_LOGS_CONFIG_LOGS_POBP_URL: <protoobp-backend>:<port>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # Прямое чтение JSON-лог файлов docker-демона быстрее,
      # чем тянуть их через Docker socket API.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Шаг 2 — добавьте лейбл com.protoobp.ad.logs к контейнеру MySQL. Образ mysql:8.0 пишет error log в stdout — агент подхватит его и пометит записи указанными source и service:

services:
  mysql:
    labels:
      com.protoobp.ad.logs: '[{"source": "mysql", "service": "mysql", "log_processing_rules": [{"type": "multi_line", "name": "log_start_with_date", "pattern": "\\d{4}-\\d{2}-\\d{2}"}]}]'

Slow query log в контейнере пишется в файл, а не в stdout. Чтобы собрать и его, направьте файл на общий том и добавьте отдельный источник типа file (через conf.d/mysql.d/conf.yaml host-агента или POBP_LOGS_CONFIG_.../смонтированный conf.yaml в контейнере агента) — с path: <том>/mysql-slow.log и тем же source: mysql.

Проверка

В выводе agent status должен быть раздел Logs Agent со статусом running и хотя бы один источник mysql с ненулевым BytesRead (у источника типа «JSON-файл docker-контейнера» поле Status может отображаться как Pending даже при активном чтении — смотрите BytesRead и LogsProcessed):

docker exec protoobp-agent agent status \
  | sed -n '/^==== Logs Agent ====/,/^====/p'