NetXMS Support Forum

Ключ ни на что не влияет в работе программы — собирать без него правильно.

Он добавляет в сборку только libipfix, библиотеку разбора NetFlow/IPFIX. Демон-коллектор nxflowd, для которого она предназначалась, в сборку не входит вообще, а сервер и консоль с flow-данными не работают: обработка так и не была реализована. В 7.0 ключ удалён вместе с кодом.

Вместо собственного коллектора в 7.0 планируется интеграция с внешними анализаторами трафика, первый коннектор — ntopng: https://github.com/netxms/netxms/issues/3429

Hi,

Confirmed, and thanks for tracing it - your reading is exactly right. When no multiplier applies the value stays a String, so the %s path skips the decimal trimming. Tracked as https://github.com/netxms/netxms/issues/3577.

Until that's fixed, setting an explicit display format on the DCI works around it: %{m,u}.2f instead of leaving it empty. The f conversion parses the string into a number first, so the trimming happens. Cost is that it's per-DCI and pins you to two decimals regardless of magnitude.

Добрый день

Расскажите пожалуйста, какую роль играет ключ конфигурирования (ниже) в последующей работе программы?
 --with-flow-collector   build NetFlow/IPFIX flow collector

Т.е. из комментария конечно понятно что это, но на что он влияет, как используется в программе?
Собираю без него, но может он таки нужен? Если да, то для чего и как использовать?
Расскажите пожалуйста!

Float DCI values between approximately 0.01 and 1 are displayed with unnecessary trailing zeroes when using a measurement unit with default multipliers.

For example, I am monitoring current from a PDU over SNMP.

The SNMP device returns integer values that are divided by 100 using a transformation script:

return $1 / 100;

For a phase current:

Raw value: 303
Transformed value: 3.03
Displayed value: 3.03 A

This is displayed correctly.

However, for the neutral current:

Raw value: 68
Transformed value: 0.68
Displayed value: 0.680000 A

The expected display value would be:

0.68 A
Configuration
NetXMS server/client version: 6.1.1
DCI type: SNMP
Data type: Float
Unit: A
Multipliers: Default
Transformation:
return $1 / 100;
Steps to reproduce
Create an SNMP DCI returning an integer value such as 68.
Set the DCI data type to Float.
Set the measurement unit to A.
Leave multipliers at the default setting.
Add the transformation:
return $1 / 100;
The transformation test correctly shows 0.68.
After normal data collection, Last Values displays:
0.680000 A

Using the same configuration with a raw value such as 303 produces:

3.03 A

as expected.

I also duplicated a working DCI that displayed 3.03 A correctly and changed only the SNMP OID so that the returned/transformed value was below 1. The duplicated DCI immediately showed the same 0.680000 A behavior, so the issue does not appear to be caused by a DCI configuration difference.

Expected behavior

Float values should use consistent formatting regardless of whether the value is above or below 1.

For example:

3.030000 -> 3.03 A
0.680000 -> 0.68 A
Actual behavior

Values greater than or equal to 1 are formatted without unnecessary trailing zeroes:

3.030000 -> 3.03 A

while values below 1 may retain the complete float string:

0.680000 -> 0.680000 A
Additional information

The behavior appears to still be present in the DataFormatter implementation in NetXMS 6.2.3 and current master.

It appears that when the default multiplier logic cannot select a multiplier for a value below 1, the original value string is retained instead of being converted to a Double. The %s formatting path then only applies the normal decimal formatting when the value is a Double, causing the original 0.680000 string to be displayed unchanged.

The underlying numeric DCI value appears to be correct; this seems to be a display/formatting issue.

Да, это ровно тот случай из Note в ответе от 09.08: отложенное действие было заведено до входа в обслуживание, а при срабатывании режим обслуживания не проверяется — ни флаг "Accept correlated events", ни скрипт в фильтре правила на этом этапе не работают, они отрабатывают в момент постановки таймера. Настройками это не обходится, поэтому завёл тикет: https://github.com/netxms/netxms/issues/3566

We are visiting FrOSCon 2026 in Sankt-Augustin, Germany - so if you happens to be there too and want to chat with the team - feel free to message me!

Cheers,
Victor

Hi,

Yes, there is one - it sits on the notification channel, not on the EPP action, which is why you didn't find it. Added in 6.1 (https://github.com/netxms/netxms/issues/2987), and it's a token bucket, so "max N per time window" is exactly what it does.

Your reading of snoozeTime/blockingTimerKey is correct: the check is "does a scheduled task with this key exist", not a count against a threshold. N=1 only, never N.

Server configuration parameters:

NotificationChannels.RateLimit.ChannelBurst      10       # your N
NotificationChannels.RateLimit.ChannelRate       1        # refill rate
NotificationChannels.RateLimit.ChannelRateUnit   minute   # second | minute | hour

10 immediately, then one more per minute - 10 per 600s. Defaults are 0 = disabled, and they are re-read every 10 seconds, so no restart. There is a matching RecipientBurst/RecipientRate pair counted per recipient address. Anything over the limit is queued rather than dropped, and once the backlog passes DigestThreshold (50) it's folded into one digest mail every DigestInterval (300s).

The catch: it counts per channel and per recipient, and cannot key on the event message. That is the one thing your script does that this doesn't.

