NetXMS Support Forum

For which smartphone platform you'd like NetXMS client to be developed? If you don't see any need for mobile client, please answer "I don't need smartphone client" so we know how important this feature is.

Best regards,
Victor

You have missed code for actual message reception. Instead of


// Initialize raw message receiving function
pMsgBuffer = (CSCP_BUFFER *)malloc(sizeof(CSCP_BUFFER));
RecvNXCPMessage(socketId, pRawMsg2, pMsgBuffer, RECEIVER_BUFFER_SIZE,0,0,0);

// Allocate space for raw message
pRawMsg2 = (CSCP_MESSAGE *)malloc(RECEIVER_BUFFER_SIZE);
pMsg2 = new CSCPMessage(pRawMsg2);


you should have something like


// Initialize raw message receiving function
pMsgBuffer = (CSCP_BUFFER *)malloc(sizeof(CSCP_BUFFER));
RecvNXCPMessage(0, NULL, pMsgBuffer, RECEIVER_BUFFER_SIZE,0,0,0);

CSCP_ENCRYPTION_CONTEXT *nullContext = NULL;
pRawMsg2 = (CSCP_MESSAGE *)malloc(RECEIVER_BUFFER_SIZE);
RecvNXCPMessage(socketId, pRawMsg2, pMsgBuffer, RECEIVER_BUFFER_SIZE,&nullContext,NULL,0);
pMsg2 = new CSCPMessage(pRawMsg2);


Best regards,
Victor

Hi!

Could you please post screenshots with your configuration - DCI configuration, Threshold configuration, event processing policy?

Best regards,
Victor

Eto trebuet izmenenij v LogWatch. Na etu temu est' issue v bugtracker'e (#271), nadejus' chto k sledujuschemu relizu mi eto sdelaem.

Parametri, peredavaemie v sobitii na vozvrat znachenija k norme (standartnoe sobitie - SYS_THRESHOLDS_REARMED), otlichajutsja ot parametrov dlja sobitija na otklonenie ot normi (standartnoe sobitie - SYS_THRESHOLD_REACHED). Dlja SYS_THRESHOLD_REARMED parametri takie:

1) Parameter name
2) Description
3) DCI ID
4) Instance

Znachenija tam ne peredajutsja. Eto ne ochen' udachnoe reshenie, pravil'nej bilo bi imet' odinakovij nabor parametrov i v tom i v drugom sluchae, no sejchas uze slozno menjat' chto-to iz-za uze suschestvujuschih konfiguracij. Horoshego reshenija ja poka ne pridumal.

Hello!

Did you look at this example: https://www.netxms.org/documentation/confexample/? It has a bit outdated screenshots, but you should got the idea. Example is for CPU usage monitoring, but you can easily adapt it for disk space, etc. with simple changes.

Best regards,
Victor

Hi!

It's very strange. The only thing that was changed in port checker between 0.2.30 and 0.2.31 is that 0.2.31 has configurable connection timeout. On what platform you run port checker? Maybe it's platform-dependent bug.

Best regards,
Victor

Hi!

How do you monitor - via ServiceCheck.HTTP parameter or by creating network service object? What errors you get?

Best regards,
Victor

It's actually a bug in alarm notifier - it does not update alarm list correctly.

For knowing that node was offline for some time and then go back online, you can do the following:
Instead of terminating node down alarm when SYS_NODE_UP event received, generate new alarm with NORMAL priority which will replace "Node down" alarm. Than you will know that node was down for some time. Then you have 3 options to terminate those "Node up" alarms:
1. Terminate them manually;
2. Create a script that will use nxalarm command line utility to periodically read active alarms and terminate "Node up" alarms which are older than some time period;
3. Set alarm timeout for "Node up" alarms and terminate them when alarm timeout event comes.

Best regards,
Victor

А версия агента 0.2.31? Раньше был такой баг, но в 0.2.31 его исправили. Я попробовал только что у себя такую конфигурацию:


<parser trace="4">
   <file>*System</file>
   <rules>
      <rule>
         <id>7036</id>
         <source>Service Control Manager</source>
      </rule>
      <rule>
         <match>(.*)</match>
         <event params="1">100008</event>
      </rule>
   </rules>
</parser>


- работает как надо - посылает события на все записи в event log, кроме записей с ID 7036 и source "Service Control Manager".

Если версия агента 0.2.31 - попробуйте поставить trace и запустить агента в debug mode (nxagentd -D) - будем смотреть логи.

If you clear your database you will delete everything - configuration, collected data, etc. What kind of problems do you have?

Best regards,
Victor

Could you please try to get interface list from PBX with different SNMP tool - for example, with GetIf (http://www.wtcs.org/snmp4tpc/getif.htm)? If other tools will return empty interface list, than we will know that problem is with PBX SNMP agent, but if you will be able to see interface list with other tools, that will mean the bug in NetXMS.

Best regards,
Victor

Hi!

Web interface is implemented as read-only right now. To configure system, you should use Windows-based management console.

Best regards,
Victor

I don't have any experience with Avaya devices, but some common problems are:
1) may be switch does not respond to SNMP requests at all, due to incorrect community string, firewall settings, etc.?
2) may be some sort of security configuration on the device which restricts MIB tree access, and NetXMS server does not have access to interface part of MIB tree?

Could you please post entire output of configuration poll?

Best regards,
Victor

Hello!

First, I recommend you to stop your server and clean up alarms by executing SQL query

DELETE FROM alarms;

After that, please post your configuration - DCI configuration, threshold settings, and event processing policy. Most likely there are some problems with event processing configuration.

Best regards,
Victor