Трассировка и отслеживание действий

Завершено

Основную часть мер по обслуживанию баз данных занимает настройка их производительности. Те файлы журналов, которые вы просматривали при работе с локальными базами данных, доступны и в Базе данных Azure для MySQL/PostgreSQL.

После переноса баз данных в Azure необходимо продолжать просмотр файлов журналов, чтобы гарантировать нужную производительность этих баз данных.

В этом модуле вы узнаете, где в службе Azure хранятся файлы журналов для PostgreSQL и MySQL, а также узнаете уровень детальности содержащихся в них данных.

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

База данных Azure для MySQL/PostgreSQL также записывает диагностическую информацию в журналы сервера. Журналы сервера — это собственные файлы журналов сообщений для MySQL и PostgreSQL (это не файлы журналов транзакций, которые недоступны в Базе данных Azure для MySQL/PostgreSQL). Эти файлы содержат сообщения, информацию о состоянии сервера и другую информацию об ошибках. Все эти данные можно использовать для отладки проблем с базами данных. Журналы сервера хранятся в течение семи дней (либо меньший срок, если общий размер файлов журналов сервера превышает 7 ГБ).

Службы "База данных Azure для MySQL" и "База данных Azure для PostgreSQL" записывают разную информацию в журналы сервера. В следующих разделах журналы серверов описываются для каждой из этих служб отдельно.

Журналы сервера в базе данных Azure для MySQL

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

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

• log_queries_not_using_indexes. Этот параметр имеет значение ON или OFF. Задайте для него значение ON для записи всех запросов, которые, скорее всего, будут выполнять полное сканирование таблицы, а не поиск по индексу.
• log_throttle_queries_not_using_indexes. Указывает максимальное количество медленных запросов, не использующих индексы, которые можно зарегистрировать в журнале за минуту.
• log_slow_admin_queries. Установите для этого параметра значение ON для записи медленно выполняющихся администраторских запросов в журнал.
• long_query_time. Пороговое значение (в секундах), определяющее, какой запрос будет считаться медленно выполняющимся.

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

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

• audit_log_events. Укажите здесь события, включаемые в аудит. На портале Azure этот параметр представляет собой раскрывающийся список событий, таких как CONNECTION, DDL, DML, ADMINи т. д.
• audit_log_exclude_users. Этот параметр представляет собой разделенный запятыми список пользователей, действия которых не будут включаться в журнал аудита.

Если необходимо хранить журнал медленных запросов и журнал аудита более 7 дней, вы можете переместить их в службу хранилища Azure. Откройте страницу Параметры диагностики для своего сервера и выберите + Добавить параметр диагностики. На странице Параметры диагностики выберите Архивировать в учетной записи хранения, выберите учетную запись хранения, в которой нужно сохранить файлы журнала (эта учетная запись уже должна существовать), затем выберите MySqlSlowLogs и MySqlAuditLogs и укажите срок хранения (до 365 дней). Вы можете загрузить файлы журналов из службы хранилища Azure в любой момент времени в течение указанного срока. Выбрать Сохранить:

Данные журнала медленных запросов будут записаны в формате JSON в большие двоичные объекты в контейнере с именем insights-logs-mysqlslowlogs. Для появления файлов журнала в службе хранилища Azure может потребоваться до 10 минут. Записи аудита хранятся в формате JSON в контейнере больших двоичных объектов insights-logs-mysqlslowlogs.

Журналы сервера в базе данных Azure для PostgreSQL

В Базе данных Azure для PostgreSQL журнал сервера содержит файлы журнала ошибок и файлы журнала запросов. Информацию из этих файлов можно использовать для выявления источников ошибок и неэффективных запросов.

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

