Мониторинг баз данных MS SQL можно выполнять с помощью агента Zabbix, отправляя данные счетчиков производительности СУБД, но помимо этого существует возможность отслеживать показатели доступности и работоспособности баз и в agentless-конфигурации

Содержание

1 Мониторинг баз данных MS SQL
1.1 Теория
1.2 Окружение
1.3 Подготовка сервера Zabbix
1.3.1 Установка драйвера
1.3.2 Настройка конфигурации
1.3.3 Проверка
1.4 Настройка элемента данных
1.5 Устранение неисправностей
1.5.1 Брандмауэр Windows
1.5.2 Сетевая конфигурация MS SQL
1.5.3 Telnet — наше все
1.5.4 Ошибки подключения на Zabbix Server
1.6 Режимы проверки подлинности MS SQL

Мониторинг баз данных MS SQL

Помимо официальной документации, при написании статьи использовались и другие источники 1 2.

Теория

В безагентной конфигурации Zabbix Server имеет возможность выполнять обращения к удаленным серверам баз данных. При этом используемая СУБД может быть любой, но обязательно с поддержкой программного интерфейса доступа к базам данных (Open Database Connectivity — ODBC).

MS SQL Server, разумеется, поддерживает ODBC. И это неудивительно, ведь Microsoft была в числе инициаторов создания и разработчиков этого API.

К сожалению, из коробки Zabbix не сможет выполнять запросы к MS SQL (да и к любой другой СУБД) и поэтому необходимо произвести ряд настроек, о чем ниже.

Окружение

Для демонстрации возможностей я подготовил отдельную лабу, в которой присутствует свежий Zabbix Server 3.4 на Debian 9 и отдельная виртуальная машина с Microsoft SQL Server 2014 Express.

В качестве ODBC будет использован самый свежий Microsoft ODBC Driver for SQL Server на Linux, но в интернете широко доступны варианты и с другими драйверами 3. Также можно найти и готовые шаблоны с LLD 4.

Подготовка сервера Zabbix

Microsoft хорошо постаралась и задокументировала процесс установки драйвера 5, при этом нигде не засветив примеров использования (что вообще очень странно). Основные шаги установки ниже (выполняйте под рутом).

Установка драйвера

Добавляем ключ в доверенные:

curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add —

Подключаем репозиторий:

curl https://packages.microsoft.com/config/debian/9/prod.list > /etc/apt/sources.list.d/mssql-release.list

curl https://packages.microsoft.com/config/debian/9/prod.list > /etc/apt/sources.list.d/mssql-release.list

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

apt-get update && ACCEPT_EULA=Y apt-get install msodbcsql17

apt-get update && ACCEPT_EULA=Y apt-get install msodbcsql17

Все остальные шаги опциональны.

Настройка конфигурации

Для проверки конфигурации выполните команду:

odbcinst -j
unixODBC 2.3.4
DRIVERS…………: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /root/.odbc.ini
SQLULEN Size…….: 8
SQLLEN Size……..: 8
SQLSETPOSIROW Size.: 8

Посмотрим содержимое файла odbcinst.ini

cat /etc/odbcinst.ini
[ODBC Driver 17 for SQL Server]+
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.1.so.0.1
UsageCount=2

Обратите внимание на заголовок в квадратных скобках — ODBC Driver 17 for SQL Server — и запомните его, он понадобится далее.

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

odbcinst i d f /etc/odbcinst.ini
Проверьте регистрацию:
odbcinst q d n «ODBC Driver 17 for SQL Server»

Результатом выполнения команды должно быть отображение на экране содержимого файла odbcinst.ini.

Далее вам нужно создать и зарегистрировать источник данных. Для этого используем файл из конфигурации, предложенный по умолчанию — /etc/odbc.ini — который изначально пустой. Открываем его для редактирования и вставляем содержимое:

[mssql01]
Description = ms sql test+
Driver = ODBC Driver 17 for SQL Server
Server = tcp:172.16.100.25,1433
User = test01
Password = tratata
Database = master
Примечание: обратите внимание на имя драйвера, выше я просил вас запомнить его. Имя источника данных — mssql01 — понадобится далее.

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

Зарегистрируем источник данных:

odbcinst i s f /etc/odbc.ini
Проверим регистрацию:
odbcinst q s n mssql01
Результат выполнения команды — содержимое файла /etc/odbc.ini

