Agent client collector issue

_navin9898
Tera Expert

Hi All,

 

Good day!

As part of agent client collector implementation, I am seeing an issue where agent record itself is getting inserted into 'cmdb_ci' table with a new class 'agent client collector' which doesn't look right. Please let me know if anyone else has faced same issue. Please consider below screenshot for your reference:

 

_navin9898_0-1732095397627.png

 

Best Regards,

ND

1 ACCEPTED SOLUTION

Hi @_navin9898,

 

Thats how it is... See how the record is created >>

 

When an ACC is first installed, the MID Server it is connected to will send a REST request to the instance. This causes the sn_agent_cmdb_ci_agent and sn_agent_ci_extended_info record pair to be created. From then on, every minute, the same REST message is sent to keep the records updated.

 

In the syslog_transaction table, this will look like a REST type transaction, created by the MID Server user, with URL /api/sn_agent/agents/updateClientTimestamp?api=api

 

The Agent Client Collector API (/api/sn_agent/agents) is defined by this Scripted REST Web Service record:
/sys_ws_definition.do?sys_id=cf0d4208c3e3030039a3553a81d3ae9a

And the updateClientTimestamp resource is defined in:
/sys_ws_operation.do?sys_id=b64dc208c3e3030039a3553a81d3ae76

That in turn makes use of Script Include MonitoringConfig, and it's functions updateClients and classifyClientsAndUpdate.
/sys_script_include.do?sys_id=6c62a3f0c305130039a3553a81d3ae88

This API handles 3 situations:

  • Newly installed ACCs
  • Full update
  • Update timestamp and status only.

If the ACC is new, insertNewClients function will insert the pair of records. Otherwise the function updateClientKeepAlive will update the values.

sn_agent_cmdb_ci_agent fields updated:

  • name
  • agent_id
  • ip_address

sn_agent_ci_extended_info fields updated:

  • status
  • mid
  • up_since
  • name
  • agent_id
  • ip_address
  • is_windows
  • agent_version

Note: The "Delete agent info" business rule ensures no "orphans" are left on sn_agent_ci_extended_info by deleting the corresponding sn_agent_ci_extended_info when a sn_agent_cmdb_ci_agent record is deleted. When this rule is inactive, "orphan" sn_agent_ci_extended_info records are kept which can lead to the empty sn_agent_cmdb_ci_agent records being created. This can happen if, as one example, an agent is deleted from the table however is still installed (the next keep alive will find the "orphan" sn_agent_ci_extended_info record and create an empty sn_agent_cmdb_ci_agent record).

 


☑️ Please mark responses as HELPFUL or ACCEPT SOLUTION to assist future users in finding the right solution....

LinkedIn - Lets Connect

View solution in original post

4 REPLIES 4

SK Chand Basha
Giga Sage

Hi @_navin9898 

 

Yes, It was expected behaviour we can able to see what are agents created sn_agent_cmdb_ci_agent.LIST mapped into cmdb_ci table there is one BR.

Sohail Khilji
Kilo Patron
Kilo Patron

Hi @_navin9898 ,

 

This is expected behavior. you will defiantly having this record in that table. Let me know what are you expecting with these records ?


☑️ Please mark responses as HELPFUL or ACCEPT SOLUTION to assist future users in finding the right solution....

LinkedIn - Lets Connect

Hi @Sohail Khilji 

Thanks for your response.

Yes, host info with other relevant attributes will be populated in 'cmdb_ci' table however if you look into the screenshot which I have attached, the few records gets inserted within 'cmdb_ci' table with prefix as 'Agent_' which is a agent record which doesn't look correct.

 

Best Regards,

ND

Hi @_navin9898,

 

Thats how it is... See how the record is created >>

 

When an ACC is first installed, the MID Server it is connected to will send a REST request to the instance. This causes the sn_agent_cmdb_ci_agent and sn_agent_ci_extended_info record pair to be created. From then on, every minute, the same REST message is sent to keep the records updated.

 

In the syslog_transaction table, this will look like a REST type transaction, created by the MID Server user, with URL /api/sn_agent/agents/updateClientTimestamp?api=api

 

The Agent Client Collector API (/api/sn_agent/agents) is defined by this Scripted REST Web Service record:
/sys_ws_definition.do?sys_id=cf0d4208c3e3030039a3553a81d3ae9a

And the updateClientTimestamp resource is defined in:
/sys_ws_operation.do?sys_id=b64dc208c3e3030039a3553a81d3ae76

That in turn makes use of Script Include MonitoringConfig, and it's functions updateClients and classifyClientsAndUpdate.
/sys_script_include.do?sys_id=6c62a3f0c305130039a3553a81d3ae88

This API handles 3 situations:

  • Newly installed ACCs
  • Full update
  • Update timestamp and status only.

If the ACC is new, insertNewClients function will insert the pair of records. Otherwise the function updateClientKeepAlive will update the values.

sn_agent_cmdb_ci_agent fields updated:

  • name
  • agent_id
  • ip_address

sn_agent_ci_extended_info fields updated:

  • status
  • mid
  • up_since
  • name
  • agent_id
  • ip_address
  • is_windows
  • agent_version

Note: The "Delete agent info" business rule ensures no "orphans" are left on sn_agent_ci_extended_info by deleting the corresponding sn_agent_ci_extended_info when a sn_agent_cmdb_ci_agent record is deleted. When this rule is inactive, "orphan" sn_agent_ci_extended_info records are kept which can lead to the empty sn_agent_cmdb_ci_agent records being created. This can happen if, as one example, an agent is deleted from the table however is still installed (the next keep alive will find the "orphan" sn_agent_ci_extended_info record and create an empty sn_agent_cmdb_ci_agent record).

 


☑️ Please mark responses as HELPFUL or ACCEPT SOLUTION to assist future users in finding the right solution....

LinkedIn - Lets Connect