NetXMS Support Forum

Hi,

We are using events to send emails to another system which parses the emails based on a number of rules and puts it all into a ticketing system.
As we are setting up rules, we sometimes find that some alerts are not parsed or ticketed properly. That's obviously not a NetXMS problem.

However, I'd like to be able to "force" an alert to be resent. When I try to just resolve the alert (we tend to sticky acknowledge them to avoid being spammed while we look at things) and then terminate it, the system will still not send a new alert out. I would have thought that when an alert is terminated where the underlying condition has not actually changed, that a new alert would be triggered. But that does not seem to be the case.

I can clear the collected data for the DCI in question, but the "Threshold" column will still show me the threshold that was triggered originally. And when new data comes in that still matches that, it doesn't change nor does it send another alert. Is there any way to "clear" that Threshold column for an individual DCI to ensure a new alert goes out?

Any ideas?

Sure were.
I wasn't aware that the server crashing, deleting of wrong DCIs and DCI duplication were all related to the same underlying problem with instances.

I just upgraded to version 2.0.5 and did another round of template consolidation, which included removing a number of instances from templates and the system has been stable with no odd DCI deletions either.

Thanks Victor!

Cheers

Sorry, haven't seen that before other. Maybe someone else has?

Hi,

== OK resulted in three alerts for the "OK" ones.
!= OK resulted in no alerts.

System has four disks. The first one is in "Predictive Failure" status. The actual text is a simple string which is the result of using a transformation, i.e. I know what text is being stored as I defined it in that transformation. The fact that it displays text and not numbers means the transformation itself was also working.

Cheers,

Hi,

The results are somewhat unexpected.
I created the script, I created an event and an event processing policy.
Then I removed the system from the HP template, but kept the DCIs for testing.
Changed the Threshold to !like - and got nothing at all.
I created a duplicate of the DCI - and received three alerts: the three "OK" disks (with "OK" without quotes being passed via %[TableData]). But I didn't get one for the "Predictive Failure" one.
I switched back to == and still did not get any alerts. Changed to !=, again three alerts for "OK" disks.
I changed to != BLUBB (literally BLUBB) and still only got three alerts.

In my original message I mentioned switching to "not like" triggered an immediate alarm. I should've been more thorough at the time, now I am wondering if I only got three alerts back then as well. Out of ideas. Is this some odd off by one problem? The row with the Predictive Failure is the first one.

Cheers

When you open the Management Console it downloads the netxms.mib file to your system. I noticed it doesn't always replace the version you have on your computer with a new one. However manually deleting the netxms.mib from your system, i.e. the one you run the Management Console on, does trigger a download of the new netxms.mib and you should be good to go.

Cheers

Ubuntu packages, pretty please? 

I had some issues with instance discovery DCI deletion, in my case to the point of crashing the server.
NetXMS version 2.0.5 includes a fix around deletion of such DCIs, so it may resolve your problem as well.
(Haven't tested at my end yet, as I am waiting on the Ubuntu packages.)

Cheers

Hi,

We are making extensive use of SNMP tables for monitoring things like CPU, RAM, PSU, fan and HDD/SDD health.
Threshold triggering in tables appears to be a bit hit and miss though.

For example right now I have a system with a disk that reports "Predictive Failure" in the HP System Management Homepage on the server itself.
Our NetXMS picks this up, transforms the numerical value reported into a string to match "Predictive Failure" - and shoul dthen alert on this.
The latter part is not working. I have seen this before with string matching and "equal to" and sometimes switching to "like" worked. In this particular case that didn't work either. Changing to "not like" just for testing triggered an immediate alarm, so it sure looks like what I am looking for does not match what NetXMS finds in the database?

See attached images showing the collected data (note: Display Name matches Column Name) as well as the configured Thresholds.
I also attached the template - nothing special really.

Now I am not sure if there may be other items in an unhealthy state right now, where NetXMS just doesn't create an alarm. The only reason I picked this one up was because I just added the system as a node to NetXMS while it was in that state already.

Thanks

Hi,

I seem to have a lot of systems with duplicate DCIs.
Pretty much all DCIs on our installation are created via templates.
It appears that the system sometimes decides to create the same DCI a second time, although it already exists. I have not seen this happen live, I only see the results when the very same thing(s) show up twice on the same node.  It doesn't seem to be tied to a specific node, template or DCI, but happens across all nodes.

Not sure if this is due to a race condition or deadlock at the time of a regular node configuration poll?

Cheers

Hi,

I just encountered a rather odd issue when I manually removed a node from a template and asked it to remove the DCIs.
The result was that not all DCIs from the template were actually removed - but two out of three DCIs from a completely different template were.

Not sure if anyone here has ever seen such a behaviour before?

Cheers

Hi,

I noticed that when an instanced DCI triggers an alarm and the instance itself is then later removed, the alarm remains in the system.
Guess it would make sense if alarms were removed from the system together with DCI data when an instance is removed?

Along the same line, it would also be nice to be able to tell the system to keep an instance "active" for a (per instance DCI configurable) period, just in case the same instance comes back later. In our case we have some systems that have USB drives which we are monitoring for disk space. The drives are sometimes detached for some time, but do come back. Once the disk is detached though, the instance will eventually be removed, wiping the DCI data, keeping any potential "zombie alarms" and then creates a new DCI later when the disk is reattached.

I could think of other scenarios where keeping the "old" DCI data for a while would make sense, guess it all depends on how much one actually utilises instance discovery and instance discovery filters.

Cheers

As the node on FindObject does not limit the search scope, I implemented this using the suggested GetNodeInterfaces loop. Works fine.

I don't think you can do that directly.

However you should be able to create a separate DCI that uses a script.
That script could utilise GetDCIValue (https://wiki.netxms.org/wiki/NXSL:GetDCIValue) and Table methods (https://wiki.netxms.org/wiki/NXSL:Table) to obtain the data you're after. That DCI can then be used in the Dashboard.

Hope that helps somewhat.

Hi,

Just found a previous post regarding MySQL database size and shrinking the file size:
https://www.netxms.org/forum/general-support/mysql-db-fast-grow-how-to-free-space/

It includes a link that may help. Another link that may be helpful:
http://www.thegeekstuff.com/2016/02/mysql-innodb-file-per-table/

This is not a NetXMS specific issue, it is simply how the database software itself (in your case MySQL, presumably using InnoDB) operates.

Hope the links help.