NetXMS Support Forum

Hello,

after a few years of NetXMS usage I can only praise all the improvements so far, but IMHO there are still a few things that bug me right from the start:

• Syslog/Event/SNMP monitors - is it just me or they (still) don't really work until you take at least one look directly at the relevant tabs (even though you may have them automatically opened ever since you started the console)?
• GUI annoyances - let's say I'm looking at the server configuration tab and then decide to click a node on the left and... nothing, I'm still looking at the same server configuration tab (instead of seeing details of the object I just clicked). Or, I just saw that I forgot some performance graphs, so I activate them and close the DCI editor and... nothing, no new graphs (until I click some other object and return). Also, nodes can have ICMP proxy, SNMP proxy and... poller node (except for a zone where it's agent proxy)?
• MIB explorer - how about snmpwalking from a custom numerical OID at the right side, not just via MIB tree branches at the left? For example, you could place a button labeled "Snmpwalk" at the right side of the numerical OID entry field so we can manually enter numbers and walk from there. Let's be honest, anyone with a decent quantity of SNMP capable devices will never compile all the MIBs and sometimes it really takes a while to find something - first to snmpwalk most of the way from the top, then to scroll through rows and rows of similar looking numbers... and while at it, how about a reverse function to "Select in MIB tree" or an option to refresh a single OID value?
• Image library - perhaps the best illustration of my point here is this direct quote from the manual: it "...is possible to upload, delete and update images.". And, besides zooming and grouping, that's about it. If you ever tried to upload proper images of your equipment (mostly in Visio format, aren't they?) you will probably agree that it can be best described as a very manual and painful "trial and error" process. OK, perhaps it would be too much to expect vector graphics and direct Visio import, but how about copy/paste/crop/resize and some kind of info panel with image resolutions and such?
• Conditions - sorry if I'm really pushing it here, but it would be great if container conditions could also set internal objects to "unknown" status so I can script their dependency on a single point of failure upstream network interface. You get it, I hope - once this interface (or its parent node) fails you only get one alert, status of all the objects in this container automatically switches to "unknown" without polling, and everything stays that way until the SPoF goes up again. Note that it could actually be a trunk/portchannel interface, so it's SPoF only in this context. I kind of remember someone here saying that it should automatically work like that due to topology discovery but I'm yet to see it happen...

Btw, after rereading what I just wrote - did I mention that I really like NetXMS? 

Hi,

all mentioned points definitely worth fixing/implementing. What you call "conditions" will definitely be complicated, while rest seems to be relatively easy to implement. I'll try to schedule it for next releases.

Best regards,
Victor

Hello, Victor

and thank you for your reply, you're being very helpful as usual.

Regarding "conditions", I'm actually talking about extending an already implemented feature (right click on container,  create condition..., Events and Status/Script). The only thing that is missing IMHO is the possibility to apply "unknown" status to child objects... or more like a mix of "unknown" and "unmanaged", as the idea is to stop all DCI polling until the condition is met again.

I'll try to elaborate some more... for some of my coworkers, a container with a big red "critical" status implies that something is wrong with the objects it contains (especially when they all also turn "critical"). It takes ages for them to figure out that the problem is actually due to NetXMS not being able to access its child objects because of a small red "critical" condition on a single, seemingly unrelated node and/or interface.