Мониторинг База данных Azure для MySQL — гибкий сервер

Azure Monitor собирает и агрегирует метрики и журналы из системы для мониторинга доступности, производительности и устойчивости, а также уведомляет вас о проблемах, влияющих на систему. Вы можете использовать портал Azure, PowerShell, Azure CLI, REST API или клиентские библиотеки для настройки и просмотра данных мониторинга.

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

Мониторинг необходим для поддержания работоспособности, производительности и безопасности экземпляров гибкого сервера базы данных Azure для MySQL. Azure Monitor предоставляет комплексное решение для сбора, анализа и выполнения данных телеметрии с серверов MySQL. В этой статье описаны доступные ключевые возможности мониторинга, включая метрики, журналы, оповещения и средства визуализации, которые помогут вам заранее управлять рабочими нагрузками базы данных.

Сбор данных с помощью Azure Monitor

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

Список всех данных, поддерживаемых Azure Monitor, см. в следующей статье:

• Поддерживаемые метрики Azure Monitor
• Журналы ресурсов, поддерживаемые Azure Monitor

Известные проблемы

Не удается создать метрики сервера, если для параметра character_set_server сервера задано значение UTF16. Это происходит, так как задача сбора метрик зависит от соединителя C# MySQL, который имеет проблемы совместимости с UTF16. Мы рекомендуем клиентам использовать альтернативный набор символов и перезапустить сервер после обновления конфигурации для восстановления функциональных возможностей метрик.

Встроенный мониторинг базы данных Azure для MySQL — гибкий сервер

База данных Azure для MySQL — гибкий сервер предлагает встроенные ресурсы для мониторинга.

Журналы сервера

В База данных Azure для MySQL гибком сервере пользователи могут настраивать и скачивать журналы серверов, чтобы помочь в устранении неполадок. Если эта функция включена, экземпляр гибкого сервера База данных Azure для MySQL начинает записывать события выбранного типа журнала и записывает их в файл. Затем можно скачать файлы с помощью портала Azure или Azure CLI.

Функция журнала сервера по умолчанию отключена. Сведения о включении журналов сервера см. в разделе "Включение и скачивание журналов сервера" для База данных Azure для MySQL — гибкий сервер

Журналы сервера поддерживают включение и скачивание журналов медленных запросов и журналов ошибок. Чтобы выполнить исторический анализ данных, в портал Azure на панели параметров диагностики сервера добавьте параметр диагностики для отправки журналов в рабочую область Log Analytics, служба хранилища Azure или центры событий. Дополнительные сведения см. в статье Настройка диагностики.

Если ведение журнала включено для экземпляра гибкого сервера База данных Azure для MySQL, журналы доступны до семи дней после их создания. Если общий объем доступных журналов превышает 7 ГБ, по мере необходимости удаляются самые старые файлы. Хранилище на 7 ГБ для журналов сервера доступно бесплатно и не может быть увеличено.

Журналы поворачиваются каждые 24 часа или когда они достигают 500 МБ, в зависимости от того, что происходит сначала.

Журналы медленных запросов в Базе данных Azure для MySQL

В гибком сервере Базы данных Azure для MySQL пользователи могут настраивать журнал медленных запросов и обращаться к нему. Журналы медленных запросов по умолчанию отключены и могут быть включены для выявления узких мест производительности во время устранения неполадок.

Дополнительные сведения о журнале медленных запросов MySQL см. в разделе о журналах медленных запросов справочного руководства по MySQL.

Настройка ведения журнала медленных запросов

Журнал медленных запросов по умолчанию отключен. Чтобы включить эти журналы, установите для параметра сервера slow_query_log значение ВКЛ. Этот параметр можно настроить с помощью портала Azure или Azure CLI.

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

• long_query_time: регистрирует запрос, если время его выполнения превышает long_query_time (в секундах). Значение по умолчанию — 10 секунд. Параметр long_query_time сервера применяется глобально ко всем новым установленным подключениям в MySQL. Однако это не влияет на потоки, которые уже подключены. Мы рекомендуем повторно подключиться к гибкому серверу Базы данных Azure для MySQL из приложения или перезапустить сервер, чтобы очистить потоки со старыми значениями long_query_time и применить обновленное значение параметра.
• log_slow_admin_statements: определяет, регистрируются ли в журнале инструкции администрирования (например, ALTER_TABLE, ANALYZE_TABLE).
• log_queries_not_using_indexes: определяет, регистрируются ли запросы, не использующие индексы.
• log_throttle_queries_not_using_indexes: ограничивает количество неиндексированных запросов, которые можно записать в журнал медленных запросов. Этот параметр вступает в силу, если для log_queries_not_using_indexes установлено значение ВКЛ.

