You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

(i.e. xinet.d, init.d or daemon mode).
OR

  1. Edit the /etc/xinetd.d/uptimeagent file and change the log type to only log EMERG level messages, which will suppress the warning level connection messages

(i.e. log_type = SYSLOG authpriv emerg). OR

  1. Edit the /etc/xinetd.d/uptimeagent file, and change the the log_type to FILE, and either log to an Uptime Infrastructure Monitor agent only log, or

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

Related articles

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



 
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.
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.

  • No labels