Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - noel

#1
Thanks for the info, after reading the docs about Agent External Metrics I converted the actions to shell form metrics and now it works fine.

(Before I read the docs I tried the format you provided, but that had some issues which didn't trigger an alarm so I have no idea what was wrong with that.)
#2
General Support / Script based DCIs broken after update
September 04, 2026, 12:51:51 PM
I recently upgraded our NetXMS server (and agent) listed below:
netxms-agent:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
netxms-server:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
and later (due to this issue)
netxms-agent:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm)
netxms-server:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm).

I had two similar DCIs like this: origin: script, metric: Ping("1.1.1.1",1)

And the following script behind:

if ($2) {
cmd = "ping-suli";
} else {
cmd = "ping-voda";
}
println("Using: " .. cmd);
res = $node.executeAgentCommandWithOutput(cmd, $1);
if (res.length == 0) return null;
return res;

Both DCIs error with the following: Script (Ping) execution error: Error 14 in line 8: Function or operation argument is not an object

But if I use the execute script function with params: "1.1.1.1",1 to run the ping on the same node I get the expected result:

Using: ping-suli


*** FINISHED ***

Result: 25.2

This issue started after the first upgrade and persisted after the second.
#3
I have several DCIs for ping times that do not report data if the ping fails and display them on a dashboard, but currently netxms interpolates between all data points, it would be nice if it took the polling rate into account and instead of interpolating a large gap, it would fill the gap with a specific color.

Attached two images how it currently looks like and how I imagined this feature. As you can see on the first image it's barely visible that there were missing pings, but on the second you can tell that at a glance.
#4
Attached the database list and two binary files created with psql copy, one is just the message value, the other is the entire record.
#5
The old server has already been shutdown, but I'll try my best to get the info from it this week. I'll be able to post the entire record as-is since it didn't contain any sensitive data iirc.

I no longer have the failed record error message, but in the original post you can see the start of the message, it just continued with all the fields of the failed record.
#6
I used pg_dump and psql to migrate the database to the new location, which was successfull. Currently I'm waiting on the timescale conversion to complete.

Edit: TimescaleDB inplace migration also completed successfully. NetXMS is now running on the new host.
#7
Old db:
netxms=# \d win_event_log
                        Table "public.win_event_log"
      Column      |          Type           | Collation | Nullable | Default
------------------+-------------------------+-----------+----------+---------
 id               | bigint                  |           | not null |
 event_timestamp  | integer                 |           | not null |
 node_id          | integer                 |           | not null |
 zone_uin         | integer                 |           | not null |
 origin_timestamp | integer                 |           | not null |
 log_name         | character varying(63)   |           |          |
 event_source     | character varying(127)  |           |          |
 event_severity   | integer                 |           | not null |
 event_code       | integer                 |           | not null |
 message          | character varying(2000) |           |          |
 raw_data         | text                    |           |          |
Indexes:
    "win_event_log_pkey" PRIMARY KEY, btree (id)
    "idx_win_event_log_node" btree (node_id)
    "idx_win_event_log_timestamp" btree (event_timestamp)
New db:
netxms=# \d win_event_log
                         Table "public.win_event_log"
      Column      |           Type           | Collation | Nullable | Default
------------------+--------------------------+-----------+----------+---------
 id               | bigint                   |           | not null |
 event_timestamp  | timestamp with time zone |           | not null |
 node_id          | integer                  |           | not null |
 zone_uin         | integer                  |           | not null |
 origin_timestamp | integer                  |           | not null |
 log_name         | character varying(63)    |           |          |
 event_source     | character varying(127)   |           |          |
 event_severity   | integer                  |           | not null |
 event_code       | integer                  |           | not null |
 message          | character varying(2000)  |           |          |
 raw_data         | text                     |           |          |
Indexes:
    "win_event_log_pkey" PRIMARY KEY, btree (id, event_timestamp)
    "idx_win_event_log_node" btree (node_id)
    "idx_win_event_log_timestamp" btree (event_timestamp)
Triggers:
    ts_insert_blocker BEFORE INSERT ON win_event_log FOR EACH ROW EXECUTE FUNCTION _timescaledb_functions.insert_blocker()
I also checked the length of the problematic record in the old db:
netxms=# select length(message) from win_event_log where id = 7335338;
 length
--------
  2000
(1 row)

I tried the normal to normal migration but it failed with the same error.

Additional info:
Old db version:
postgres=# select version();
                                                                version                                                                
----------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 14.15 (Ubuntu 14.15-0ubuntu0.22.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)
New db version:
postgres=# select version();
                                                       version                                                      
