IBM Support

ITM Agent Insights: Agentless Linux monitoring agent (R4) missing subnodes under "Managed Systems"

Technical Blog Post


Abstract

ITM Agent Insights: Agentless Linux monitoring agent (R4) missing subnodes under "Managed Systems"

Body

Agentless Linux monitoring agent - R4 - does not display remote Linux endpoints under "Managed Systems" in TEP navigator:

image

 

 

Confirm that the R4 agent instance has been configured to communicate with remote Linux endpoints, and the specific details used for SNMP version / remote system IP.

Reference:

ITM Agent Insights: Agentless Linux monitoring agent (R4) configuration walk-through
https://ibm.biz/BdZWex

 

Verify that SNMP daemon is running on the remote Linux endpoint and that the snmpd.conf is configured correctly to include necessary "systemview" entries to provide OID details to R4 agent requests.

 

To set up the SNMP environment on a remotely monitored Linux endpoint, it is necessary to add three "systemview" lines to the snmpd.conf and start the SNMP daemon:


# Third, create a view for us to let the group have rights to:
# Make at least snmpwalk -v 1 localhost -c public system fast again.
# name incl/excl subtree mask(optional)
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1

view systemview included .1.3.6.1.2.1.25
view systemview included .1.3.6.1.4.1.2021
view systemview included .1.3.6.1.2.1.2


The last line is for the Network attribute group, which was missing from the detailed instructions in the product manual, and was determined by reviewing the OIDs that the R4 agent references by reviewing the queries in the kr4.ref file.

For example,

hrStorageUsed uses OID=
1.3.6.1.2.1.25.2.3.1.6 which was not included originally.
<metric key="false" metricName="hrStorageUsed" name="Used_Blocks" oid="
1.3.6.1.2.1.25.2.3.1.6" size="8" type="NUMERIC_64BIT_DATA" visible="true"/>


<metric key="true" metricName="ifIndex" name="Index" oid="
1.3.6.1.2.1.2.2.1.1" size="4" type="NUMERIC_DATA" visible="true"/>

 

Clarification to product documentation has been submitted through DOC APAR IV88506 to be included in future manuals.
 

IV88506: CLARIFY AGENTLESS CONFIGURATION STEP REQUIRED FOR REDHAT.
http://www-01.ibm.com/support/docview.wss?uid=swg1IV88506

 

The section of product documentation that needed to be clarified:

***
2. For Red Hat operating systems, the /etc/snmpd.conf must be modified to allow the Host Resources MIB and ucdavis MIB to be viewed by all users.
3. Add the following system views to the SNMP configuration:

a. view systemview included .1.3.6.1.2.1.25
b. view systemview included .1.3.6.1.4.1.2021

***
So in the above, there are 3 issues.

1) the location of snmpd.conf on Red Hat operating systems is NOT in /etc directory... it is in /etc/snmp directory.

On a Red Hat Linux system.
/etc/snmp/snmptrapd.conf
/etc/snmp/snmpd.conf

On an AIX system.
/etc/snmpd.conf
/etc/snmpdv3.conf


2) step #2 indicating the need to allow the Host Resources MIB and ucdavis MIB to be viewed by all users is written in a way as to indicate that it is a separate step from #3, so it is easily confused by customers where they ask, "How do I modify the snmpd.conf to allow for these two MIBs".

Step #3 of including the two oid values to systemview is how to accomplish #2, but the way it is written is not clear.

3) the completely missing OID to add for Network attribute group that adds a 3rd "view systemview included" line


 

After adding the necessary systemview lines, confirm the SNMP daemon is started:

# service snmpd start
Starting snmpd: [ OK ]


After starting SNMP daemon, recycle the R4 agent and refresh the TEP to confirm whether the subnodes are visible in the TEP under the separate R4 instances.

image

 

Confirm that workspaces are populating with data by clicking on the "Disk" / "Memory" / "Network" navigator items to verify data collection from the remote Linux endpoint.

 

 

