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 каждый по отдельности бесплатно предоставляют огромный набор функций. По отдельности или частично, эти продукты не могут решить задачи, которые им по силе в тандеме. Как еще реализовать эту связку, каждый может придумать сам.

ссылка на оригинал статьи http://habrahabr.ru/post/273805/