NetXMS Forum

Ну тут всё просто. Надо понять netxms, прежде, чем что-то от него хотеть. В который раз уж пишу.

I wonder is there any reasons left to use snmp transport in such cases. We can get all interesting information from $node object and its child interfaces:

i = GetInterfaceObject($node, $1);
if (i != null && i->adminState == 1)
{
  return %(true, $1, i->name);
}
return false;

Это ещё какое решение, просто вам надо бы поглубже посмотреть в сторону nxsl, посоны.

http://wiki.netxms.org/wiki/NXSL:Interface

У объекта Interface появилось свойство alias, есть name, появились незадокументированные методы setStatusPropagation / setStatusCalculation.

http://wiki.netxms.org/wiki/NXSL_Function_Reference#Object_Management

Тут есть SetInterfaceExpectedState, ManageObject, UnmanageObject.

Cначала прикинем типовой сценарий: вот если это маршрутизатор Cisco, а интерфейс Tu* или Fa*, то этот интерфейс мне не особо критичен, если это Di*, Nu0, Lo* - то вообще игнорим, а вот Gi* мне очень интересны.

Осталось - написать скрипт, который, в зависимости от ваших предпочтений, сделает интерфейсу i:
  - если совсем не интересует - UnmanageObject (i),
  - если интересует, но не совсем - SetInterfaceExpectedState (i, "IGNORE"),
  - если интересует - i->setStatusPropagation (4,1,2,3,3),
  - если интересует очень - оставит всё по-умолчанию.

if (i->node->sysDescription ~= "^Cisco")
{
  if (i->name ~= "^Nu|^Di|^Lo")
  {
    UnmanageObject (i);
  } else  if (i->name ~= "^Fa|^Tu")
  {
    i->setStatusPropagation (4,1,2,3,3);
  } else  if (! i->name ~= "^Gi")
  {
    SetInterfaceExpectedState (i, "IGNORE");
  }
}

Можно без всей этой автоматизации, врукопашную. Но, если узлов тысячи, а тут у некоторых есть такие инсталляции, то придётся тяжко.

PS:

setStatusPropagation (4,1,2,3,3) соответствует картинке, которую я приаттачил.

---

Сборка юникодовая зачем?

Юникод принципиален, вы с китайцами, чтоль, работаете?

У меня, после того, как поисчезало из дерева объектов всё то, что по-русски забивал, UNICODE сборка не прижилась. После перезапуска сервера пошла ругань на SQL запросы, и так далее.

Сейчас CP1251 + pgsql, и всё ок, но "осадочек" остался. Надо бы ещё потерзать UNICODE, но времени паталогически не хватает.

О, это было бы неплохо, а то мы тут уже кучу эклипсов перебрали.

Может, в раздел downloads оба? У меня на стационаре Win64, на буке Lin64.

Пока второй день дрючу ковыряю Eclipse. После Idea жутковато. Хотя бы запустить консоль уже было бы достижением, потому что с зависимостями я там потерялся совсем.

Я выбираю 1, т.к. было бы интересно посмотреть на костыль. Создавать на каждый DCI свой dummy, суммирующий предыдущие, а потом эти Dummy вывалить на график?

По второму пункту. Что именно подсказывает? Про rrd и min/avg/max разговоры идут давно. Самим пора делать.

Приветики. Продублирую здесь:

1. Нужен push в nxsl, сейчас работает через action / nxapush (за появление -o в котором отдельное спасибо)
   https://www.netxms.org/forum/feature-requests/nxsl-improvements/

2. Cisco-related просьба. Хотелось бы надеяться на появление атрибута ifAlias в объекте Interface. UseInterfaceAliases приводит, если честно, к бардаку, как в картах, так и дереве объектов. Сейчас использую Custom Attributes, вызов из хука:

sub ifUpdateAlias(root)
{
	transport = CreateSNMPTransport(root);
	if (transport == null)
	{
		println "Failed to create SNMP transport, exit";
	}

	foreach(o : GetObjectChildren(root))
	{
		if (classof(o) == "Interface")
		{
			index = o->ifIndex;
			value = SNMPGetValue(transport, "1.3.6.1.2.1.31.1.1.1.18." . index);
			if (value != null)
			{
			   SetCustomAttribute (o, "ifAlias", value);
			}
		}
	}
}

