Приветствую!
Возникло некоторое непонимание с "ServiceCheck.HTTP".
Действовал согласно 2 части инструкции (https://www.netxms.org/forum/index.php/topic,28.0.html).
Привожу свою русскую интерпретацию (это не перевод):
QuoteМониторинг web-сервера возможен без добавления его в базу NetXMS как ноды (возможно, предполагается мониторить ресурс: на котором нет клиента NetXMS, который находится вне вашей сети или который находится не в вашем подчинении).
1) Для уже существующего в базе объекта-ноды (это может быть например сам сервер NetXMS) необходимо создать DCI (источник - агент NetXMS):
DCI: ServiceCheck.HTTP(server_ip_address,port,uri,host_header,response)
Замечание: При использовании метода "ServiceCheck.HTTP" невозможно использование URL, обязательно должен использоваться URI (в том числе для запроса к корню сайта), т.е.:
www.google.com - не правильно
www.google.com:/ - правильно
Далее в примерах вместо DNS-имени используется ip-адрес, но суть ограничения от этого не меняется.
Пример использования 1 (запрос к корню web-сервера):
ServiceCheck.HTTP(209.85.135.147,80,/,www.google.com,"^HTTP/1\.[01] 200.*")
Пример использования 2 (запрос к файлу test.html в корне сервера, файл должен существовать!):
ServiceCheck.HTTP(209.85.135.147,80,/test.html,www.google.com,"^HTTP/1\.[01] 200.*")
Пример использования 3 (запрос к файлу test.html в корне сервера, файл должен существовать, ищем на полученной странице слово "maps"):
ServiceCheck.HTTP(209.85.135.147,80,/test.html,www.google.com,"^HTTP/1\.[01] 200.*maps*")
Данный запрос может вернуть несколько значений:
0 - удача (соединение с сервером установлено и получен ожидаемый ответ)
1 - использованы неверные аргументы (в основном если неправильно написан RegExp)
2 - невозможно соединиться с сервером
3 - получен неправильный ответ сервера
Для процессинга ответов DCI, отличных от "0", можно создать threshold'ы.
Для сведения: для использования данного вида опросов на сервере NetXMS (если опрос идёт именно с него) требуется наличие субагента "portchecker". В случае с платформой Windows данный субагент уже присутствует и загружен по умолчанию. В случае с платформой UNIX вам нужно убедиться, что в конфиге агента NetXMS присутствует что-то вроде этого:
SubAgent = /usr/local/lib/libnsm_portCheck.so
А теперь вопрос: при условии что я всё правильно понял (см. мою интерпретацию) у меня в процессе тестирования данного метода мониторинга возникла проблема с обнаружением на странице нужных мне слов.
Тут всё просто: мой web-сервер в процессе работы генерирует статическую страничку со списком пунктов, на которой html-тегами типа <red> и <green> (для пущей наглядности проверяющему) помечаются проблемы в работе сайта, существующие на момент генерации этого статического html-файла. И мне была поставлена задача в автоматическом режиме обнаруживать на этой страничке слово <red> средствами мониторинга NetXMS. Вроде судя по описанию, задачка проста.
Однако не тут-то было. Как я не изгалялся, получить адекватный результат мне так и не удалось. DCI всегда возвращает "0". Всегда, как бы не менялось содержимое проверяемой странички!
Мой DCI:
ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*red*")
Есть на странице слово "red" - получаю "0".
Нет на странице "red" - тоже получаю "0".
Складывается впечатление, что DCI возвращает не указанные ранее 4 значения, а просто отчёт о состоянии DCI (0 - выполнено успешно). Я ведь правильно понял, что в случае, если DCI не находит искомое слово на странице, я должен получить значение "3" (получен неправильный ответ сервера)?
Или как DCI должна отчитываться, что ответ от сервера отличается от заданного в RegExp'е запроса?
Прошу помочь разобраться с проблемой.
up.
прошу помочь разобраться с проблемой.
???
Esli DCI imenno takoj, kak v poste:
Quote from: Anth0ny on June 30, 2008, 10:30:38 AM
Мой DCI:
ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*red*")
Есть на странице слово "red" - получаю "0".
Нет на странице "red" - тоже получаю "0".
to v nem oshibka. REgexp
.*red* matchit bukvi re, za kotorimi mozet idti ili ne idti bukva d, posle chego mozet idti chto ugodno. T.e. slova rexx, retry, centered, i t.d. toze smatchatsja. Ochen' bol'shaja verojatnost', chto na etoj stranice vstrechaetsja kombinacija bukv re, poetomu vsegda 0 i vozvraschaetsja.
Pravil'nej budet
.*red.*, hotja slovo centered vse ravno podojdet. Dlja testov rekomenduju vzjat' html, propuskat' cherez grep i smotret', pravil'nij li rezul'tat.
Best regards,
Victor
Виктор, Вы гений =)
Действительно, для тестов использовалась пустая страница, где было только одно слово: red или green
Сейчас попробую сделать так, как Вы сказали.
Спасибо!
А всё-таки что по кодам возврата?
Что должно вернуться если условие regexp'а не выполнено но сайт работает корректно?
Т.е. что вернёт DCI если в моём случае нет слова "red" на странице?
Если 0 (мол, запрос отработал удачно), то можно ли как-то изменить это положение вещей, чтобы я однозначно видел, какой именно ответ вернуло выполнение regexp'а (что заданное в regexp условие было отправлено и полученный результат или TRUE или FALSE ?)
А то всё время 0 да 0 ... Не удобно, право слово...
ТЕСТ НЕ ПРОЙДЕН: после модификации запроса на .*red.* всё вроде бы отработало успешно. Однако возвращаемый результат по прежнему - 0. True regexp или false - всё равно возвращается 0. если условие Threshold'а говорит, что если ответ = 0 -> ошибка, то при любых словах на странице DCI помечается как обнаруживший искомое.
нет эффекта. изменение слова на текстовой странице не влияет на получаемый результат: всегда получаю 0 и соответственно отрабатывает только правило, обнаруживающее что получено значение 0.
складывает впечатление что в моём конкретном случае это не работает.
что red что green на странице- всегда возвращается 0.
и почему-то не могу завершить процессинг эвента...
не работает правило, прерывающее обработку. может дело в том что всегда возвращается 0 (чтобы не получил regexp) и дальше тупо нечего процессить? Потому что 0 - это TRUE, при котором считается что RED найдено. А если не найдено, то всё равно получаю 0.
дополнительный комментарий:
даю скрины, чтобы было понятно о чём спич.
1. строка проверки на наличие слова RED на странице:
ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*red.*")
При выполнении DCI всегда возвращается 0, а значит НЕЛЬЗЯ настроить прерывание для Event'а.
2. скрин Theshold'а, как это сейчас настроено
3. скрин Event Processing'а - Alarm
4. скрин Event Processing'а - терминатор для Alarm'а
Regexp proverjaet ne tol'ko content stranici, no i header'i. Vot otvet moego web-saita:
HTTP/1.1 200 OK
Date: Fri, 04 Jul 2008 08:05:22 GMT
Server: Apache
X-Powered-By: PHP/4.4.0-pl1-gentoo
Set-Cookie: supraLang=en; expires=Sun, 19 Jul 2009 13:05:23 GMT; path=/
Set-Cookie: PHPSESSID=afa2bbc5cdf668e7db85c92b04cfea2d; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 7658
Connection: close
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
i dal'she idet content
zagolovok X-Powered-By: PHP/4.4.0-pl1-gentoo prekrasno matchitsja regexpom .*red.*. Vozmozno v vashem headere chto-to podobnoe. Mozno poprobovat'
^HTTP/1\.[01] 200.*<html.*red.* - togda mi budem iskat' slovo red tol'ko posle taga <html>.
Виктор, спасибо за быстрый ответ!
О проблеме: моя тестовая страница совершенно пуста. там вообще нет тегов. это просто текстовый файл с расширением html и одним-единственным тестовым словом. вообще, как мне кажется, дело тут не в том, что находит-ли искомое regexp или не находит, а в том, что в ответ на запрос с regexp'ом всегда возвращается "0".
Нашёл? = 0
Не нашёл? = 0
Моё условие Вы уже видели: если на странице встречается слово "red" - должно быть зафиксировано событие (Event), что слово "red" найдено. Затем запускается процессинг, который отсылает мне извещение, что слово на странице найдено.
И всё бы хорошо, да только у Threshold'а, который использует этот regexp, нет другого возвращаемого состояния, кроме как "0". А это значит, что DCI не в состоянии отличить состояние "найдено" last()=0 от "не найдено" last()l=0.
И соответственно я не могу создать условие-терминатор, которое бы тоже опиралось на возвращаемое состояние и заканчивало бы обработку данного эвента (помечало DCI как нормально рабюотающий). Не на что опираться, потому что всегда получаем 0.
применительно к моему тестированию: ищем слово red, если находим- проблема, если нет- всё ок.
Threshold Configuration
----------------------
Condition
Will be "Equal"
Than "0"
----------------------
Event
Condition TRUE
Site test Filed!
Condition FALSE
Site test OK!
----------------------
Я собственно вот о чём...
=)
Нужно ввести возвратные коды для такого рода Threshold'ов.
0 - условие regexp'а полностью выполнено (искомое найдено).
1 - условие regexp'а не выполнено (искомое не найдено)
Это возможно? А то невозможно понять что вообще происходит...
=)
вот ответ моего тестового сайта:
Quote
http://www.intwww.local/worktest.html
GET /worktest.html HTTP/1.1
Host: www.intwww.local
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,ru;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Wed, 02 Jul 2008 10:12:27 GMT
If-None-Match: "b17d7e212cdcc81:c90"
HTTP/1.x 304 Not Modified
Server: Microsoft-IIS/5.1
Date: Wed, 02 Jul 2008 11:41:16 GMT
X-Powered-By: ASP.NET
Etag: "b17d7e212cdcc81:c90"
Content-Length: 0
хмм.. тоже присутствует X-Powered-By
а как же тогда быть?
как заставить искать только конкретное слово, БЕЗ совпадений?
просто получается, что найдя искомое, Threshold пометит хост в соответствии со значением, заданным ему при помощи Event'а. А как же перевести его в обратное состояние, в то, которое предшествовало новому?
т.е. как в данном случае в автоматическом режиме пометить хост как нормальный, если искомое не обнаруживается при следующем опросе?
я даже проверил поиск абстрактным словом "^HTTP/1\.[01] 200.*blablablabla.*"
не получается. если условия настроены так как сказано выше (при ответе = 0 -> проблема), то при каждом запросе получаю именно состояние "Проблема".
а всё-таки Вы оказались правы!
если я ищу слово blablablabla а его нет на странице, я получаю ответ "3"!
если добавляю- получаю 0 - и хост помечается проблемным.
если снова убираю- хост помечается как нормальный.
соответственно прошу меня извинить, был не прав. :-\
усиленно бью челом.
всё работает так как заявлено.
ещё раз ОГРОМНОЕ спасибо за помощь и проявленное при этом нечеловеческое терпение.
Pozalujsta :) Mne toze prijatno chto rezul'tati moej raboti komu-to nuzni :)
Вот ещё реализуете работу с логами windows и тогда вообще уже практически нечего будет желать =).
offtop: что там насчёт 0.2.22? =)
когда нам ожидать (примерно) и что нового будет в релизе?
Esli so vremenem vse budet ok, to na sledujuschej nedele.
Poka izmenenija takie:
V sobitijah, alarmah i actionah mozno budet ispol'zovat' skripti dlja formirovanija teksta (v vide macro %[script_name]);
Skripti v event processing policy poluchat dostup k attributam nodi i samogo sobitija cherez peremennie $node i $event;
Dobavlena podderzka custom attributes dlja ob'ektov (t.e. mozno opredelit' svoj attribut skazem u nodi i potom ispol'zovat' v skriptah;
Dobavlena vozmoznost' kodirovki NXCP soobschenij v XML i utilita nxcptest;
Ispravleni zaregistrirovannie bugi #196, #201, #216, #220, #221.
Sobirajus' esche poispravljat' bagov i realizavat' koe-chto iz feature requests.
Quote from: Anth0ny on July 03, 2008, 01:00:29 PM
Вот ещё реализуете работу с логами windows и тогда вообще уже практически нечего будет желать =).
Есть чего желать. И даже больше виндовых логов. Очень актуальна возможность фильтрации и сортировки событий за произвольный период. И реакция на события сислога.
2 Виктор: удачи! очень надеемся что время всё же будет. и Вы реализуете всё что запланировали. и даже больше. ;)
2 Isherim: нуу.. в общем да, ты прав.
было бы здОрово иметь эти возможности.
хотя, в принципе, что касаемо сортировки и фильтрации давно минувших событий то тут я не уверен, что это сильно нужно. как опция- да. не не как самоцель. так как мониторинг в первую очередь интересен своей оперативностью и информативностью. а копаться в старом белье... имхо не так уже это и важно. важнее то, что происходит с контролируемыми нодами здесь и сейчас.
и поэтому реакция на SysLog очень даже интересна.
тут полностью согласен.
Quote from: Victor Kirhenshtein
^HTTP/1\.[01] 200.*<html.*red.* - togda mi budem iskat' slovo red tol'ko posle taga <html>.
Виктор, вопрос:
ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*
<body.*red.*")
я правильно понял Вашу мысль?
будет такой запрос искать слово red начиная с тега
<body id="popup"> ?
возникла следующая проблема: запрос не работает если страница, к которой он обращается, выглядит следующим образом (это исходник полученной страницы).
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:x="http://www.w3.org/1999/xhtml" xml:space="x">
<head>
<link rel="stylesheet" type="text/css" href="/css/firefox/main.css" media="screen"/>
<link rel="stylesheet" type="text/css" href="/css/firefox/popup.css" media="screen"/>
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />
<script type="text/javascript" src="/MonoRail/Files/AjaxScripts.visp"></script>
<script type="text/javascript" src="/MonoRail/Files/BehaviourScripts.visp"></script>
<!-- Behaviours -->
<script type="text/javascript">
<!--//--><![CDATA[//><!--
function writeX( parNode, elem, val)
{
var par = document.getElementById(parNode);
if( val && par)
{
var p = document.createElement( elem);
try
{
p.innerHTML = val;
par.appendChild(p);
}
catch(e){}
}
}
document.write = function (s)
{
writeX( "counters", "span", s);
}
function addSpyLog()
{
writeX( 'counters', 'span', '<a href="http://u10123.54.spylog.com/cnt?cid=1012354&f=3&p=0" onclick="window.open(this.href); return false;"><img src="http://u10123.54.spylog.com/cnt?cid=1012354&p=0" alt="SpyLOG" border="0" width="88" height="31"/></a>');
}
function validateMail( mail)
{
var pattern = new RegExp("[\.\-_A-Za-z0-9]+@([\.\-_A-Za-z0-9]+)+(\.[A-Za-z0-9]{2,6})+");
return pattern.test(mail);
}
function getElementsByClass(searchClass,node,tag)
{
var classElements = new Array();
if (node == null) node = document;
if (tag == null) tag = '*';
var els = node.getElementsByTagName(tag);
var elsLen = els.length;
var pattern = new RegExp("(^|\\s)"+searchClass+"(\\s|$)");
for (i = 0, j = 0; i < elsLen; i++)
{
if (pattern.test(els[i].className) )
{
classElements[j] = els[i];
j++;
}
}
return classElements;
}
function setCursorPosition(oInput,oStart,oEnd)
{
if (oInput.setSelectionRange)
{
oInput.setSelectionRange(oStart,oEnd);
}
else if (oInput.createTextRange)
{
range = oInput.createTextRange();
range.collapse(true);
range.moveEnd('character', oEnd);
range.moveStart('character',oStart);
range.select();
}
}
function focusSearch()
{
var elem = getElementsByClass('textformFields',null,'input');
if (elem.length > 0)
{
elem[0].focus();
setCursorPosition(elem[0], elem[0].value.length, elem[0].value.length);
}
return true ;
}
function focusFirstField()
{
var elem = document.getElementsByName("focusField");
if (elem.length > 0)
{
var el = elem[0];
el.focus();
}
return false;
}
function bannerPublicView()
{
var publicBanner = document.getElementById('publicBanner');
if(publicBanner)
{publicBanner.style.display = "none";}
}
function onloadDefault()
{
focusSearch();
bannerPublicView();
addSpyLog();
}
function supportEMailView()
{
var oFrame = $('mailframe');
if (oFrame)
{
var frmHeight = window.innerHeight;
var frTop = (frmHeight/2-260);
oFrame.style.display = 'block';
oFrame.style.height = '520px';
oFrame.style.width = '520px';
oFrame.style.top = frTop +'px';
oFrame.src="/support/supportframe.visp";
}
return false;
}
//--><!]]>
</script>
</head>
<body id="popup">
<h1>Монитор работоспособности ресурса IQLib</h1>
<h2>Получение файлов из хранилища фондов</h2>
<div class='green'><b>Успешно</b></div>
<h2>Получение файлов из хранилища баннеров</h2>
<div class='green'><b>Успешно</b></div>
<h2>Соединение с SQL-сервером</h2>
<div><b><span class='red'>IQLib.Site: OK</span><br/><span class='green'>IQLib.Site.Sys: OK</span><br/><span class='green'>IQLib.Users: OK</span><br/><span class='green'>IQLib.Statistic.Raw: OK</span><br/></b></div>
<h2>Выполнение запросов к поисковой системе и получение документов</h2>
<div><b><span class='green'>IQLib.XBook: OK</span><br/><span class='green'>IQLib.XRef: OK</span><br/></b></div>
<h2>Выполнение распределенной транзакции SQL-сервером</h2>
<div class='green'><b>Успешно</b></div>
<h2>Тестирование сервисов на сервере приложений</h2>
<div><b><span class='green'>Job: [Days] Garbage Collector: OK</span><br/><span class='green'>Job: [Days] Publishing Remove: OK</span><br/><span class='green'>Job: [Hours] Publishing Add: OK</span><br/><span class='green'>Job: [Hours] Statistic Collector: OK</span><br/><span class='green'>Job: [Minutes] Statistic Collector: OK</span><br/><span class='green'>Job: [Weeks] Statistic Collector: OK</span><br/><span class='green'>Send Message Service: OK</span><br/><span class='green'>User Query Execute Service: OK</span><br/><span class='green'>User Query Notify Service: OK</span><br/></b></div>
<br/>
<p>
<strong>Дата выполнения теста:</strong> 07.07.2008 10:33:01
</p>
<div class="more green" title="Повторить тест"><a href="/monitor/view.visp">Повторить тест</a></div>
</body>
</html>
Как только убираю всё, что завёрнуто в
<HEAD>, так запрос начинает работать нормально и обнаруживает слово red на этой странице. В чём может быть проблема, не подскажете?
Я собственно потому и спросил выше, можно ли начать просмотр с тега <body> а не с <html>. Чтобы не парсить заголовок.
с предыдущей проблемой разобрались: при внимательном осмотре нашего файла в коде был замечен regexp. очевидно NetXMS на может завернуть один regexp в другой (согласен- это очень-очень частный случай, не баг). и изза этого не отрабатывает как положено. пофиксили, убрав из кода страницы лишние элементы (указанные regexp'ы). всё отлично работает.
но в процессе дальнейшего углублённого тестирования столкнулись со следующей проблемой (правда, может это и не проблема а наш собственный косяк, но тогда нужен совет Мастера):
1. мы мониторим веб-страницу при помощи запроса
ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*<html.*red.*")
2. для обработки ответов сервера на DCI созданы Event'ы, WWW_NOK (Not OK, слово "red" обнаружено, нода переводится в статус Warning) и WWW_OK (слово "red" не обнаружено, нода переводится в статус Normal).
и у нас возникла проблема с процессингом:
условия:
- при мониторинге 1 раз в минуту время от времени на запрашиваемой монитором странице проявляются ошибки, которые носят случайный (а не систематический) характер. но увеличивать интервал между опросам мы не можем (нас 1 минута устраивает)
- мы НЕ ХОТИМ реагировать на кратковременные ошибки-всплески (в общем случае, при следующем обращении к тестовой странице на ней уже всё хорошо)
- мы НЕ ХОТИМ, чтобы почта отправлялась сразу же после обнаружения на странице слова "red" и перевода ноды в статус Warning (Event = NOK)
(между прочим, данная ситуация характерна не только для этого конкретного случая. как я уже писал, данную стратегию можно использовать при любых запросах, связанных с текущими показателями производительности, которые имеют обыкновение также скочкообразно и кратковременно возрастать при увеличении нагрузки)
в соответствии с документацией, мы решили задействовать поле Timeout в Processing Policy и решить данную задачу с его помошью.
для этого мы:
- создали ещё один Event, WWW_WARN (статус - Normal), и прописали его в Procrssing Policy, где для этого Event'а мы указали в Action акцию "mailto" (заранее созданная операция по отправке почтового извещения оператору).
- для Event'а WWW_NOK в поле Seconds ставим значение 300 а в поле Event мы выбираем WWW_WARN
я ведь правильно понимаю, что указав в поле Seconds "300" и указав в поле Event наше событие "WWW_WARN" мы должны получить тот эффект, что при наступлении события WWW_NOK наш DCI с запросом помечается как проблемный, почта отправлена не будет (для WWW_NOK не указана Action), а вот при истечении указанных 300 секунд должно быть обработано событие WWW_WARN и тогда почта будет отправлена?
соответственно, мы должны получить нужный эффект: если в течение указанных 300 секунд статус DCI вернётся к состоянию Normal при помощи события "WWW_OK" , то почта о сбое вообще не будет отправлена, так как согласно нашей логике срабатывание на ошибку будет выглядеть как СЛУЧАЙНОЕ срабатывание на кратковременную проблему (пиковую загрузку) и ошибка сама рассосалась в пределах 300 секунд. Соответственно, ручное вмешательство оператора не требуется. но в логах обнаружение проблемы будет отмечено.
мм... надеюсь понятно объясняю... да-с.
так вот. а что мы имеем на самом деле?
1. при задании в поле Seconds любого значения, не равного "0" срабатывание происходит мгновенно, без указанной отсрочки.
2. какой бы Event мы бы не указывали в поле Event, ВСЕГДА в Event Log'е появляется сообщение, что сработало событие именно SYS_ALARM_TIMEOUIT. и как я уже сказал- срабатывание происходит мгновенно, без учёта поля Seconds.
складывается впечатление, что не срабатывают поля:
Seconds- не даёт отсрочки по запуску ДОПОЛНИТЕЛЬНОГО Event'а
Event - не запускает указанное в нём событие на обработку
соответственно, мы не можем добиться нужного эффекта "ОТЛОЖЕННОГО" извещения (которое не будет выслано, если проблема сама рассосалась в указанные временные рамки в поле Seconds).
дальше-больше =)
пробовал привязать отправку сообщения к этому событию SYS_ALARM_TIMEOUIT, но опять же получаю мгновенную отправку сообщения, а не отложенную на 300 секунд.
кроме того, прошу обратить внимание на то, что для использования поля Timeout обязательно необходимо включить в Alarm'е поле "generate New Alarm", а тогда нода помечается как Outstanding. вопрос в том, как потом ВЫВЕСТИ её из этого состояния? ведь нам нужна только операция по запуску дополнительного события, а не пометка ноды, как сбойной...
А так же есть проблема с ALARM_TIMEOUT: этот Event помечает ноду как Outstanding, а вот автоматического способа вернуть ноду из Outstanding в состояние Normal для этого Event'а мы не нашли...
Прошу помочь разобраться, в чём именно моя ошибка и каким образом можно добиться эффекта "Отложенного" извещения, которое высылается только если проблема не рассосалась в течение указанных 300 секунд...
UP
Виктор, нужна Ваша помощь...
прошу прощения за настойчивость, но предыдущий вопрос всё ещё актуален.
UP.
V alarm timeout'ah dejstvitel'no bil bag, i ne odin: vo pervih, timeout ne sobljudalsja i srabatival nemedlenno, vo vtorih - vsegda posilalsja event SYS_ALARM_TIMEOUT. Vrode vse ispravil, rabotaet kak nado.
Chto kasaetsja alarmov, kotorie ostajutsja na node, to mozno ved' sdelat' avtomaticheskij terminate cherez kljuchi - ja tak ponjal chto u vas tak i sdelano, chto WWW_OK avtomaticheski terminiruet alarm, sozdannij po WWW_NOK. Pri zelanii vi mozete sdelat' toze-samoe i po WWW_WARN, esli ne hotite chtobi alarm ostavalsja aktivnim posle otsilki meila.
Виктор, спасибо! =)
Усиленно ждём 0.2.22.
Виктор, приветствую!
Возникла следующая проблема.
Есть 4 одинаковых web-сервера. На них одинаковая ОС и набор софта. Задача: нужно через ServiceCheck.HTTP мониторить на всех 4ёх серверах один и тот же файл, находящийся у всех серверов в одном и том же месте и называющийся одинаково для всех серверов.
примерно так:
сервера: www01.test.local, www02.test.local, www03.test.local и www04.test.local
файл: /load/test.xml
используемый regexp (для www01.test.local):
ServiceCheck.HTTP(10.101.123.1,80,/load/test.xml,www01.test.local,"^HTTP/1\.[01] 200.*<?xml.*/cross-domain-policy.*")
содержимое страницы (текст):
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="testdom.local" />
<allow-access-from domain="site.dmz.off" />
<allow-access-from domain="*" />
</cross-domain-policy>
HTTP-заголовок:
http://www01.test.local/load/test.xml
GET /load/test.xml HTTP/1.1
Host: www01.test.local
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,ru;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
If-Modified-Since: Fri, 05 Sep 2008 07:15:29 GMT
Cache-Control: max-age=0
HTTP/1.1 200 OK
Via: 1.1 PROXY
Content-Length: 314
Date: Mon, 08 Sep 2008 05:05:30 GMT
Content-Type: text/xml
Server: nginx/0.5.33
Last-Modified: Fri, 05 Sep 2008 07:15:29 GMT
Accept-Ranges: bytes
Собственно проблема в следующем: на 2 серверах данный запрос получает и обрабатывает данные корректно, а на ещё 2ух- нет. Разницы как я уже сказал между серверами нет. Программно и аппаратно они идентичны.
Не понятно ещё вот что: если regexp на 2ух странных серверах урезать до определения только статуса ответа HTTP (200), то тогда запрос на них работает (получаем "0"). Но как только в запрос добавляется поиск слов в тексте страницы - всё, начинаем получать "3". И никакие ухищрения не помогают =(. Пока есть текст в запросе- запрос всегда выдаёт "3", убираем текст (остаётся только проверка на HTTP-ответ, ищем 200) - всё отлично, "0"...
Повторяюсь: на 2ух серверах полный запрос работает прекрасно!
Виктор, не можем понять что происходит.
Написали скрипт на Unix-сервере, что бы проверить код regexp'а:
if($response=~/^HTTP\/1\.[01] 200.*<?xml.*\/cross-domain-policy.*/s) {
print "Match!\n";
}
Скрипт говорит что с нашим запросом всё в порядке: полученный от сервера ответ содержит всё необходимое.
Просим помощи... ???
Я посмотрел в коде - да, есть такая бага. Сейчас несколько переделаю субагента и выложу дифф.
спасибо, ждём-с =)
а можно рекомпильнуть субагента?
Файл в аттаче. Надо положить в корень дистрибутива (e.g. netxms-0.2.22/) и запустить:
patch -p0 < /путь/к/portcheck.diff
Я погонял на файлах разного размера и с разных серверов - вроде проблем нету.
Про сборку только субагента - если не чистили каталог из которого делали make install - то можно после патча пойти в src/agent/subagents/portCheck и сделать оттуда make install - субагент должен пересобраться и поставиться. Если из чистого дистрибутива - то для ускорения можно сделать configure --with-agent, сборка пройдет быстрее (но foundation libraries и core agent тоже будут собраны - как зависимости).
аа.. эээ... а если у меня сервер Win32...?
я так вижу что имеется ввиду *nix...
???
Мда, это я не подумал.
Виктор в ближайшее время выложит новый бинарник субагента.
Peresobrannij subagent dlja Windows.
Спасибо! Залито и проверено- работает так как должно.