NetXMS Support Forum

Ne srabativaet, poskol'ku OID .1.3.6.1.4.1.318.0.173 prisutstvuet dvazdi - nado udalit' zapis' nomer 11, i togda vse dolzno stat' horosho.

P.S. Nu i v event policy obrabativat' sobitie "Electrotechnical case open"

I'm only that such reporting is theoretically possible with tools like Crystal Reports, but it's commercial unfortunately Quick search on google also gives me this: http://www.jaspersoft.com/JasperSoft_Products.html - looks like they have open source (or community) version too. Or this one: http://www.pentaho.com/products/ - looks better then first one.

Best regards,
Victor

Things like traffic or errors on switch port are standard, and defined in standard MIBs, already included in NetXMS installation. If you need to collect HP-specific data from switches, then you can add HP MIBs to NetXMS MIB collection, recompile them, and you will be able to select HP-specific oids from MIB tree in console. Searching forum for keyword MIB shold give you some information on how to add new MIBs to the system.

Best regards,
Victor

For basic SNMP-based port monitoring, you can right-click interface object in console and select "Create DCI..." option. Select parameters you want to monitor, click OK, and console will create appropriate DCIs for you. After that, you could use these DCIs as an example for creating your own for other interface stats.

Best regards,
Victor

Hi!

There are no built-in reporting. However, all data stored in SQL database, so you can create your own report using any available reporting tools.

Best regards,
Victor

Hi!

Yes, its the right parameter to set. If you wish to have an email if node is down for 5 minutes or more, you should set it to 5 (it means that 5 status polls should fail, and status polls by default goes every 60 seconds).

Best regards,
Victor

Дополнительный вопрос: а в то время, когда шли 0 вместо нормальных значений, остальные параметры собирались?
У меня тоже обнаружился один сервер, который иногда так себя ведет - раз в неделю примерно. Похоже на проблему с агентом, но я пока-что не могу повторить ее и понять почему так происходит.

При обработке трапов событие ищется только по oid. Если нужно проверять конкретные переменные в трапе, то надо их добавлять в event и делать дополнительные проверки скриптом в event processing policy. Т.е. в описанном случае надо сделать одну запись в trap configuration:

OID = .1.3.6.1.4.1.318.0.173, Parameter bindings $2 = 1.3.6.1.4.1.318.1.1.10.2.3.4.1.2.2

а в event processing policy в скрипте написать например


$2 != ""


тогда правило отработает только если второй параметр будет содержать какое-то значение.

Если нужно просто увеличить значение на 600, то скрипт будет такой:


$1 + 600


GetDCIValue возвращает последнее значение DCI, записанное в базе, а $1 - это переменная, которая содержит текущее значение до трансформации. GetDCIValue используется обычно для трансформации, зависящей от другого DCI - например поделить объем свободной памяти на общий объем памяти и получить процент свободной памяти.

Mozno esche prislat' skrinshoti s konfiguraciej thresholdov dlja problemnih DCI i istoriju sobrannih dannih za period pered vozniknoveniem problemnogo alarma? Dannie mozno cherez export poluchit' v tekstovij fail.

Quote from: Anth0ny on July 21, 2008, 09:44:40 AM
+ ВОПРОС: применительно к мониторингу ресурсов и степени их занятости (заполненности).

Если используется несколько степеней важности (Warning, Minor, Major, Critical) загруженности ресурса, КАК можно указывать автоматом (через макрос) применительно к указанным выше шаблонам текста, что для всех степеней важности Эталонное пороговое значение (Threshold) - своё (понятно, что для каждого статуса - отдельное), а вот при подстановке в текст нужно иметь ввиду, что ОБЩЕЕ эталонное значение- отдельное и для всех одинаковое (нужно брать из статуса Normal)?

объясню:

сободно на диске (Threshold Condition) => 10 гб - Normal
при Threshold Condition =< 9 гб = Warning
при Threshold Condition =< 8 гб = Minor
при Threshold Condition =< 7 гб = Major
при Threshold Condition =< 6 гб = Critical

Соответственно Threshold Condition для каждого Threshold - свой. Но суть в том, что для всех них есть один единый ЛОГИЧЕСКИЙ Threshold, 10 гб. Который определяет НОРМАЛЬНОЕ состояние диска.

Было бы совсем неплохо иметь возможность размер этого базового Threshold подставить в текст... А то получается что в текст сейчас можно подставить только Текущий показатель и его эталонный Threshold.

вопрос возник потому, что у меня используется несколько разных схем мониторинга дисков, где-то - в %, где-то - в абсолютных величинах, при этом к разным серверам - разные требования (у сервером сильно различается объём дисков). а добиться хочется максимальной универсализации...

Это будет возможно начиная с версии 0.2.22 - там появится возможность делать custom attributes для объектов и иметь к ним доступ через скрипты.
Тогда можно будет сделать так:

1. добавить атрибут, скажем, disk_threshold_с
2. при создании сообщения использовать макрос, например, %[print_disk_threshold]
3. сделать скрипт print_disk_threshold:

GetCustomAttribute($node, "disk_threshold_" . $6)


В instance для DCI нужно будет указывать правильное имя диска, и все.

А можно более подробно описать конфигурацию? Или прислать скриншоты?

Дополнительный вопрос: а в Last Values данные показываются правильно? А то у меня есть подозрение что в момент отсылки таких писем сервер получает от агента пустую строку вместо данных и честно ее подставляет...

every 600 seconds means every 10 minutes, so you can put */10 instead of * for minutes in schedule, like


*/10 10-22 * * *


which means "collect value every 10th minute from 10:00 till 22:50".

Best regards,
Victor

Quote from: Victor Kirhenshtein on July 19, 2008, 10:35:16 AM
2. Ошибка в заголовке и теле письма
Описание: не все макросы заполняются данными, и поэтому нарушается подстановка

Шаблон почтового извещения полностью аналогичен предыдущему.

Используемый Event (Message template): Агент NetXMS не отвечает

получаю сообщение:

Subject: Minor (11-Jul-2008 20:01:06): параметр "" на сервере test3.server.ru

ВРЕМЯ ВОЗНИКНОВЕНИЯ: 11-Jul-2008 20:01:06
МЕСТО ВОЗНИКНОВЕНИЯ: test3.server.ru[10.100.143.162]
ИСТОЧНИК СОБЫТИЯ:
СТАТУС СОБЫТИЯ: Minor

Агент NetXMS не отвечает

Нельзя ли хоть чем-нибудь заполнять Event Source? Или это ошибка?

Makrosi %1 .. %9 - eto parametri sobitija. Kolichestvo i znachenie parametrov zavisit ot koda (tipa) sobitija. U sobitija SYS_AGENT_UNREACHABLE net parametrov, poetomu makros %2 raskrivaetsja v pustuju stroku.

Variantov reshenija dva - libo delat' raznie e-mail templeiti dlja raznih tipov sobitij, libo formirovat' zelaemij tekst pri pomoschi scripta.