3. Чтение / запись Comments, Status Calculation из nxsl.

4. https://www.netxms.org/forum/oe-oo/filtering-script-for-rule-in-event-processing-policy/msg12217/#msg12217

Когда-то раньше main() был обязателен, теперь уже нет. Но старая форма все равно поддерживается.

Было бы неплохо, если бы main() вызывался при включении скрипта директивой use.

У меня такое было, когда я удалял "левые" клоны узлов, появившиеся в результате network discovery. Т.е. оставишь одну нужную ноду, и появляется "unknown". Лечилось перезапуском сервера.

Возможно, сислоги действительно приходят с другого IP, неизвестного NetXMS. У меня перед NetXMS прослойка из rsyslog, который раскладывает логи по каталогам с IP-адресом устройства.

nxevent + trace - куда прямее?

enp, настоятельно рекомендую уже быстрее проникнуться концепцией NetXMS.

Передать $event из командной строки нельзя, но можно сгенерировать событие (из скрипта - PostEvent, из командной строки - утилитой nxevent), на которое среагирует обработчик, в котором есть фильтрующий скрипт.

Создай тестовый объект, тестовое событие, тестовый обработчик, и т.д.

Плюс - очень острой стала необходимость в push непосредственно из nxsl, как это обсуждалось в https://www.netxms.org/forum/feature-requests/nxsl-improvements/

А у меня немного другое затруднение. Хотелось бы иметь возможность в nxevent указать объект не только по его ID, но и как в nxpush - по системному имени, IP, dns.

А у меня проблема несколько глубже, и я даже не знаю, то ли лыжи не едут, то ли я чего-то понять не могу.

Без libusb агент бесперебойник видит, и выдаёт почти всё, кроме UPS.OnlineStatus.

С libusb под xp32 вот такое:

[WARN ] UPS: Cannot establish communication with device #0 "USB-ANY"

При всём при том:

upsc.exe ups1
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2010/08/14
battery.mfr.date: 2010/08/14
battery.runtime: 2085
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 13.6
battery.voltage.nominal: 12.0
device.mfr: American Power Conversion
device.model: Back-UPS ES 525
device.serial: 4B1033P19388
device.type: ups
driver.name: usbhid-ups
driver.parameter.bus: bus-0
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: Back-UPS ES 525 FW:851.t3.I USB FW:t3
driver.parameter.productid: 0002
driver.parameter.serial: 4B1033P19388
driver.parameter.vendor: American Power Conversion
driver.parameter.vendorid: 051D
driver.version: 2.6.5-3723:3731M
driver.version.data: APC HID 0.95
driver.version.internal: 0.37
input.sensitivity: medium
input.transfer.high: 255
input.transfer.low: 195
input.voltage: 228.8
input.voltage.nominal: 230
output.voltage.nominal: 2300.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 851.t3.I
ups.firmware.aux: t3
ups.load: 28.0
ups.mfr: American Power Conversion
ups.mfr.date: 2010/08/14
ups.model: Back-UPS ES 525
ups.productid: 0002
ups.realpower.nominal: 300
ups.serial: 4B1033P19388
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

Может, лучше про https://www.netxms.org/forum/oe-oo/okaa-teea/msg10272/#msg10272  вспомним? 

Всё должно работать.

Гораздо удобнее "отлаживать" из консоли (exec <scriptname> из библиотеки). А там trace или println, как привык. После того, как добьёшься работы, уже в "продакшн".

Да, всё по-прежнему.

Простой вариант, через custom attributes:

Если дверь будет несколько раз ;D открыта, но закрыта - один раз, резолвиться будет последний аларм. Ну это и логично, т.к. представить себе такое проблематично.

Чуть сложнее, не засоряя custom attributes, делать это через Situation, в несколько проходов:

1. Первый обработчик события открытого состояния двери устанавливает значение ситуации (situation) этим самым event id.
2. Второй - генерирует аларму и в качестве ключа %[именованным скриптом] или %<именованным параметром события> берёт состояние ситуации. А этот параметр устанавливается, соответственно, в filtering script. Ну или ещё хрен его знает где.
3. ... и т.д.