Полное описание параметров, применимых для журнала медленных запросов, вы найдете в соответствующем разделе документации по MySQL.

Доступ к журналам медленных запросов

Журналы медленных запросов можно интегрировать с настройками диагностики Azure Monitor. После включения журналов медленных запросов в экземпляре Azure Database for MySQL Flexible Server их можно отправить в журналы Azure Monitor, Центры событий или Azure Storage. Дополнительные сведения о настройках диагностики см. в документации к журналам диагностики. Дополнительные сведения о включении настроек диагностики на портале Azure см. в статье о журналах медленных запросов на портале.

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

Отслеживание действий базы данных с помощью журналов аудита

База данных Azure для MySQL гибкий сервер предоставляет пользователям возможность настраивать журналы аудита. Журналы аудита могут использоваться для наблюдения за действиями уровня базы данных, включая события подключения, администрирования, DDL и DML. Эти типы журналов обычно используются для обеспечения соответствия требованиям.

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

По умолчанию журналы аудита отключены. Чтобы включить их, установите для параметра сервера audit_log_enabled значение ВКЛ. Включите журналы аудита с помощью портала Azure или Azure CLI.

Другие параметры, которые можно настроить для управления ведением журнала аудита:

• audit_log_events: определяет регистрируемые события. См. следующую таблицу для определенных событий аудита.
• audit_log_include_users: пользователи MySQL, которые будут включаться в журнал. Значение по умолчанию для этого параметра пусто, которое включает всех пользователей для ведения журнала. Этот параметр имеет более высокий приоритет по сравнению с audit_log_exclude_users. Максимальная длина параметра — 512 символов. Например, подстановочное значение dev* включает всех пользователей с записями, начиная с ключевых слов dev , таких как dev1,dev_user,dev_2. Другой пример для записи подстановочного знака для включения пользователя в этот пример, *dev все пользователи, заканчивающиеся значением dev, например "stage_dev,prod_dev,user_dev", включаются в записи журнала аудита. Кроме того, использование подстановочного знака в качестве подстановочного знака (?) допускается в шаблонах.
• audit_log_exclude_users: пользователи MySQL, которых следует исключить из ведения журнала. Максимальная длина параметра составляет 512 символов. Записи с подстановочными знаками для пользователя также принимаются для исключения пользователей в журналах аудита. Например, подстановочное значение stage* исключает всех пользователей с записями, начинающимися с ключевых слов stage, таких как этап1, этап_пользователь, этап_2. Другой пример записи подстановочного знака для исключения пользователя - это *com. В этом примере все пользователи, заканчивающиеся значением com , исключаются из записей журнала аудита. Кроме того, использование подстановочного знака в качестве подстановочного знака (?) допускается в шаблонах.

Доступ к журналам аудита

Журналы аудита можно интегрировать с настройками диагностики Azure Monitor. После включения журналов аудита на гибком сервере их можно вывести в журналы Azure Monitor, Центры событий Azure или службу хранилища Azure. Дополнительные сведения о настройках диагностики см. в документации к журналам диагностики. Дополнительные сведения о включении настроек диагностики в портале Azure см. в статье о портале журналов аудита.

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

Связь:

Общие сведения:

Следующая схема относится к типам событий GENERAL, DML_SELECT, DML_NONSELECT, DML, DDL, DCL и ADMIN.

Доступ к таблицам:

Использование рабочих книг Azure Monitor

База данных Azure для MySQL гибкий сервер теперь интегрирован с книгами Azure Monitor. Благодаря книгам вы получаете гибкий холст для анализа данных и создания полнофункциональных визуальных отчетов на портале Azure. Книги позволяют подключаться к нескольким источникам данных в разных службах Azure и объединять их в единый интерактивный интерфейс. Шаблоны рабочих книг служат спроектированными отчетами, которые разработаны несколькими пользователями и командами для гибкого повторного использования.

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

База данных Azure для MySQL гибкий сервер имеет три доступных шаблона:

