Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Victor Kirhenshtein

#7636
Quote from: cme on August 17, 2007, 01:47:55 AM
Second question:

I have the event SYS_THRESHOLD_REACHED let's say for this CPU monitoring...
If I further want to watch the DiskUsage.. (if it's above 90%)
Do I have to create another new event like this or use another one?
So do I have to create such a event for every "thing" that is watched?
Example:
CPU -> CPU_TOO_HIGH -> action: email "CPU of PC123 too high.."
Disk -> DISK_FULL -> action: "Disk of PC123 too full.."
..

Yes, it's the main idea - you create different events for different thresholds, so you can process them differently. After NetXMS installation you already have some example events for threshold violations - their names starts with DC_ prefix.

Also, you may create different events for different thresholds (for example HIGH_CPU_USAGE and LOW_DISK_SPACE), but handle them identically - for example, write one rule in event processing policy:

add both HIGH_CPU_USAGE and LOW_DISK_SPACE to event field;
in alarm generation field as alarm text use %m macro, which will expand to actual event's text.

With this approach, you can have relatively simple event processing policy but use meaningful texts in alarms and messages.
#7637
Quote from: cme on August 17, 2007, 01:47:55 AM

One task of NetXMS will be to inform the admin about any (already added in NetXMS) PC of the net which has a
CPU usage of more than 80%.
I already know that I can add the usage in "data collection" --> then add a rule in event processing policy editor with
action "SYS_THRESHOLD_REACHED" that send an static text via email to the admin.

Now do I have to do these steps for every host?

I want to do that dynamically that in the mail the hostname will be shown like
"CPU of PC23 is above 80%..."

Hello!

You can achieve this using templates:
1. Create template object (in Templates subtree)
2. In data collection configuration for template object, create DCI for CPU utilization as usual
3. Apply template to nodes where you wish to check CPU utilization

In event processing policy, you can use macros in alarm texts. For example, if you wish to include node name and actual CPU utilization in alarm (or e-mail text, etc.), you may write your text like this:
CPU utilization on node %n is %4%%

%n will be replaced by node name, %4 by actual DCI value, and %% with single % character. You can find complete list of available macros in User's Manual (section 8.6) or here:
https://www.netxms.org/documentation/macros.shtml

Best regards,
Victor
#7638
Общие вопросы / Re: NetXMS FAQ/ЧаВо
August 17, 2007, 09:17:49 AM
Очередной баг :( Должен был быть параметр --with-oracle, но я забыл его добавить. Исправлю в 0.2.19.
#7639
Теперь понял  :) У каждого threshold'a есть два события - одно генерируется когда threshold активируется (условие выполняется), второе - когда деактивируется (условие больше не выполняется). Соответственно в качестве реакции на первый event делаем аларм с неким ключом, а на второй - terminate alarm по тому-же ключу. Я обычно поступаю следующим образом: в качестве activate event'ов на разные threshold'ы использую разные event'ы но когда делаю из них алармы то использую одинаковый шаблон для ключа: DC_%i_%5; как deactivation event использую всегда только стандартный SYS_THRESHOLD_REARMED, и в качестве реакции делаю terminate alarm по ключу DC_%i_%3. Таким образом, при нарушении порогового значения аларм создается, а при возврате к нормальному уровню - удаляется.
#7640
Если мы используем первый вариант, то трешолдов не должно быть. В поле Alarm для события SYS_IF_UP ставим "terminate alarm" и ключ из правила для SYS_IF_DISABLED.
#7641
Так как они видны в Network -> Properties, например Local Area Connection.
#7642
General Support / Re: Tranform and Condition Scripts
August 10, 2007, 07:37:47 PM
Quote from: jdlds on August 10, 2007, 04:44:06 AM

Another issue i've encountered is using the PDH.countervalue for data collection.  This seems to work fine for some counters but not others.

I tried: '\Memory\Committed Bytes' and this seems to work just fine
but when i tried
'\PhysicalDisk(_Total)\Disk Write Bytes/sec' this always returns 0.

if anyone can shed some light on this, that would great.


Some counters (like physical disk counter you mention or CPU utilization counters) requires at least two samples to be taken to calculate value. Such counters should be polled in background by agent. To configure agent to do so, use Counter parameter in WinPerf section, like below:

*WinPerf
Counter = DiskWriteBytes:"\PhysicalDisk(_Total)\Disk Write Bytes/sec":60:A:INT:Average number of bytes per second written to disk for last minute

There are several fields separated by colons (:). First is the name for new parameter (DiskWriteBytes in our example); second is counter path; third is number of samples to calculate average value - minimum is 2, and in our example it's 60 (because we need average value for last minute); fourth field is a collection class - it can be either A (collect values every second), B (collect values every 5 seconds), or C (collect values every 30 seconds); fifth field is a data type - it's only a hint for "select parameter" dialog in console and is not used by agent; and sixth field is a parameter description which will be shown in parameter selection dialog.

After you define your new counter, you can access new parameter on agent by using name specified in the first field.

Best regards,
Victor
#7643
General Support / Re: Tranform and Condition Scripts
August 10, 2007, 07:26:13 PM
Hello!

If you write non-trivial scripts (i.e. something more than single expression like $1/1024) you should define main() function. So you script should looks like this:

sub main()
{
   if ($1>5) return min($2, $3);
}

btw, you should return something also in case  when $1>5 is false, so final form will be

sub main()
{
   if ($1>5)
      return min($2, $3);
   return 0; // Or any other default value
}

Best regars,
Victor
#7644
На каждый интерфейс при configuration poll приходится примерно 5 SNMP запросов/ответов. Похоже просто наконец-то сложилась ситуация когда ни один из ~ 25000 запросов не завершился с ошибкой... Вообщем думать надо и оптимизировать.
#7645
Это можно сделать через ExternalParameter в агенте. В конфиге агента пишем

ExternalParameter = MyParameterName:my_script

После чего можем определить DCI для параметра MyParameterName на ноде где стоит агент. При каждом запросе параметра будет вызываться скрипт. Значением будет первая строчка выданная скриптом на stdout.
#7646
Т.е. на ноде больше 5000 интерфейсов? Похоже что у сервера проблема когда их так много. Буду думать как такие ситуации обрабатывать.
Кстати, что выдаст
nxsnmpget -v 2c -c community node .1.3.6.1.2.1.2.1.0
?
#7647
Вариантов два: или при обработке SYS_IF_DISABLED указываем ключ IF_DOWN_%i_%1, тогда правило обработки SYS_IF_UP этот аларм уберет, или указываем ключ IF_DISABLED_%i_%1, тогда добавляем еще одно правило обработки SYS_IF_UP, но указываем auto-termination для ключа IF_DISABLED_%i_%1.
#7648
Похоже на баг в сервере. А можно ли попробовать такую команду:

nxsnmpwalk -v 2c -c community node .1.3.6.1.2.1.2

заменив community на реальный SNMP community и node на адрес ноды.
Если IP адреса не секрет, то можно прислать все что выдаст мне на мейл (victor -at- opticom.lv), или просто отработалы без ошибок или в конче выдала какое-нибудь сообщение.
#7649
Default login is admin and password is netxms (all small letters).
Btw, this is mentioned in Installation Guide on page 20  :)

Best regards,
Victor
#7650
Quote from: Alex on August 03, 2007, 03:31:10 PM
Можно ли помечать весь объект красным цветом, если к примеру отключается поток E1 в ручную? т.е. переходит в состояние DISABLED?

Можно. В event policy добавляем обработку события SYS_IF_DISABLED для нужной ноды и в качестве действия создаем аларм с приоритетом CRITICAL. Чтобы автоматически его убирать, обрабатываем событие SYS_IF_UP и в качестве реакции на него делаем terminate alarm.

Альтернативный вариант - определяем DCI для Internal параметра ChildStatus(<имя или id объекта интерфейса>) и ставим threshold c генерацией какого-либо event'a. Дальше обрабатываем event как и в первом варианте.