NetXMS Support Forum

Т.е. закрытые алармы - это те, у которых term_by <> 0, и в этом случае дата/время закрытия - last_change_time?

Спасибо, я просто не увидел кнопочку "get more data"

Однако вопрос с выборкой алармов средствами SQL по-прежнему актуален, потому что текущее представление включает слишком много колонок. Актуальность, наверное, потеряется только с решением этой проблемы -  https://www.radensolutions.com/chiliproject/issues/224

Да, искать по БД приходится не от хорошей жизни - в Alarm Log с фильтром по Source удается найти записи до апреля, остальных нет. Хотя в БД с тем же object_id есть записи вплоть до сегодняшнего дня. Что может так влиять на неотображение данных?

Здравствуйте!

Получить список алармов из БД (PostgreSQL) можно так:


select
    name,
    message,
    timestamp 'epoch' + creation_time * interval '1 second' as begin,
    timestamp 'epoch' + last_change_time * interval '1 second' as last_change   
from alarms inner join object_properties
    on source_object_id = object_id
order by creation_time desc


Однако я не могу найти поле с отметкой о том, когда аларм был закрыт, а также кем и по какой причине.

Здравствуйте!

Регулярно наблюдаю высокие значения в Database writer's request queue (other queries) - см. аттач и:


netxmsd: show queues
Condition poller                 : 0
Configuration poller             : 0
Topology poller                  : 0
Data collector                   : 0
Database writer                  : 4542
Database writer (IData)          : 0
Event processor                  : 0
Network discovery poller         : 0
Node poller                      : 0
Routing table poller             : 0
Status poller                    : 0


Насколько это плохо и с чем связано?

NetXMS есть в официальном репозитарии ALT Linux в виде rpm, однако вряд ли этот rpm окажется подходящим для других rpm-based дистрибутивов

Пакет для Альта собирается так - http://git.altlinux.org/people/enp/packages/netxms.git

1.2.2

Обновлю при случае

Здравствуйте!

Только что наблюдал следующую ситуацию: в БД накопилось множество записей в таблице interfaces, которые должны были быть удалены еще несколько дней назад - именно тогда их удалили из консоли. После рестарта netxmsd удаленные интерфейсы стали видны в консоли и сейчас снова удаляются без проблем. Что это было и что делать, если воспроизведется?

Да, LogFailedSQLQueries в дефолтном состоянии, т.е. yes

Здравствуйте!

Нашей смене очень интересно, как описаны подсети из дерева объектов на маршрутизаторах. В описаниях упоминаются как минимум номера вланов и при исчезновении какой-то ноды есть о чем жаловаться "начальнику транспортного цеха" - последний предоставляет исключительно L2 и видит только вланы и мак-адреса.

Наверное, стоило бы сделать дополнительную вкладку со списком всех найденных интерфейсов из заданной сети (с описаниями и т.д.) - тем более, что вся необходимая информация в БД NetXMS уже есть. Но я только сейчас это сообразил, после того, как реализовал опрос маршрутизаторов по SNMP для вытягивания интерфейсов и отображения в комментариях к подсетям. Покажу, чтоб не потерялось и в качестве рекламы Groovy для интеграционных задач


#!/usr/bin/groovy

import org.apache.commons.net.util.SubnetUtils

import org.netxms.client.NXCSession

import org.snmp4j.CommunityTarget
import org.snmp4j.PDU
import org.snmp4j.Snmp
import org.snmp4j.mp.SnmpConstants
import org.snmp4j.smi.GenericAddress
import org.snmp4j.smi.OID
import org.snmp4j.smi.OctetString
import org.snmp4j.smi.VariableBinding
import org.snmp4j.transport.DefaultUdpTransportMapping
import org.snmp4j.util.DefaultPDUFactory
import org.snmp4j.util.RetrievalEvent
import org.snmp4j.util.TableUtils

def get(Snmp snmp, CommunityTarget target, String oid) {
PDU pdu = new PDU()
pdu.add(new VariableBinding(new OID(oid)))
pdu.type = PDU.GET
snmp.send(pdu, target, null).response.get(0).variable
}

def routers = [
[ "router1", "udp:192.168.1.1/161", "public" ],
[ "router2", "udp:192.168.1.2/161", "private" ]
]

def subnets = []