*NOTE*
In order for the R4 agent installed on a supported platform to be able to monitor remotely a specific flavor of Linux system, the remote Linux system must be able to respond to the data collection requests that the R4 agent initiates through SNMP wit h specific OIDs.  As long as the remote Linux system is running an SNMP provider that is written to the standards and supports / returns data for the necessary OIDS, the R4 agent queries to gather the data should work.

 

If subnodes are missing:

Check the "Data Collection Status" workspace in the TEPto determine if there is an error being reported.
Verify network connectivity with the remote Linux endpoint by making sure it can be reached with tool such as ping from the R4 agent system.

Make sure there are no firewalls blocking communications on the SNMP port (UDP 161).
Confirm whether external command "snmpwalk" is able to query OIDs from the R4 system to the remote Linux endpoint.

If "snmpwalk" commands work, verify the R4 agent instance has been configured with the same SNMP protocol / community strings / passwords that work with the external snmpwalk command.

 

Review R4 agent RAS1 logging for any "timeout" issue:

The RAS1 logging with default level "ERROR" showing no response from remote Linux endpoint:
 

snmpqueryclass.cpp,2041,"internalCollectData") Timeout occurred. No response from agent 123.123.123.123.
snmpqueryclass.cpp,1389,"handle_snmp_response_async") ERROR: decoded PDU is null -- this is a timeout scenario
configdiscoveryqueryclass.cpp,250,"internalCollectData") Removing R4:<subnode>:LNX node, no valid data collection.

 

If experiencing timeouts with R4 agent, but the external "snmpwalk" commands complete, the offline managed systems may be due to a performance issue where SNMP is not responsive in the default times that ITM uses.  The IBM Tivoli Monitoring SNMP data provider is multithreaded to enhance performance. The SNMP data source that is being monitored might not be able to respond to multiple incoming requests in a timely manner.

There are tuning options that can improve reliability of SNMP data collections for the R4 agent:

Reduce the thread pool size
The default thread pool size is 15.
Try reducing the size to 5. This setting can be adjusted in the agent ENV file by setting the environment variable.

Increase the SNMP Response Timeout
The default SNMP Timeout is 2 seconds.
Try increasing the timeout to 10 seconds. This setting can be adjusted in the agent ENV file by setting the CDP_SNMP_RESPONSE_TIMEOUT environment variable.

Reduce the number of SNMP retries
The default number of SNMP retries is 2.
Try reducing the size to 1. This setting can be adjusted in the agent ENV file by setting the CDP_SNMP_MAX_RETRIES environment variable.


In the
r4_<instance>.cfg, set the following:

CDP_DP_THREAD_POOL_SIZE="5"
CDP_SNMP_RESPONSE_TIMEOUT="10"
CDP_SNMP_MAX_RETRIES="1"

Then recycle the R4 agent and review RAS1 logs to confirm whether the logs still report timeouts to the remote Linux systems configured to gather SNMP data from that are not being displayed in the TEP navigator as subnodes under "Managed Systems".

 

Submitter: drd401709

Compid: 5724C04RL - Agentless Monitoring for Linux Operating Systems
Reference DCF technotes:

Keywords: kr4agent

 

Additional ITM Agent Insights series of IBM Tivoli Monitoring Agent blogs are indexed under ITM Agent Insights: Introduction.

 

Tutorials Point

Subscribe and follow us for all the latest information directly on your social feeds:

 

imageimageimage

Check out all our other posts and updates:

Academy Blogs
Academy Videos
Academy Google+
Academy Twitter

image

 

 

Additional ITM Agent Insights series of IBM Tivoli Monitoring Agent blogs are indexed under ITM Agent Insights: Introduction.

 

Tutorials Point

Subscribe and follow us for all the latest information directly on your social feeds:

 

imageimageimage

Check out all our other posts and updates:

Academy Blogs
Academy Videos
Academy Google+
Academy Twitter

image

 

[{"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]

UID

ibm11083087