• log_checkpoints. Контрольная точка создается каждый раз, когда каждый файл данных обновляется последними данными из журнала транзакций. В случае сбоя сервера эта контрольная точка обозначает момент времени, c которого должно выполняться восстановление путем наката из журнала транзакций.
• log_connection и log_disconnections. Эти параметры включают регистрацию каждого успешного соединения и конца каждого сеанса.
• log_duration. Этот параметр включает регистрацию продолжительности выполнения каждой выполненной инструкции SQL.
• log_lock_waits. Этот параметр включает регистрацию событий ожидания блокировки. Если возникает ожидание блокировок, это может быть вызвано плохой реализацией транзакций в коде приложения.
• log_statement_stats. Этот параметр включает запись в журнал обобщенной информации о производительности сервера.

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

• log_error_verbosity. Этот параметр задает уровень детализации для каждого сообщения, записанного в журнал.
• log_retention_days. Число дней, в течение которых файлы журнала хранятся на сервере перед удалением. Значение этого параметра по умолчанию — 3 дня, максимально возможное — 7 дней.
• log_min_messages и log_min_error_statement. Эти параметры задают уровни предупреждений и ошибок для записи инструкций.

Как и в случае с Базой данных Azure для MySQL, файлы журналов, созданные Базой данных Azure для PostgreSQL, доступны на странице Журналы сервера. На странице Параметры диагностики можно также скопировать журналы в службу хранилища Azure.

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

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

Включение отслеживания производительности запросов

Хранилище запросов записывает сведения в схему mysql в Базе данных Azure для MySQL и в Базу данных с именем azure_sys в Базе данных Azure для PostgreSQL. Хранилище запросов может собирать данные двух типов — данные о выполнении запросов и статистику ожидания. Хранилище запросов по умолчанию отключено. Для его включения выполните следующие действия.

• Если вы используете Базу данных Azure для MySQL, установите для параметров сервера query_store_capture_mode и query_store_wait_sampling_capture_mode значение ALL.
• Если вы используете Базу данных Azure для PostgreSQL, задайте для параметра сервера pg_qs.query_capture_mode значение ALL или TOP, а для параметра pgms_wait_sampling.query_capture_mode — значение ALL.

Анализ данных о производительности запросов

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

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Если вы используете Базу данных Azure для PostgreSQL, выполните следующие запросы.

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

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

Если вы непосредственно изучите хранилище запросов, то сможете создавать собственные пользовательские отчеты и получать подробные аналитические сведения о функционировании системы. Однако следует учитывать, что чрезмерный объем доступных данных может усложнить понимание ситуации. В Базе данных Azure для MySQL/PostgreSQL имеется два дополнительных средства для анализа этих данных —Анализ производительности запросови Рекомендации по запросам.

Анализ производительности запросов — это графическая служебная программа, доступная на странице Анализ производительности запросов для сервера. На вкладке Долго выполняющиеся запросы отображается статистическая информация о наиболее долго выполняющихся запросах. Вы можете указать нужный период времени и детализировать информацию вплоть до масштаба в несколько минут. В разделе условных обозначений отображаются текст каждого запроса, а также продолжительность и число выполнений запроса. Диаграмма дает сравнительное представление о продолжительности каждого запроса. Вы можете просматривать данные по среднему времени выполнения каждого запроса, но также бывает полезно отобразить для каждого запроса общее время (продолжительность выполнения * число выполнений). На рисунке ниже показан пример.

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

События ожидания обычно делятся на три категории.

• Ожидания блокировок. Эти события возникают, если запрос пытается прочитать или изменить данные, заблокированные другим запросом. Если возникает большое количество ожиданий блокировок, проверьте наличие длительных транзакций или операций, использующих очень ограниченный уровень изоляции.
• Ожидания ввода-вывода. Ожидания такого типа возникают, если запрос выполняет большое количество операций ввода-вывода. Причиной таких ожиданий может быть плохо составленный запрос (проверьте предложение WHERE), неэффективная операция соединения или выполнение полного сканирования таблицы из-за отсутствия индекса.
• Ожидания памяти. Ожидание памяти возникает в случае, когда для обработки запроса недостаточно памяти. Такое может происходить, например, когда ваш запрос пытается прочитать большой объем данных или он блокируется другими запросами, активно потребляющими ресурсы памяти. Это также может означать, что отсутствуют индексы, в результате чего запросы считывают таблицы в память целиком.

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

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