routers.each { router ->

def target = new CommunityTarget(
community : new OctetString(router[2]),
address : GenericAddress.parse(router[1]),
version : SnmpConstants.version2c
)

def snmp = new Snmp(new DefaultUdpTransportMapping())
snmp.listen()

def table = new TableUtils(snmp, new DefaultPDUFactory())

OID[] oids = [
new OID(".1.3.6.1.2.1.4.20.1.1"),
new OID(".1.3.6.1.2.1.4.20.1.2")
]

table.getTable(target, oids, null, null).each { event ->
if (event.status == RetrievalEvent.STATUS_OK) {
def columns = event.columns;
def address = columns[0].variable
def index = columns[1].variable
def descr = get(snmp, target, ".1.3.6.1.2.1.2.2.1.2.${index}")
def alias = get(snmp, target, ".1.3.6.1.2.1.31.1.1.1.18.${index}")
subnets << [router[0], "${address}", ("${descr} ${alias}").trim()]
}
}

snmp.close()

}

def session = new NXCSession("monitor", "pusher", "pushpwd")
session.connect()

session.syncObjects()
session.getAllObjects().each { object ->
if (object.getObjectClassName() == "Subnet") {
def desc = []
subnets.each { subnet ->
if (new SubnetUtils(object.getObjectName()).info.isInRange(subnet[1]))
desc << "${subnet[0]} - ${subnet[2]}"
}
if (desc)
session.updateObjectComments(object.getObjectId(), "${desc.unique()}")
}
}

session.disconnect()


Расскажите, каков алгоритм распределения нод по подсетям в дереве объектов? У меня наблюдается странная аномалия - хост с интерфейсами из сетей 192.168.199.0/24 и 10.10.12.0/24 попал в подсеть 1.1.1.0/24. Версия сервера - 1.2.2, консоли - 1.2.4 и 1.2.2 тоже.

Здравствуйте!

Как получить список подсетей серез Java API? Ничего умнее я не придумал (синтаксис groovy):


session.getAllObjects().each { object ->
    if (object.getObjectClassName() == "Subnet")
        println "${object.getObjectId()} - ${object.getObjectName()}"
}


Quote from: Victor Kirhenshtein on November 12, 2012, 11:29:45 AM
Вообще-то поля NXCObjectModificationData напрямую изменять нельзя. Они все обьявлены как private, я так понимаю что Groovy это просто игнорирует (а зря!).

Нет, Groovy вызывает set-метод

Quote from: Victor Kirhenshtein on November 12, 2012, 11:29:45 AM
Что касается комментариев, то это исключение (так исторически сложилось), и через modifyObject поменять их нельзя. Правильный код для изменения комментария ...

Спасибо!

Здравствуйте!

Пытаюсь изменить комментарий объекта через Java API (использую Groovy):


NXCSession session = new NXCSession("server", "login", "password")
session.connect()

data = new NXCObjectModificationData(2081)
data.description = "ABC"
session.modifyObject(data)

session.disconnect()


Комментарий не изменяется. Что я делаю неправильно?

Total number of objects:     2470
Number of monitored nodes:   332
Number of collectable DCIs:  1342

Региональная NGN-сеть. Мониторится различное VoIP-оборудование + сервера с Linux, FreeBSD и Windows. Сервер NetXMS живет внутри OpenVZ CT, использует PostgreSQL из соседнего CT. Активно используем push в тех случаях, когда нужные DCIs по SNMP не достать - для этого есть самописные перловые модули для нескольких шаблонов, которые читают список нод прямо из БД NetXMS. Имена модулей и параметры подключения хранятся в той же самой БД в custom attributes. Заинтересованы в наличии perl wrapper к libnxcl

Серверная часть опакечена для ALT Linux - см. http://packages.altlinux.org/ru/Sisyphus/srpms/netxms и http://git.altlinux.org/people/enp/packages/netxms.git, она же и используется, собственно. Так что можно добавить на первую страницу информацию о том, что в ALT Linux NetXMS включен в официальный репозитарий и работает практически из коробки (только БД настроить нужно).

Если б протокол обмена с сервером базировался на чем-то широко распространенном (JSON/XML-RPC? REST? Hessian/Burlap? Protobuf? Thrift?), то проблемы, наверное, не было бы.

А возможность дернуть NXSL-скрипт извне как из командной строки, так и по HTTP  - замечательная идея. Но в этом случае внутри NXSL-скриптов должен быть доступен аналог Java API. Я даже боюсь себе представить трудоемкость такой задачи. Пока научить бы NXSL с таблицами работать ...