• Обзор: отображает сводку по экземплярам и метрики верхнего уровня, помогающие визуализировать и понять использование ресурсов на сервере. Этот шаблон отображает следующие представления:

  • Сводка сервера
  • Сводные данные по базе данных
  • Метрики подключения
  • Метрики производительности
  • Метрики хранения

• Аудит: отображает сводные данные и подробные сведения о событиях аудита, собираемых для сервера. Этот шаблон отображает следующие представления:

  • Административные действия со службой
  • сводка аудита;
  • сводка аудита событий подключения;
  • аудит событий подключения;
  • сводка доступа к таблицам;
  • обнаруженные ошибки.

• Анализ производительности запросов: отображает сводку и подробные сведения о рабочей нагрузке запросов в экземпляре, долгосрочном запросе, анализе запросов с задержкой и метриках соединения. Этот шаблон отображает следующие представления:

  • загрузка запросов;
  • общее количество активных подключений;
  • Тенденция снижения скорости запросов (>10 секунд времени выполнения запроса)
  • сведения о медленных запросах;
  • Список пяти самых длинных запросов
  • Сводка медленных запросов по минимальному, максимальному, среднему и стандартному отклонению времени выполнения запроса

Кроме того, вы можете изменить эти шаблоны и настроить их в соответствии с требованиями. Дополнительные сведения см. в статье Книги Azure.

Доступ к шаблонам книг

Чтобы просмотреть шаблоны в портал Azure, перейдите в область мониторинга для База данных Azure для MySQL гибкого сервера, а затем выберите книги.

Список шаблонов можно также посмотреть в области Общедоступные шаблоны.

Использование средств Azure Monitor для анализа данных

Эти средства Azure Monitor доступны на портале Azure для анализа данных мониторинга:

• Некоторые службы Azure имеют встроенную панель мониторинга на портале Azure. Эти панели мониторинга называются инсайтами, и их можно найти в разделе "Инсайты" в Azure Monitor в портале Azure.

• Обозреватель метрик позволяет просматривать и анализировать метрики для ресурсов Azure. Дополнительные сведения см. в разделе "Анализ метрик" с помощью обозревателя метрик Azure Monitor.

• Log Analytics позволяет запрашивать и анализировать данные журнала с помощью языка запросов Kusto (KQL). Дополнительные сведения см. в статье Начало работы с запросами журналов в Azure Monitor.

• Портал Azure имеет пользовательский интерфейс для просмотра и выполнения базового поиска по журналу действий. Чтобы выполнить более подробный анализ, перенаправите данные в журналы Azure Monitor и выполните более сложные запросы в Log Analytics.

• Application Insights отслеживает доступность, производительность и использование веб-приложений, чтобы можно было выявлять и диагностировать ошибки, не ожидая, когда пользователь сообщит о них.
  Application Insights включает точки подключения к различным средствам разработки и интегрируется с Visual Studio для поддержки процессов DevOps. Дополнительные сведения см. в разделе Мониторинг приложений для App Service.

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

• Панели мониторинга, позволяющие объединять различные виды данных в одну панель в портале Azure.
• Рабочие книги — это настраиваемые отчеты, которые можно создать в портале Azure. Рабочие книги могут включать текст, метрики и лог-запросы.
• Grafana — инструмент с открытой платформой, который превосходно подходит для операционных панелей мониторинга. С помощью Grafana можно создавать панели мониторинга, содержащие данные из нескольких источников, отличных от Azure Monitor.
• Power BI— служба бизнес-аналитики, которая предоставляет интерактивные визуализации в различных источниках данных. Вы можете настроить Power BI на автоматический импорт данных журналов из Azure Monitor, чтобы воспользоваться этими визуализациями.

Экспорт данных Azure Monitor

Вы можете экспортировать данные из Azure Monitor в другие средства с помощью:

• Метрики. Используйте REST API для метрик для извлечения данных метрик из базы данных метрик Azure Monitor. Дополнительные сведения см. в справочнике по REST API Azure Monitor.

• Журналы: используйте REST API или соответствующие клиентские библиотеки.

• Экспорт данных рабочей области Log Analytics.

Чтобы начать работать с REST API Azure Monitor, см. руководство по REST API мониторинга Azure.

Использование запросов Kusto для анализа данных журнала

