Основновной и дочерний сервера

Started by Alex, May 06, 2011, 04:22:28 PM

Previous topic - Next topic

Alex

Ребят, вопрос на засыпку. А можно ли как-то сделать связку основного и резервного сервера? Т.е. есть один сервер, который будет основным, и с него будут высылаться алерты в случае необходимости, но второй сервер при этом должен молчать. Если же основной по какой-либо причине первый сервер не работает или не отвечает (выключен для переустановки ПО или еще чего), то эту роль берет на себя второй сервер и алерты высылаются уже с него. Но в том случае, если первый сервер работает, то никаких алертов чтоб от второго сервера не было, чтоб он тихо и мирно собирал статистику.
Возможно ли это?

Victor Kirhenshtein

Да, можно. Надо на втором сервере настроить мониторинг состояния первого, сделать ситуацию (например "Primary Server Down") c атрибутом, обозначающим текущий статус основного сервера (например "isDown"), и добавить следующие правила:

1. Если основной сервер не доступен или на нем нет необходимых процессов, выставляем isDown для ситуации "Primary Server Down" в 1;
2. Если основной сервер снова работает, выставляем isDown для ситуации "Primary Server Down" в 0;
3. Здесь два варианта:
3а. В самом начале делаем правило, которое проверяет, равно ли isDown для ситуации "Primary Server Down" 0, и если да, то делает stop processing - таким образом фактически события не обрабатываются пока первый сервер работает;
3b. К каждому правилу для отсылки алертов добавляется доп. проверка на равенство isDown для ситуации "Primary Server Down" 1.


Alex

Виктор, а Вас не затруднит показать пример в картинках?
Потому что не совсем понятно где прописываются правила. Если в Events Processing Policy, то как там установить параметр IsDown=1? Если в поле Situation, то он остается пустым, потому что нельзя указать Situation Name из списка (он пуст).

Спасибо заранее.

Victor Kirhenshtein

Комментарий к картинкам:

1. Идем в меню View -> Situations, там создаем новый объект "Primary Server Down". Получаем картинку 1.
2. Идем в event processing policy, создаем два правила с Source=NETXMS-PRIMARY, event=SYS_NODE_DOWN, и Source=NETXMS-PRIMARY, event=SYS_NODE_UP. Для первого правила поле "Situation" редактируем как на картинке 2, для второго - как на картинке 3.
3. Создаем правило с единственным условием в виде скрипта:


s = FindSituation("Primary Server Down", "default");
if (s != NULL)
{
return (s->isDown == 1);
}
return false;


и флагом "Stop processing". Все 3 правила видны на картинке 4.

Надеюсь стало понятней :)

Alex

Виктор, это все отлично. Смысл теперь стал прозрачно понятен.
Еще вопрос такой.. В случае отключения NetXMS на мастере, сама NODE-а будет активной, и соответственно эти правила срабатывать не будут. Как привязать еще проверку на работу сервиса NetXMS на Primary Server?

Victor Kirhenshtein

Ja sdelal SYS_NODE_DOWN bol'she dlja primera. A tak ja vizu tri sposoba:

1. monitorit' sostojanie processa netxmsd i tcp porta 4701, esli to ili drugoe ne v porjadke, vistavljat' isDown;
2. Sdelat' na lokal'nom agente vtorogo servera external parameter, kotorij dergaet server cherez kakoj-nibud' klientskij tool, naprimer nxalarm, i esli tot daet failure, to schitae, chto server ne rabotaet;
3. Sdelat' na udalenom servere external parameter, kotorij zapuskaet nxadm -c "show status", esli ne otrabotal - znachit server ne rabotaet.

Nu ili ob'edinit' vse tri dlja nadeznosti. S tochki zrenija event processing policy prosto dobavjatsja novie sobitija k pervim dvum pravilam.

Alex

Виктор, все понятно.
Но вот нарисовалась еще одна проблема.
Прописал портЧек
[17-May-2011 14:35:37] Log file opened
[17-May-2011 14:35:37] Debug level set to 0
[17-May-2011 14:35:38] Subagent "/usr/local/lib/libnsm_linux.so" loaded successfully
[17-May-2011 14:35:38] Subagent "/usr/local/lib/libnsm_portCheck.so" loaded successfully
[17-May-2011 14:35:39] Listening on socket 0.0.0.0:4700
[17-May-2011 14:35:40] NetXMS Agent started

но ни где не появляется ServiceCheck.Custom :(
Может где-то в другом месте это настраивается?
Спасибо.

Victor Kirhenshtein

A configuration poll delasli posle dobavlenija subagenta?

Alex

Да, делал. в настройках DCI для Origin: Internal нет такого значения как ServiceCheck

Victor Kirhenshtein

A pochemu internal? Eto ved' parametr agenta, t.e. dolzen bit' origin "agent".

Alex

О! Точно! Этот момент пропустил. :)
Спасибо, все нашел. ))

Alex

Подскажите еще пожалуйста, как проверять в Events Policy состояние значения DCI?

Спасибо.

Victor Kirhenshtein

T.e. pri obrabotke kakogo-to sobitija nado proverit' tekuschee znachenie DCI? Togda nado dobavit' filtering script, i v nem poluchit' tekuschee znachenie pri pomoschi funkcij FindDCIByName/FindDCIByDescription i GetDCIValue - tochno takze, kak v transformation scripte.

Alex

Ага, понял, попробую завтра сделать )))