Содержание

Мониторинг дисков с помощью zabbix
Использование Zabbix для слежения за базой данных MS SQL Server
Предисловие
Решение
Результат

Мониторинг дисков с помощью zabbix

Мониторинг производительности дисковых подсистем с помощью zabbix. Мониторятся следующие параметры.

утилизация блочного устройства в % — удобная метрика для отслеживания общей нагрузки на устройстве;
latency или отзывчивость — доступна как общая отзывчивость, так и отзывчивость на операциях чтения/записи;
величина очереди (в запросах) и средний размер запроса (в секторах) — позволяет оценить характер нагрузки и степень загруженности устройства;
текущая скорость чтения/записи на устройство в человекопонятных килобайтах;
количество запросов чтения/записи (в секунду) объединенных при постановке в очередь на выполнение;
iops — величина операций чтения/записи в секунду;

Для работы нам потребуется утилита iostat входящая в пакет sysstat. Устанавливаем sysstat

Создаем директорию для скриптов

Создаем первый скрипт для сбора метрик

Копируем в него следующий текст

Создаем второй скрипт для парсинга

Даем права на запуск

Создаем файл с ключами zabbix агента

Копируем в него следующие ключи

Скачиваем шаблон для zabbix сервера и устанавливаем.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Использование Zabbix для слежения за базой данных MS SQL Server

Предисловие

Часто возникает потребность в режиме реального времени сообщать администратору о проблемах, связанных с БД (базой данных).

В данной статье будет описано, что необходимо настроить в Zabbix для слежения за базой данных MS SQL Server.

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

Решение

Вначале опишу все те счетчики производительности (через элементы данных в Zabbix), которые нам нужны:

Logical Disk

Avg Disc sec/Read

Zabbix: perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Read], а также важно проследить за нужным диском, например так: perf_counter[\LogicalDisk(C:)\Avg. Disk sec/Read]

Примеры триггеров:
<НАЗВАНИЕ_УЗЛА:perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Read].last()>>0.005, уровень-высокий
и
<НАЗВАНИЕ_УЗЛА:perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Read].last()>>0.0025, уровень-средний

Avg Disc sec/Write
Показывает выраженное в секундах среднее время записи данных на диск. Среднее значение счетчика производительности Avg. Disk sec/Write не должно превышать 10 миллисекунд. Максимальное значение счетчика производительности Avg. Disk sec/Write не должно превышать 50 миллисекунд.

Zabbix: perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Write], а также важно проследить за нужным диском, например так: perf_counter[\LogicalDisk(C:)\Avg. Disk sec/Write]

Cредняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков Avg. Disk Read Queue Length (очередь запросов на чтение) и Avg. Disk Wright Queue Length (очередь запросов на запись).
Значение Avg. Disk Queue Length не измеряется, а рассчитывается по закону Литтла из математической теории очередей. Согласно этому закону, количество запросов, ожидающих обработки, в среднем равняется частоте поступления запросов, умноженной на время обработки запроса. Т.е. в нашем случае Avg. Disk Queue Length = (Disk Transfers/sec) * (Avg. Disk sec/Transfer).

Avg. Disk Queue Length приводится как один из основных счетчиков для определения загруженности дисковой подсистемы, однако для его адекватной оценки необходимо точно представлять физическую структуру системы хранения. К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RAID-массиве из 4-х дисков, то волноваться стоит при значении больше 4*2=8.

Zabbix: perf_counter[\LogicalDisk(_Total)\Avg. Disk Queue Length], а также важно проследить за нужным диском, например так: perf_counter[\LogicalDisk(C:)\Avg. Disk Queue Length]

Memory

Pages/sec

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

Zabbix: perf_counter[\Memory\Page Faults/sec]
Пример триггера:
<НАЗВАНИЕ_УЗЛА:perf_counter[\Memory\Page Faults/sec].min(5m)>>1000, уровень-информация
Available Bytes

Отслеживает количество доступной памяти в байтах для выполнения различных процессов. Низкие показатели означают нехватку памяти. Решение — увеличить память. Этот счётчик в большинстве случаев должен быть постоянно выше 5000 КВ.
Есть смысл выставлять порог для Available Mbytes вручную из соображений:

