NetXMS Support Forum

Could you please post complete error message from server's log?

Best regards,
Victor

Did you have libmysqlclient.so somewhere in the system? If yes, where?

Best regards,
Victor

Poprobujte zamenit' faili node.cpp i interface.cpp v src/server/core na prilozennie i peresobrat' server.

Please post your config.log

Best regards,
Victor

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