---------------------------------------------------------------------------------------------------------------------
 PostgreSQL 15.10 (Debian 15.10-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
(1 row)
#8
I'm trying to migrate NetXMS from a physical host to an LXC container and also upgrade to TimescaleDB.

I installed NetXMS 5.1.3 in the container and initialized a postgres 15 database with timescaledb, then I upgraded the existing host to the same version and stopped the service in both locations.

Then I run
nxdbmgr migrate old_netxmsd.conf which started the migration, but failed with a Windows Event log:
Migrating table win_event_log
SQL query failed (22001 ERROR:  value too long for type character varying(2000)):
INSERT INTO win_event_log (id,event_timestamp,node_id,zone_uin,origin_timestamp,log_name,event_source,event_severity,event_code,message,raw_data) VALUES (?,to_timestamp(?),?,?,?,?,?,?,?,?,?)
Failed input record:
(Truncated the event data, but it was also printed.)

I thought about removing records in the source db which violate the new constraints to complete the migration, but what about new records that netxms will attempt to insert in the new db?

What should I do in this case?
#9
General Support / Should Agent IDs be unique?
September 10, 2024, 04:53:42 PM
I just deployed 30+ PCs from a sysprepped image with WDS and noticed that all agent IDs are the same, but - so far - it didn't cause any issues and I can't see alerts related to this - like you get for duplicate MAC addresses. So I'm wondering does it have to be unique? If so, what step(s) should I take during sysprepping in the future (and also now after the deploy) to make it unique? If not, then what's the purpose of that ID?
Tried looking it up in the admin guide, but couldn't find anything related to imaging with an agent install or what's the role of this ID.
#10
Feature Requests / Customizable syslog in dashboard
June 19, 2024, 09:48:57 AM
I like to keep an eye on our squid proxy traffic on the dashboard, but I'm only interested in the message column, which gets squished by the first 6 columns, I can resize them one-by-one to zero width but that also gets lost on a refreh.
I'd like to see an option to hide columns and/or save their width percentages.
#11
Finally with the next regex I managed to get it working, so it's only matching admin users' logins:
Virtuális fiók:\t\tNem.*Emelt szintű jogkivonat:\t\tIgen.*Fióknév:\t\t(\w+).*Fiók tartománya:\t\t(?!NT AUTHORITY)
#12
I did manage to get events when trying simple regexes that didn't try to match multiple lines of windows log messages.
But I'm a bit confused now about what is the tested string, since the docs only mention single lines, but the windows event is multiple lines and when I simply put (.*) as the match regex, in the event %1 was a multi line string with the full windows event message; which is strange since as far as I know . matches everything except new line; but either way the regex I used had . and explicit \r\n matched multiple times so it should've catched each case, also it worked when I tested it on regexr.com
#13
I tried creating a template and added a log parser policy with the following content:
<parser checkInterval="1" name="Admin activity parser">
   <macros/>
   <file>*Security</file>
   <rules>
      <rule name="Login">
         <match repeatCount="0" repeatInterval="3600" reset="false">Emelt szintű jogkivonat:\s+Igen(?:.|\r\n)+Fióknév:\s+(\w+)</match>
         <event>VV_ADMIN_LOGON</event>
         <id>4624</id>
         <push group="1"></push>
         <agentAction action=""></agentAction>
      </rule>
   </rules>
</parser>
It didn't crash the server however it also doesn't trigger the event, I tried to:
  • reduce the checkInterval from the default 10000 to 1 (what is the unit for this?)
  • make the regex match the whole message
  • use literal \r\n and \t in the expression
I made sure that the template is applied to the node I'm testing with, and in the windows events view I can see the windows event for the login. Also I'm still running netxmsd from gdb and I can only see entries like this and nothing else when I log into an account on the client:
*D* [agent.conn.10794   ] AgentConnectionEx::onWindowsEvent(): Received event from agent at 10.255.7.114, node ID 1814
#14
Attached the full bt output. I'll also try the suggested method and get back with the results.
#15
Hi,

I'm trying to set up a log parser rule that would trigger an event if an administrator logs on to a monitored computer, however this rule causes the NetXMS server to crash with segmentation fault.

NetXMS Server versions that I've tried: 4.5.3, 4.5.4

The parser which causes the crash (made it with the GUI then switched to the XML view):
<parser name="Default parser">
   <macros/>
   <rules>
      <rule name="Admin logon">
         <match repeatInterval="0" reset="false">Emelt szintű jogkivonat:\s+Igen(?:.|\n)+Fióknév:\s+(\w+)</match>
         <event>VV_ADMIN_LOGON</event>
         <id>4624</id>
         <agentAction action=""></agentAction>
      </rule>
   </rules>
</parser>
Windows event 4624 is created when a user logs in and with this rule I'd like to check if they're an administrator and what is their name. (The monitored desktops run Windows 10 with Hungarian language.)

How could I solve this?