•50% свободной памяти доступно = Отлично
•25% доступно памяти = Требует внимания
•10% свободно = Возможны проблемы
•Меньше 5% доступно памяти= Критично для скорости, нужно вмешиваться.
Zabbix: perf_counter[\Memory\Available Bytes]

Processor (Total): % Processor Time
Этот счетчик показывает процентное отношение времени, которое процессор был занят выполнением операций для не простаивающих потоков (non-Idle thread). Эту величину можно рассматривать как долю времени, приходящегося на выполнение полезной работы. Каждый процессор может быть назначен простаивающему потоку, который потребляет непродуктивные циклы процессора, не используемые другими потоками. Для этого счётчика характерны непродолжительные пики, которые могут достигать 100 процентов. Однако, если наблюдаются продолжительные периоды, когда утилизация процессора выше 80 процентов, то система будет более эффективной при использовании большего числа процессоров.

Zabbix: perf_counter[\Processor(_Total)\% Processor Time], здесь же может иметь место по ядрам выводить
Пример триггера:
<НАЗВАНИЕ_УЗЛА:perf_counter[\Processor(_Total)\% Processor Time].min(5m)>>80, уровень-информация

Network Interface (*): % Bytes Total/sec
Общее количество переданных и полученных байт за секунду по всем интерфейсам. Это пропускная способность интерфейса (в байтах). Необходимо сравнить значение этого счётчика с максимальной пропускной способностью сетевой платы. Вообще, этот счётчик должен показать не более 50% утилизации пропускной способности сетевого адаптера.
Zabbix: perf_counter[\Network Interface(*)\Bytes Sent/sec]

MS SQL Server: Access Methods
Объект Access Methods (Методы доступа) в SQL Server предоставляет счетчики, помогающие следить за доступом к логическим данным в рамках базы данных. Физический доступ к страницам базы данных на диске контролируется при помощи счетчиков диспетчера буферов. Наблюдение за методами доступа к данным в базе данных помогает определить, можно ли увеличить производительность запросов путем добавления или изменения индексов, добавления или перемещения секций, добавления файлов или групп файлов, дефрагментации индексов или изменения текста запросов. Кроме того, при помощи счетчиков объекта Access Methods можно следить за размером данных, индексов и свободного пространства в базе данных, контролируя объем и фрагментацию для каждого экземпляра сервера. Чрезмерная фрагментация индексов может значительно снизить производительность.

Page Splits/sec
Количество разбиений страниц в секунду, выполненных в результате переполнения страниц индекса. Большое значение этого показателя означает, что при выполнении операций вставки и изменения данных SQL Server приходится выполнять большое количество ресурсоемких операций по разбиению страниц и переносу части существующей страницы на новое место. Таких операций по возможности следует избегать. Проблему можно попытаться решить двумя способами:
— создать кластерный индекс для столбцов с автоприращением. В этом случае новые записи не будут помещаться внутрь страниц, уже занятых данными, а будут последовательно занимать новые страницы;
— перестроить индексы, увеличив значение параметра Fillfactor. Этот параметр позволяет зарезервировать в страницах индексов свободное место, которое будет использоваться для размещения новых данных, без необходимости производить операции разбиения страниц.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access Methods\Page Splits/sec»,30]
Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access Methods\Page Splits/sec",30].last()>><НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:SQL Statistics\Batch Requests/sec",30].last()>/5, уровень-информация
Full Scans/sec
Количество неограниченных операций полного сканирования в секунду. К таким операциям относятся сканирование основной таблицы и полное сканирование индекса. Стабильное повышение этого показателя может свидетельствовать о деградации системы (нехватка нужных индексов, их сильная фрагментация, неиспользование оптимизатором существующих индексов, наличие неиспользуемых индексов). Однако, стоит отметить, что полное сканирование в небольших таблицах невсегда плохо, т к если удается всю таблицу разместить в ОЗУ, то как раз быстрее будет произвести полное сканирование. Но в большинстве случаев стабильный рост показателя этого счетчика будет говорить о деградации системы. Все это применимо только для OLTP-систем. В OLAP-системах постоянные полные сканирования-это нормально.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access Methods\Full Scans/sec»,30]