For that part there's a lighter option than persistent storage - the alarm already counts repeats per alarmKey, and a filter script can read it:

alarm = FindAlarmByKey($key);
return (alarm == null) || (alarm.repeatCount < 10);

The count disappears when the alarm terminates, so there is nothing to clean up. Note the filter runs before the rule updates the alarm, so have an earlier rule create it and a later one send the mail. If you stay with persistent storage instead, two things will bite you: keys are silently truncated at 127 characters (hash the message with Crypto::SHA256()), and nothing ever expires them - delete with WritePersistentStorage(key, null).

On the alarmTimeout chain, two corrections. Generating an alarm does not suppress the rule's actions - the alarmKey de-duplicates the alarm, not the notification, and the action list still runs for every matching event. So whatever gives you 1 mail per window there is your filter script, not the alarm. And alarmTimeout is measured from the alarm's last change, so every repeat event resets it: during a flood SYS_ALARM_TIMEOUT never fires, it fires only once the events stop for the full timeout period.

It's an inactivity timer, not a window timer. Terminate-on-timeout is the right way to build a self-resetting alarm - just don't expect a fixed 600s cycle out of it.

If you enable the channel limit, be on 6.1.3+ or any 6.2.x - there was a shutdown crash in the throttling thread, fixed in https://github.com/netxms/netxms/issues/3238. None of these parameters are in the Admin Guide yet - filed https://github.com/netxms/netxms-doc/issues/70 for that.

Hi all,

We're monitoring log-based error events(Event Log Entry, Error in Log File, ASP .NET Error) and sending email notifications via an EPP rule. The issue we have is that when something goes wrong we can be spammed with hundreds of emails.

We have two different methods to resolve this but wanted input on which is better and if there are any other options.

• A custom NXSL filter script on the EPP rule that builds a key and tracks via WritePersistentStorage(). This allows 10 emails per a rolling 600 second window per key (based on the message).
• Generate an alarm with an alarmKey based on the message, using a custom script, and then using alarmTimeout and a companion rule that terminates the alarm. This is obviously a native solution but only allows 1 email per window.

Questions for the community:

• Is there a native mechanism we've overlooked for "max N notifications per time window"? (We've looked at action snoozeTime/blockingTimerKey, but those suppress rather than count.)
• For email throttling specifically, is the persistent-storage script the accepted pattern, or is there a cleaner way?
• Is the alarmTimeout → SYS_ALARM_TIMEOUT → terminate-rule chain the right way to get a self-resetting alarm?

Thanks in advance.

Hi,

No - Title and Group do not take scripts. Neither field goes through a macro engine on the server: the whole Performance View block is stored with the DCI as-is, and the client substitutes a small fixed set of placeholders when it draws the tab. That is the entire mechanism, so there is nothing to hook a script into.

Two separate things are off in the screenshot. %[...] is a real macro syntax, but it belongs to the text expansion used for event and alarm messages, notification text and object tools - and there the form is %[scriptName], without the script: prefix. The script: prefix belongs to %{script:name}, which is a template macro for DCI name, description and instance fields, expanded when the DCI is created from a template - once per node, not per discovered instance. You combined the two, and neither engine is applied to Performance View fields.

What the fields do accept, substituted by the client at render time:

• Title - {instance}, {instance-name}, {node-name}
• Group - {instance}, {instance-name} (no {node-name} here)
• Name in legend - {instance}, {instance-name}, {node-name}

Leave Title or Name in legend empty and the DCI description is used instead. Charts are grouped by the substituted Group value, so instances that produce identical text land on one graph.

For splitting instances into two or more groups there are two ways.

Simplest approach is one master DCI per group: copy the instance discovery DCI, give each copy a fixed Group name, and let each instance filter script accept only the instances belonging to that group. The group stays static text and the script only decides membership, so each group can also have its own title, colors and time range.

If you want to keep a single master DCI and let the script decide, use the instance display name as the carrier - the filter script sets it, and Group reads it back:

if ($1 ilike "*volt*")
   return [true, $1, "Voltage"];
return [true, $1, "Current"];
Second element of the array is the instance value ({instance}), third is the instance display name ({instance-name}). Set both Group and Title to {instance-name} and Name in legend to {instance} - instances the script labelled "Voltage" end up on one graph titled Voltage, "Current" on another.

Two caveats: {instance-name} then carries the group label everywhere it is shown, Last Values and DCI descriptions included, so use {instance} where you need the instance itself; and group matching is exact, case included.

Filling these fields from a script is not possible today, and the macros that do work are not in the documentation - the Performance view section only mentions grouping by identical Group text. I raised https://github.com/netxms/netxms-doc/issues/69 to get them written down. If script-driven titles are important for your setup, say so and I will open a feature request for it.

Всё получилось, ровно так как вы и написали. Вариант с make install конечно, более привлекателен )

В конечном итоге:

[root@AltTEST netxms-6.2.3]# nxdbmgr upgrade
NetXMS Database Manager Version 6.2.3 Build 6.2-694-g766c57382a

INFO: Server module WEBAPI skipped
Upgrading database...
Upgrading from version 62.35 to 62.36
Upgrading from version 62.36 to 62.37
Upgrading from version 62.37 to 62.38
Database upgrade succeeded


Большое спасибо за помощь!