Большинство инструментов мониторинга баз данных созданы не для той аудитории. Панели мониторинга предназначены для успокоения руководителей, оповещения откалиброваны для удовлетворения контрольных списков соответствия требованиям, а отчёты отформатированы для ежеквартальных обзоров. Ничто из этого не полезно в 10 часов вечера, когда приложение возвращает тайм-ауты, а дежурный разработчик просит обновлений каждые три минуты. То, что нужно администратору баз данных в этот момент, — это инструмент, который уже имеет контекст. Не сырые данные, которые нужно собирать в условиях стресса. Не список превышенных порогов. А реальный контекст: что выполнялось, что находилось в ожидании, что изменилось и как это сравнивается с тем, что является нормальным для данного конкретного экземпляра в это время суток. Это более сложная задача, чем кажется, и большинство инструментов мониторинга её не решают. Давайте поговорим об углублённой диагностике и информативных панелях мониторинга.
Проблема оповещений без контекста
Оповещение говорит вам, что что-то не так. Но оно почти никогда не говорит вам, почему. Загрузка процессора составляет 90 процентов. Это оповещение. Но это один вышедший из-под контроля запрос, внезапный всплеск подключений, неправильная конфигурация параллелизма, регрессия плана, вызванная устаревшей статистикой, или запланированное пакетное задание, которое выполняется каждую ночь и всегда выглядит именно так?
Оповещение не знает ответа. И инструменты, к которым администратор баз данных обычно обращается, чтобы это выяснить, отличаются от инструмента, который отправил оповещение. Этот разрыв между уведомлением и диагностикой — то место, где исчезает время устранения инцидента.
Ответ заключается не в увеличении количества оповещений или панелей мониторинга. А в предоставлении более глубокого контекста в том же интерфейсе, в тот же момент, когда срабатывает оповещение. Сеансы, выполнявшиеся в момент превышения порога, накапливающаяся в этот момент статистика ожидания, самые ресурсоёмкие запросы и то, как всё это сравнивается с историческим базовым уровнем для этого экземпляра. Без этого контекста каждое оповещение становится началом расследования, требующего переключения между инструментами, написания запросов по памяти и надежды на то, что проблема всё ещё будет видна к тому времени, когда вы её найдёте.
Динамические базовые уровни: почему фиксированные пороги не работают
Порог загрузки процессора в 80 процентов звучит как разумная отправная точка, пока вы не осознаете, что конкретный экземпляр выполняет ночное ETL, которое каждую ночь с 2 до 4 часов утра поднимает загрузку процессора до 85 процентов, и так происходит уже три года без происшествий. Оповещение, срабатывающее каждую ночь в 2 часа утра, приучает дежурную команду игнорировать его. Когда загрузка процессора достигает 85 процентов во вторник в 2 часа дня из-за того, что что-то действительно не так, никто не реагирует вовремя.
Та же проблема возникает с порогами ввода-вывода, порогами памяти и порогами времени ожидания. У каждого экземпляра есть своя норма, и эта норма меняется в зависимости от времени суток, дня недели и цикла рабочей нагрузки. Фиксированный порог, применяемый единообразно к экземплярам с разными моделями нагрузки, либо слишком чувствителен, создавая шум, либо слишком допускающий, пропуская реальные проблемы.
Динамические базовые уровни решают эту проблему, строя ожидаемое поведение на основе фактических исторических данных для каждого экземпляра и каждого показателя. Система мониторинга сравнивает текущие значения с историческим распределением значений для этого экземпляра в это время суток и в этот день недели. Отклонения от изученного базового уровня вызывают оповещения. Ожидаемая повышенная активность — нет. В таблице ниже показаны диагностические категории, где этот уровень контекста наиболее важен.
Что охватывает углублённая диагностика
Категории, которые наиболее важны во время инцидента с SQL Server, источник данных для каждой из них, соответствующий период наблюдения и то, что каждая из них на самом деле вам сообщает, приведены ниже.
| Диагностическая категория | Основной источник данных | Период наблюдения | Что это вам сообщает |
|---|---|---|---|
| Анализ цепочки блокировок | sys.dm_exec_requests, sys.dm_exec_sessions | Менее минуты, сохраняется исторически | Головной блокиратор и вся зависимая цепочка, представленные в виде дерева. История сохраняется после снятия блокировки, что позволяет проводить послемагентный анализ. |
| Дельта статистики ожидания | sys.dm_os_wait_stats, выборка с интервалами | От 30 до 60 секунд | Скорость изменения показателей PAGEIOLATCH, LCK_M, CXPACKET, SOS_SCHEDULER_YIELD. Накопленные итоги сбрасываются при перезапуске службы или выполнении DBCC SQLPERF с очисткой. Дельта — надёжный сигнал в реальном времени. |
| Кэшированные планы выполнения | sys.dm_exec_query_plan, sys.dm_exec_text_query_plan | По запросу для активных запросов | План, который SQL Server использует в данный момент. Выявляет дорогостоящие операторы, поиск по ключу (key lookups) и сбросы на диск (spills). Используйте sys.dm_exec_query_profiles для статистики на уровне операторов в реальном времени. |
| Анализ хранилища запросов (Query Store) | sys.query_store_plan, sys.query_store_runtime_stats, корреляция через query_hash | Текущий vs исторический агрегат | Регрессии планов, самые ресурсоёмкие запросы по процессору или чтениям, состояние принудительного плана и является ли запрос медленным сегодня или всегда был медленным. |
| Нагрузка на tempdb | sys.dm_db_session_space_usage, sys.dm_db_task_space_usage, sys.dm_exec_requests | 60 секунд | Размер хранилища версий, конфликты распределения страниц и использование tempdb на сеанс. Проблемы с tempdb часто выглядят со стороны приложения как общая медлительность. |
| Здоровье индексов | sys.dm_db_index_usage_stats, sys.dm_db_index_physical_stats, sys.dm_db_missing_index_details | Сбор по расписанию | Уровень фрагментации, отсутствующие индексы, ранжированные по предполагаемому влиянию, и неиспользуемые индексы. Упреждающая видимость помогает предотвратить превращение отсроченного обслуживания в инциденты. |
| Нагрузка на память | sys.dm_os_performance_counters, sys.dm_exec_query_memory_grants | 60 секунд | Устойчивая нисходящая тенденция PLE (ожидаемая продолжительность жизни страницы) и ожидающие распределения памяти. Эти сигналы показывают нагрузку и задержки распределения памяти. |
| Динамические базовые уровни | Собранная история на экземпляр, на показатель | С учётом времени суток для каждого экземпляра | Ожидаемое поведение, построенное на исторических данных. Отклонения вызывают оповещения, в то время как обычные окна высокой активности остаются тихими. |
Диагностический путь от оповещения к первопричине
Путь прост в теории. Оповещение — это отправная точка. Затем должно следовать устойчивое сужение от поверхностного симптома к первопричине, причём каждый уровень предоставляет контекст, необходимый для перехода к следующему шагу.
Анализ цепочки блокировок: поиск головы, а не только хвоста
Когда приложение сообщает о тайм-аутах или медленном отклике, инстинктивно хочется посмотреть, чего именно ждёт приложение. Этот сеанс обычно заблокирован. Но сеанс, которого он ждёт, также может быть заблокирован. А тот, которого ждёт этот, может быть заблокирован кем-то ещё. Чтобы найти реальную причину, необходимо проследить цепочку blocking_session_id через sys.dm_exec_requests, пока не дойдёте до сеанса, который сам не ожидает блокировки, удерживаемой другим.
При работе с динамическими административными представлениями (DMV) это ручной процесс, выполняемый в стрессовых условиях. Инструмент мониторинга, который отображает цепочки блокировок в виде древовидной структуры, позволяет немедленно увидеть головного блокиратора и все зависимые сеансы без написания ни одного запроса. Что более важно, инструмент должен сохранять эту историю, потому что к тому моменту, когда администратор баз данных откроет экран мониторинга, цепочка блокировок может уже исчезнуть.
Событие блокировки длительностью четыре минуты, которое вызвало всплеск ошибок приложения, а затем исчезло, всё ещё чрезвычайно полезно с диагностической точки зрения. Оно сообщает вам, какой запрос удерживал блокировку, какие сеансы ожидали, как долго каждый ждал и когда цепочка очистилась. Это информация, необходимая для того, чтобы проблема не вернулась.
Доступ к плану выполнения во время активного инцидента
Статистика ожидания говорит вам, чего ждёт сервер. Она не говорит вам, какой запрос несёт ответственность или почему этот запрос ведёт себя плохо. Для этого вам нужен план выполнения.
sys.dm_exec_query_plan возвращает кэшированный план выполнения для запроса по его plan_handle. Используемый вместе с sys.dm_exec_requests, он позволяет получить кэшированный план для текущего выполняющегося запроса. sys.dm_exec_text_query_plan возвращает те же данные в форме XML и может изолировать план для конкретной инструкции внутри более крупного пакета. В большинстве инцидентов кэшированного плана достаточно, чтобы объяснить, что идёт не так.
Реальная ценность не в том, что DMV существует. Любой администратор баз данных может выполнить к нему запрос. Реальная ценность заключается в том, чтобы иметь графически отображённый план для любого выбранного активного сеанса, не покидая инструмент мониторинга. План, пострадавший от Sniffing параметров, который был идеален для небольшого результирующего набора, а теперь выполняется для большого, быстро покажет, где возникает проблема.
Здоровье индексов как упреждающая дисциплина
Здоровье индексов — это одна из тех вещей, которые тихо ждут в углу, пока не превратятся в производственную проблему. Фрагментация растёт постепенно. Рекомендации по отсутствующим индексам находятся в sys.dm_db_missing_index_details и ждут внимания, как вежливые стажёры. Неиспользуемые индексы продолжают потреблять место и замедлять операции записи, не создавая особого шума.
Данные доступны. sys.dm_db_index_usage_stats показывает модели доступа. sys.dm_db_index_physical_stats показывает уровни фрагментации. sys.dm_db_missing_index_details показывает, о чём просил оптимизатор. Проблема не в доступности. Проблема в том, что очень немногие администраторы баз данных вручную просматривают всё это на многих серверах и базах данных на регулярной основе.
Инструмент мониторинга, который собирает эту информацию непрерывно и представляет её в приоритизированной форме, меняет операционную модель с реактивной на упреждающую. Бэклог становится видимым до того, как станет полуночным сюрпризом.
Хранилище запросов (Query Store) как историческая запись производительности
Хранилище запросов сохраняет статистику выполнения и историю планов внутри пользовательской базы данных. Для каждого запроса оно хранит количество выполнений, использование процессора, чтения, длительность и историю планов, включая принудительные планы. Оно действует как бортовой самописец для производительности запросов.
Уровень мониторинга, который отображает данные Query Store, предоставляет администраторам баз данных быстрый доступ к регрессиям планов без ручного просмотра представлений Query Store. Корреляция текущих выполнений с историческим поведением позволяет понять, работает ли выполняющийся прямо сейчас запрос в пределах своей нормальной вариативности или отклонился от этого базового уровня.
Запрос, который выполняется медленно и всегда был медленным, требует иного подхода, чем тот, который вчера работал быстро, а сегодня вдруг стал медленным. Это различие меняет весь путь устранения неполадок.
Существенный разрыв на практике
Обычные инструменты мониторинга могут сказать вам, что что-то не так. Диагностическая глубина, описанная выше, включая историю цепочек блокировок, доступ к планам выполнения, динамические базовые уровни, интеграцию с Query Store и видимость здоровья индексов, позволяет администратору баз данных определить, почему что-то не так, и решить, что делать дальше, без переключения между пятью инструментами и десятью вкладками.
Разница между разрешением инцидента за 12 минут и за 90 минут редко заключается в знаниях. Обычно она заключается в доступе к правильному контексту, организованному должным образом, в нужный момент.
Комментариев нет:
Отправить комментарий