Проверка

Проверим все ли получилось. Для начала подключимся к удаленной СУБД:

isql v mssql01 test01 tratata
Должно появиться приветствие:
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+

Выполним простой запрос:

SQL> select count(*) from [sys].[databases];
SQL-запрос отображает количество доступных на сервере баз данных
+————+
|            |
+————+
| 4          |
+————+
SQLRowCount returns 0
1 rows fetched

На пустом MS SQL этих баз будет 4 штуки, что мы и видим в результатах. Если подключиться не удается и вы видите ошибки, переходите к разделу Устранение неисправностей ниже в статье.

Настройка элемента данных

Рассмотрим базовый вариант элемента данных, использующего ODBC-проверку. Для этого создайте новый шаблон или используйте существующий. Перейдите в Элементы данных — Создать элемент данных:

Небольшие пояснения:

  • odbc_check_01 — идентификатор элемента данных (вы можете задать любой на свой вкус);
  • mssql01 — имя источника данных, которое мы определили в /etc/odbc.ini;
  • SQL-запрос должен возвращать одно значение.

Обратитесь к официальной документации6, если у вас остались какие-то вопросы.

Последний шаг — подцепить шаблон к хосту СУБД. Вот такой график данных у вас должен появиться:

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

Примечание: привяжите в зависимость триггер доступности хоста, если будете использовать проверку .nodata() в триггере, чтобы он срабатывал лишь в том случае, если хост пингуется, но запрос выполнить не может. Такое поведение будет однозначно свидетельствовать о проблемах на стороне СУБД.

Если до счастливого момента создания первых элементов данных ODBC вы так и не дошли, напоминаю, что глава ниже как раз для вас.

Устранение неисправностей

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

Брандмауэр Windows

На стороне MS SQL вам нужно обеспечить свободный сетевой доступ с Zabbix Server. Если СУБД изначально настроена для работы по сети, то проблем возникнуть не должно, но если у вас свежая инсталляция, то первым делом добавьте разрешающее правило в брандмауэр. Сделать это проще всего командой:

netsh advfirewall firewall add rule name=«1433» dir=in action=allow protocol=TCP localport=1433

Либо используйте оснастку Windows Firewall.+

Сетевая конфигурация MS SQL

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

После этого вы должны будете, наконец, увидеть строчку в выводе команды netstat -a:

TCP 0.0.0.0:1433 hostname listening

Теперь переходите в консоль Zabbix Server и читайте следующую главу.

Telnet — наше все

СУБД установлена, порт открыт и прослушивается, самое время проверить подключение с Zabbix Server. Сначала воспользуемся утилитой telnet:

# telnet 172.16.100.25 1433

Trying 172.16.100.25…
Connected to 172.16.100.25.
Escape character is ‘^]’.

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

Ошибки подключения на Zabbix Server

Пришло время вернуться к проверке удаленного подключения к СУБД. Напомню команду:

isql v mssql01 test01 tratata
Но и тут все может пойти не совсем гладко и подключение не пройдет.
Примечание: если у вас используется не английская версия MS SQL, могут возникнуть проблемы с кодировкой и на стороне Zabbix Server вы будете получать абсолютно неинформативные сообщения об ошибках, состоящие из бессвязного набора символов, совсем как в примере ниже.
[28000][unixODBC][Microsoft][ODBC Driver 17 for SQL Server][SQL Server]H81:0 2E>40 ?>;L7>20B5;O «test01».
[ISQL]ERROR: Could not SQLConnect

В любом случае наличие имени пользователя в ошибке (test01) должно вас насторожить и заставить проверить права доступа для юзера. Самый простой способ это сделать — открыть консоль Microsoft SQL Server Management Studio и попытаться подключиться под нужным пользователем.

Режимы проверки подлинности MS SQL

Администраторам MS SQL хорошо знакомо, что у этой СУБД существуют несколько режимов проверки подлинности. Но если у вас используется имя пользователя MS SQL, а сервер принимает только учетки Windows, то непременно возникнет проблема.

Примечание: самый удобный вариант — смешанный — когда для проверки подлинности могут использоваться как Windows-учетные записи, так и учетки MS SQL.
Например ошибка в предыдущей главе на стороне MS SQL выглядит следующим образом
Измените режим проверки подлинности 8 или используйте соответствующие учетные записи