Zabbix + SoapUI = мониторинг веб-служб
На сегодняшний день существует множество приложений и программных комплексов от разных разработчиков, которые мы используем для решения общих задач. Обмен данными и взаимодействие между приложениями обеспечивают веб-службы. Для тестирования их работы, отладки взаимодействия между собой и клиентскими приложениями также выпущено множество инструментов. Самый популярный из них — SoapUI: он поддерживает SOAP/WSDL, REST, HTTP (S), JDBS, JMS и обладает набором инструментов, которые позволяют сделать тестирование проще и нагляднее. SoapUI выступает как тестовый сервис и тестовый клиент и позволяет тестировать интеграцию подсистем. Подробнее с инструментом можно познакомиться на официальном сайте разработчика.
Если для решения поставленной задачи используется один компьютер и комплекс приложений, поломка ПК или сбой одной из программ выявляется быстро. Но что делать, когда в организации много технических средств и программных продуктов? Физически трудно и очень затратно следить и каждую свободную минуту проверять, всё ли в порядке. Для решения этой задачи приходят на помощь специализированные программные системы, которых в интернете вы найдете очень много: одна из них — Zabbix.
Этот программный комплекс предназначен для отслеживания различных параметров сети и работоспособности технических средств. Если какой-то элемент мониторинга сломается, Zabbix сможет оповестить заинтересованных лиц через e-mail и sms. Подробнее о Zabbix можно прочитать также на официальном сайте разработчика.
Представим ситуацию. В компании используется много технических средств, которые мониторит Zabbix, и различные приложения не собственной разработки, а других IT-компаний. Часть или все эти решения связаны друг с другом и решают одну задачу. Чтобы обеспечить своевременное выявление сбоев в этом множестве элементов и быстро найти место возникновения проблемы, нам необходимо настроить мониторинг веб-служб.
Какие есть варианты?
Первый вариант — используя функционал Zabbix, настроить веб-мониторинг
Этот гайд не о том, как работать с Zabbix, поэтому я шаги буду описывать кратко.
Создаём сценарий.
Настройка — Веб– Создать сценарий.
На вкладке «Сценарий» обязательно заполняем поля «Группа элементов данных» и «Имя» (сценария).
Переходим на вкладку «Шаги», добавляем шаг сценария. Заполняем поля: название шага, URL, код ответа.
В «URL» вписываем адрес нужного веб-сервиса: http://Host: port/Service_name.
В «Код ответа» вписываем »200 OK («хорошо»). Список всех кодов состояния HTTP можно найти здесь
Далее настраиваем триггер на созданный сценарий.
Заполняем обязательные поля: имя триггера и выражение — как показано на рисунке ниже.
Что мы получили в результате? Создали элемент веб-мониторинга — «Test», который опрашивает страницу по указанному в сценарии адресу, и триггер, который сработает, как только веб-служба будет недоступна (т.е. элемент мониторинга «Test» получит код, отличный от »200»).
Этого будет достаточно, если не требуется ничего кроме, как удостовериться, что веб-служба доступна. Но, если нужно отслеживать не только доступность, но и корректность работы, то такой способ не подойдет.
Второй вариант — подружить» Zabbix и SoapUI
Сразу уточню: Zabbix-сервер развёрнут на машине под управлением Linux.
Исходим из того, что SoapUI уже установлен на машине, где крутится Zabbix-сервер. Для примера возьмём некую Soap веб-службу с единственным методом getScore, который по запросу клиента возвращает некую структуру данных: секции с наименованием полей и секции с данными.
Чтобы понять, что веб-служба работает корректно, необходимо задать критерии:
А) метод возвращает корректный ответ;
Б) метод возвращает корректный состав полей в секции полей;
В) метод возвращает не пустой набор данных (секции данных заполнены);
Г) число полей в секциях полей и данных равны;
Первое, что нужно сделать — создать сам тест, которым планируем проверять корректность работы веб-службы. SoapUI позволяет создавать тестовые сценарии для полноценного тестирования веб-служб.
Как видно на скриншоте выше, проверки по критериям А и Б реализуются штатными средствами SoapUI. Для реализации проверок по критериям Б и Г придётся «пошаманить» с элементом SoapUI «Groovy Scripts».
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context );
step=context.testCase.getTestStepAt(1);
def holder = groovyUtils.getXmlHolder(step.name+"#Response");
holder.declareNamespace("scor","http://xml.spss.com/scoring-v2") ;
holder.declareNamespace("rem","http://xml.spss.com/scoring-v2/remote") ;
def columnNamesNode = holder.getDomNodes("//scor:columnNames/scor:name");
def rowValuesNode = holder.getDomNodes("//scor:rowValues");
def ValuesNode = holder.getDomNodes("//rem:getScoreResponse[1]/scor:scoreResult[1]/scor:rowValues[1]/scor:value");
int countNames = columnNamesNode.size();
int countRowValues = rowValuesNode.size();
int countValues = ValuesNode.size();
assert countRowValues>0 : log.error("The Node with name \"rowValues\" is not found in the Response");
assert countNames==countValues : log.error ("The count of elements of the node \"columnNames\" doesn't coincide with count of elements of the node \"rowValues\"!");
Итак, тестовый сценарий для проверки корректности работы веб-службы готов. Осталось заставить Zabbix и SoapUI работать в связке.
Тесты SoapUI можно запускать из консоли. Почему бы не использовать эту возможность?
Ниже приведен листинг скрипта для мониторинга различных сервисов.
#!/bin/bash
## путь к SoapUIPro
pathSoapUIDirectory=/usr/local/soapUIPRO/bin/
## путь к папке Zabbix
pathZabbixDirectory=/etc/zabbix
## путь, где хранятся проекты SoapUI для тестирования веб-служб
pathSoapUiProjectWithName=$pathZabbixDirectory/WebTest/"$1.xml"
## путь к папке, где будут лежать отчеты тестирования веб-служб
pathParentReportDir=$pathZabbixDirectory/SoapReport
## Путь к папке хранения отчетов с разбиением по хостам. Чтобы не перепутать, где лежат отчеты в случае, если одна и та же служба развернута на нескольких хостах
pathReportsDirectory=$pathParentReportDir/"$1"
## чтобы не создавать каждый раз необходимую структуру папок при включении в мониторинг новой веб-службы, создаем структуру папок и выдаем им необходимые права доступа.
if [ -d "$pathParentReportDir" ];
then
chmod 666 "$pathParentReportDir"
else
mkdir "$pathParentReportDir"
chmod 666 "$pathParentReportDir"
fi
if [ -d "$pathReportsDirectory" ];
then
chmod 666 "$pathReportsDirectory"
else
mkdir "$pathReportsDirectory"
chmod 666 "$pathReportsDirectory"
fi
## путь к файлу, в который SoapUI записывает все сценарии, которые не прошли проверки. Он пригодится чуть позднее
searchfile=$pathReportsDirectory/"alltests-fails.html"
## host:port/service_name
endPoint="$2"
## Путь к папке, где лежит источник тестовых данных (файл Excel), если необходимо
pathTestdataDirectory=$pathZabbixDirectory/WebTest/TestData/"$5"
## имя листа в файле-источнике Excel
workSpaceName="$6"
## наименование тестового набора в проекте
testSuiteName="$3"
## наименование тестового сценария в проекте
testCaseName="$4"
## В зависимости от того, какие параметры были указаны при вызове скрипта, формируем команду запуска тестов SoapUI
commandString="sh $pathSoapUIDirectory/testrunner.sh -e $endPoint -s $testSuiteName"
if [ -n "$testCaseName" ]
then
commandString=${commandString}" -c $testCaseName"
fi
commandString=${commandString}" -r -j -f $pathReportsDirectory"
if [ -n "$pathTestdataDirectory" ]
then
commandString=${commandString}" -P pathTestData=$pathTestdataDirectory -P varSpace=$workSpaceName"
fi
commandString=${commandString}" -I $pathSoapUiProjectWithName"
$commandString > $pathReportsDirectory/"$1RunLogs.txt"
## Проверка результатов запуска тестов SoapUI
###For Debug###
#errorString="### ErrorCode: 1 - error of start of the project, 2 - Error of assertions of the tests, 0 - All ok. The returned code:"
#echo "$errorString "$? >> /tmp/"$1RunLogs.txt"
if [ $? -ne 0 ];
then
echo "ErrorOfRunProject" ### По какой либо причине SoapUI не смог выполнить тесты
else
if [ ! -f "$searchfile" ]
then
echo "FileNotFound"
else
if grep -w "Failure" "$searchfile" > /dev/null; then
echo "TestFailure" ### Tests error
else
echo "OK" ### All Ok
fi
fi
fi
Этот скрипт необходимо поместить в папку /externalscripts, чтобы «Zabbix» его увидел, т.к., по умолчанию, внешние скрипты должны лежать именно в этой папке. В нашем случае скрипт «RunTestService.sh» должен лежать в »/etc/zabbix/externalscripts». Необходимо выдать скрипту права доступа на запуск:
sudo chmod 755 /etc/zabbix/externalscripts/RunTestService.sh
Осталось настроить сам Zabbix на работу с этим скриптом. Для этого нужно создать элемент данных с типом «Внешняя проверка».
Так как скрипт возвращает текстовые значения, то в «Типе информации» необходимо указать — «Текст».
«Ключ» выглядит так:
RunTestService.sh["{HOSTNAME}","ScoringProcessTests","{$SCORING.ENDPOINT}","getScoreTestSuite","getScoreTestCase"]
где:
«RunTestService.sh» — наш скрипт;
»{HOSTNAME}» — имя хоста, на котором развернут сервис для разделения отчётов одних служб на разных хостах;
«ScoringProcessTests» — наименование проекта SoapUI для тестирования веб-службы;
»{$ENDPOINT}» — URL веб-службы;
«getScoreTestSuite» — наименование тестового набора сценариев в проекте SoapUI;
«getScoreTestCase» — наименование тестового сценария в проекте SoapUI;
Чтобы Zabbix информировал об обнаруженном сбое веб-службы, нужно настроить триггер.
Триггер будет срабатывать, если элемент данных получит значение, отличное от «OK», а «Zabbix» отобразит в своем интерфейсе факт обнаружения сбоя и оповестит заинтересованных лиц по почте, sms или другим способом. Способ оповещения зависит от потребностей пользователей.
Таким образом, Zabbix и SoapUI каждый по отдельности бесплатно предоставляют огромный набор функций. По отдельности или частично, эти продукты не могут решить задачи, которые им по силе в тандеме. Как еще реализовать эту связку, каждый может придумать сам.