MS SQL Server: Buffer Manager
Объект Buffer Manager (диспетчера буферов) предоставляет счетчики, позволяющие наблюдать за тем, как SQL Server использует следующие ресурсы:
— память для хранения страниц данных;
— счетчики, служащие для мониторинга физического ввода-вывода, когда SQL Server считывает и записывает страницы баз данных;
— расширение буферного пула для расширения буферного кэша с использованием быстрой энергонезависимой памяти, например твердотельных накопителей (SSD);
— мониторинг памяти и счетчиков, используемых SQL Server, помогает получить следующие сведения;
— существуют ли «узкие места», вызванные недостатком физической памяти. Если часто используемые данные не могут быть сохранены в кэше, SQL Server вынужден считывать их с диска;
— можно ли повысить эффективность выполнения запросов, увеличив объем памяти или выделив дополнительную память для кэширования данных или хранения внутренних структур SQL Server;
— насколько часто SQL Server считывает данные с диска. В сравнении с другими операциями, такими как доступ к памяти, физический ввод-вывод выполняется дольше. Уменьшение объема ввода-вывода может повысить производительность выполнения запросов.

Buffer Cache hit radio
Показывает, насколько полно SQL Server может разместить данные в буфере кэша. Чем выше это значение, тем лучше, т.к. для эффективного обращения SQL сервера к страницам данных, они должны находиться в буфере кэша, и операции физического ввода-вывода (I/O) должны отсутствовать. Если наблюдается устойчивое снижение среднего значения этого счётчика, необходимо рассмотреть возможность добавления ОЗУ. Данный показатель всегда должен быть выше 90% для OLTP-систем и выше 50% для OLAP-систем.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Buffer cache hit ratio»,30]
Примеры триггеров: <НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Buffer cache hit ratio",30].last()>=0)
and (<НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\Processes blocked",30].time(0)>>=50000)
and ( <НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\Processes blocked",30].time(0)>=500, уровень-информация
Lock Wait Time (ms)
Суммарное время ожидания блокировок (в миллисекундах) за последнюю секунду.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Wait Time (ms)»,30]
Lock Waits/sec
Количество случаев за последнюю секунду, когда потоку приходилось ожидать в связи с запросом блокировки.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Waits/sec»,30]
Lock Timeouts/sec
Количество повторений, когда не удается получить блокировку путем циклического обращения. Значение параметра конфигурирования SQL Server spin counter определяет количество «оборотов» потока (spins), прежде чем истечет время тайм-аута и поток перейдет в неактивное состояние.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Timeouts/sec»,30]
Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Locks(_Total)\Lock Timeouts/sec",30].last()>>1000, уровень-информация
Lock Requests/sec
Количество запросов в секунду указанного типа блокировки.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Requests/sec»,30]
Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Requests/sec",30].last()>>500000, уровень-информация
Lock Number of Deadlocks/sec
Количество запросов блокировки в секунду, приводящих к взаимоблокировке. Наличие взаимоблокировок свидетельствует о неправильно построенных запросах, которые блокируют совместные ресурсы.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Number of Deadlocks/sec»,30]
Пример триггера: <НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Number of Deadlocks/sec",30].last()>>1, уровень-высокий

MS SQL Server: Memory Manager
Объект Memory Manager (Диспетчер памяти) в Microsoft SQL Server обеспечивает счетчики для контроля использования памяти всего сервера. Контроль над использованием памяти всего сервера для оценки действий пользователя и использования ресурсов может помочь идентифицировать нехватку производительности. Контроль над памятью, используемый экземпляром SQL Server, может помочь определить:
— существуют ли нехватки в недостаточной физической памяти для хранения в кэше часто используемых данных. Если памяти недостаточно, SQL Server должен получить данные с диска;
— может ли производительность запроса улучшиться, если будет добавлена память или увеличится объем доступной памяти для кэширования данных или внутренних структур SQL Server.

Memory Grants Outstanding
Указывает общее число процессов, успешно получивших память рабочей области. При стабильном падении показателя, необходимо увеличить ОЗУ.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Memory Manager\Memory Grants Outstanding»,30]
Memory Grants Pending
Указывает общее число процессов, ожидающих предоставления памяти рабочей памяти. При стабильном росте показателя, необходимо увеличить ОЗУ.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Memory Manager\Memory Grants Pending»,30]

