In some Linux / Unix / Solaris configurations, you may notice that the Uptime Infrastructure Monitor Agent is repeatedly logging connection warnings in the
/var/adm/messages log. This is usually normal behaviour as xinetd/inetd is set up to log any connections to its services by default.
In the case of the Uptime Infrastructure Monitor Agent, this practice can result in very large log files, as every time the Monitoring Station polls the Agent or runs a Service Monitor, the connection will be logged.
If you want to disable this logging for the Uptime Infrastructure Monitor Agent service, there are a couple of different approaches to take. The option to use depends on the OS, and how the xinetd/inetd/syslogd settings are configured. So please make sure you are using the appropriate option for your environment.

1. Disable or suppress warning level messages via the appropriate config file for your Operating System's logging tool, and how your agent is currently running

...

/dev/null to suppress the logging completely
(i.e. log_type = FILE /dev/null or log_type = FILE /var/tmp/uptimeagent.log).

Related articles

Image Removed  How to display the NetFlow dashboard using IE Image Removed   /var/adm/messages kernel: cdrom: open failed
Image Removed  Suppress Connection Warnings from the Agent in /var/adm/messages Monitor Disk Mounting in Active / Passive Cluster Nodes

 

Anchor
Suppress Linux agent inetd uptmagnt conn Suppress Linux agent inetd uptmagnt conn

Use the following steps to reduce the number of messages recorded in var/log/messages files on Red Hat Linux agents:
Edit the uptimeagent or uptmagnt file under /etc/xinetd.d and add the following lines between the {} characters: log_on_success -= PID
log_on_success -= EXIT log_on_success -= HOST DURATION log_on_failure -= HOST
Restart the xinetd process.
To test if the agent is still logging messages, run a tail -f on messages and then poll the Agent from the Uptime Infrastructure Monitor user interface to see if this action logs a new message.

Anchor
System stats change in Resource Usage re System stats change in Resource Usage re

Many of the system total fields for a target agent are based on the latest known configuration at the latest period of the report window. For example, in the Resource Usage report, # of CPUs, memory size, swap size, CPU utilization and memory utilization take the available capacity at the end of the reporting window as the baseline figure for total capacity. Configuration changes on the system and rescanning of the host in question during the time range included in the report may change these values, even if the collected performance data is unchanged.
This scenario would potentially produce a report of the same data that shows different values depending on the report timeframe. For example: Configuration Changes
Change Detected Change Description
2010-01-27 15:04:43 Memory size changed from 18874368kB to 4194304kB 2010-01-27 11:18:54 Memory size changed from 4194304kB to 18874368kB 2010-01-27 09:15:01 Memory size changed from 18874368kB to 4194304kB 2010-01-27 06:47:17 Memory size changed from 4194304kB to 18874368kB
If we were to run a report on Jan 27 for the system with the above configuration changes, we would see that some reports show memory at 18 Gb, some at 4 Gb and the average as n/a.