Вы можете анализировать данные журнала Azure Monitor с помощью языка запросов Kusto (KQL). Дополнительные сведения см. в разделе Запросы журналов в Azure Monitor.

Рекомендуемые запросы Kusto для Azure Database for MySQL - Flexible Server

Журналы медленных запросов можно использовать для поиска кандидатов для оптимизации. После передачи журналов медленных запросов в журналы Azure Monitor с помощью журналов диагностики можно выполнить дальнейший анализ медленных запросов. Эти образцы запросов помогут вам начать. Обязательно обновите их, указав имя вашего сервера.

• Запросы, выполнявшиеся дольше 10 секунд на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | where query_time_d > 10
  

• Список пяти самых длинных запросов на определенном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | order by query_time_d desc
  | take 5
  

• Сводка медленных запросов по минимальному, максимальному, среднему и стандартному отклонению времени выполнения запроса на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | summarize count(), min(query_time_d), max(query_time_d), avg(query_time_d), stdev(query_time_d), percentile(query_time_d, 95) by Resource
  

• График распределения медленных запросов на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | summarize count() by Resource , bin(TimeGenerated, 5m)
  | render timechart
  

• Отображение запросов дольше 10 секунд во всех экземплярах гибкого сервера База данных Azure для MySQL с включенными журналами диагностики

  AzureDiagnostics
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | where query_time_d > 10
  

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

• Вывод списка событий GENERAL на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs' and event_class_s == "general_log"
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | order by TimeGenerated asc nulls last
  

• Вывод списка событий CONNECTION_V2 на определенном сервереstatus_d, столбец обозначает код ошибки подключения клиента, с которым сталкивается клиентское приложение при подключении.

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs' and event_subclass_s == "CONNECT"
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, user_s, ip_s, status_d
  | order by TimeGenerated asc nulls last
  

• Вывод списка событий CONNECTION на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs' and event_class_s == "connection_log"
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | order by TimeGenerated asc nulls last
  

• Вывод сводки событий, для которых проводится аудит, на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs'
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | summarize count() by event_class_s, event_subclass_s, user_s, ip_s
  

• Построение диаграммы распределения типов событий, для которых проводится аудит, на конкретном сервере

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs'
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | summarize count() by Resource, bin(TimeGenerated, 5m)
  | render timechart
  

• Вывод списка событий аудита во всех экземплярах гибкого сервера База данных Azure для MySQL с включенными журналами диагностики для журналов аудита

  AzureDiagnostics
  | where Category == 'MySqlAuditLogs'
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | order by TimeGenerated asc nulls last
  

Использование оповещений Azure Monitor для уведомления о проблемах

Оповещения Azure Monitor позволяют выявлять и устранять проблемы в системе, а также заранее уведомлять вас, когда конкретные условия находятся в данных мониторинга, прежде чем клиенты заметят их. Вы можете настроить оповещения на любую метрику или источник данных в платформе Azure Monitor. Существуют различные типы оповещений Azure Monitor в зависимости от служб, которые вы отслеживаете, и собираемых данных мониторинга. См. Выбор подходящего типа правила оповещения.

Рекомендуемые правила оповещений Azure Monitor для гибкого сервера базы данных Azure для MySQL

Примеры распространённых оповещений для ресурсов Azure см. в примерах запросов журнала оповещений.

Реализация оповещений в масштабе

Для некоторых служб можно отслеживать масштаб, применяя одно правило генерации оповещений метрик к нескольким ресурсам одного типа, которые существуют в одном регионе Azure. Оповещения базовых показателей Azure Monitor (AMBA) предоставляют полуавтоматический метод внедрения оповещений о важных метриках платформы, панелей мониторинга и рекомендаций в крупном масштабе.

Получение персонализированных рекомендаций с помощью Помощника по Azure

Для некоторых служб, если во время операций ресурсов происходят критические условия или неизбежные изменения, на странице Обзор службы в портале отображается оповещение. Вы можете найти дополнительную информацию и рекомендуемые исправления для оповещения в рекомендациях Консультанта в разделе Мониторинг в меню слева. Во время обычных операций рекомендации помощника не отображаются.

Дополнительные сведения о Azure Advisor см. в разделе обзор продукта Azure Advisor.

Связанный контент

• База данных Azure для MySQL — справочник по данным мониторинга гибкого сервера
• Мониторинг ресурсов Azure с помощью Azure Monitor