MS SQL Server: Statistics
Объект Statistics (Статистика) в Microsoft SQL Server обеспечивает работу счетчиков для наблюдения компиляции и типов запросов, отправляемых экземпляру SQL Server. Наблюдение за числом компиляций и повторных компиляций запросов и числа пакетов, полученных экземпляром SQL Server, дает представление о том, как быстро SQL Server выполняет запросы пользователей и насколько эффективно их обрабатывает оптимизатор запросов.

Batch Requests/sec
Число пакетов команд Transact-SQL, полученных за секунду. На эту статистику влияют любые ограничения (ввод-вывод, число пользователей, размер кэша, сложность запросов и т. д.). Высокое число запросов пакетов свидетельствует о высокой пропускной способности.
Zabbix: perf_counter[«\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:SQL Statistics\Batch Requests/sec»,30]

Помимо всего выше перечисленного также можно настроить и другие элементы данных (а также и создать триггеры по ним с последующим оповещением).Например:
1) размер свободного места на диске
2) размеры БД-файлов данных и журнала лога
и т. д.
Однако, все эти показатели не показывают проблему именно запросов в реальном времени.
Для этого необходимо создавать свои специальные счетчики.
Из-за соображений конфиденциальности, не буду приводить примеры таких счетчиков. Тем более, что они настраиваются уникально для каждой системы. Но отмечу, что для таких систем как 1С, NAV и CRM специализированные счетчики создать можно совместно с соответствующими разработчиками.
Приведу пример создания обобщенного показателя, который показывает сколько запросов выполняется и сколько запросов ожидают выполнения (приостановлены или заблокированы) на каждый момент времени.
Для этого необходимо создать хранимую процедуру:

Теперь необходимо создать файл с пользовательскими параметрами и расширением .conf (или добавить строчки в существующий такой пользовательский файл, если он был создан ранее) и вставить следующие строки:
UserParameter=НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ВЫПОЛНЯЕМЫХ_ЗАПРОСОВ,powershell -NoProfile -ExecutionPolicy Bypass -File ПОЛНЫЙ_ПУТЬ\zabbix\conf\userparams.d\НАЗВАНИЕ_ФАЙЛА_ДЛЯ_ВЫПОЛНЯЕМЫХ_ЗАПРОСОВ.ps1
UserParameter=НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ОЖИДАЮЩИХ_ЗАПРОСОВ,powershell -NoProfile -ExecutionPolicy Bypass -File ПОЛНЫЙ_ПУТЬ\zabbix\conf\userparams.d\НАЗВАНИЕ_ФАЙЛА_ДЛЯ_ОЖИДАЮЩИХ_ЗАПРОСОВ.ps1
После этого сохраняем файл .conf и перезапускаем агент Zabbix.
После этого добавляем в Zabbix новых два элемента (в данном случае названия и ключ совпадают):
НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ВЫПОЛНЯЕМЫХ_ЗАПРОСОВ
НАЗВАНИЕ_ПАРАМЕТРА_КОЛИЧЕСТВО_ОЖИДАЮЩИХ_ЗАПРОСОВ
Теперь можно создавать графики и триггеры на созданные пользовательские элементы данных.

Если кол-во ожидающих запросов резко возрастает, то следующим запросом можно вывести все выполняющиеся и ожидающие запросы в данный момент времени с детализацией от куда и под каким логином выполняется запрос, текст и план запроса, а также прочие детали:

Результат

В данной статье был рассмотрен пример счетчиков производительности (элементы данных) в Zabbix. Данный подход позволяет уведомлять администраторов о разных проблемах в реальном времени или через какое-то определенное время. Таким образом, данный подход позволяет минимизировать в будущем наступления критической проблемы и остановки работы СУБД и сервера, что в свою очередь защищает производство от остановки рабочих процессов.
Предыдущая статья: Регламентные работы с базой данных информационной системы 24×7 в MS SQL Server

Zabbix очередь диска windows

Мониторинг дисков с помощью zabbix

Использование Zabbix для слежения за базой данных MS SQL Server

Предисловие

Решение

Результат