10 More Discussions You Might Find Interesting
1. AIX
The monitoring tools what we have not able to see historical information about the process name or pid number for the process that consumed high CPU or memory or paging space. Can you please suggest some of the best monitoring tools available in the market that monitors primarily AIX and other Unix... (0 Replies)
Discussion started by: baladelaware73
0 Replies
2. Red Hat
Need assistance in finding a Graphical Monitoring tool open source for Centos , REDHAT linux which doesnt require "root" to compile the tool.
Tool that does performance monitoring for Disk usage, CPU, Memory ,Network stats
Need install and configure steps as well . (2 Replies)
Discussion started by: ajayram_arya
2 Replies
3. UNIX for Dummies Questions & Answers
Hello mates..
i need help with these things
*Users should be allowed to login only once, i.e Multiple logins from single user should be restricted and should issue an alert if any user tries .
*statistics of everyday log in time ,duration of login,and the commands executed by the user
*Alert... (6 Replies)
Discussion started by: safijunaid
6 Replies
4. Infrastructure Monitoring
I am interested whitch tools are the best by monitoring the UNIX processes and network interfaces ? and whitch tools for management UNIX ?
I know that the nagios very good monitoring tools, but interested me and others who have ? (4 Replies)
Discussion started by: danyy
4 Replies
5. Solaris
Hi folks
I am looking for tool which have graphical presentation for cpu and disk characteristics. Cpu is the least of the concern, disk is the most.
We use san devices and i know which id's correspond to it. But the problem is that at least one of the tool I tried to use - Quest Sportlight does... (6 Replies)
Discussion started by: ggolub
6 Replies
6. AIX
Are there any AIX 4.2 commands that would give me the ability to monitor the hardware temperature ?
I did a forum search and found nothing about AIX. I checked the 'diag' command but it does not say anywhere that it has this feature. I tried the 'prtdiag' command but it does not exist on the... (6 Replies)
Discussion started by: Browser_ice
6 Replies
7. Red Hat
Hi,
In HPUX there is a grate monitor tools named GLANCE, which give you
information on the disks load, memory usage, cpu ...
What is the equivalent tool in LINUX Redhat 4.
Thanks (3 Replies)
Discussion started by: yoavbe
3 Replies
8. UNIX for Advanced & Expert Users
Guys, I would like to know who are using monitoring tools? I use Nagios before but it seems is more on Linux and Windows platform.
- Nagios
- BigBrother
- BigSister
- Cacti
- MRTG
- JFFNMS
- anymore? Please give comment too
I would like to have some comment on UNIX monitoring tools.... (2 Replies)
Discussion started by: dwarf007
2 Replies
9. Infrastructure Monitoring
I need some monitoring tools for SCO 7.1.4
Does anybody reccomend some software that I can install to monitor mem leaks and odd SAR values etc (2 Replies)
Discussion started by: trebor1
2 Replies
10. IP Networking
Any idea where can I get a freware to monitor the network traffic in my department? The best is this tool can store the log files. Thanks! (5 Replies)
Discussion started by: zheng_soon
5 Replies
CLIENT-LOCAL.CFG(5) File Formats Manual CLIENT-LOCAL.CFG(5)
NAME
client-local.cfg - Local configuration settings for Xymon clients
SYNOPSIS
~xymon/server/etc/client-local.cfg
DESCRIPTION
The client-local.cfg file contains settings that are used by each Xymon client when it runs on a monitored host. It provides a convenient
way of configuring clients from a central location without having to setup special configuration maintenance tools on all clients.
The client-local.cfg file is currently used to configure what logfiles the client should fetch data from, to be used as the basis for the
"msgs" status column; and to configure which files and directories are being monitored in the "files" status column.
Note that there is a dependency between the client-local.cfg file and the hobbit-clients.cfg(5) file. When monitoring e.g. a logfile, you
must first enter it into the client-local.cfg file, to trigger the Xymon client into reporting any data about the logfile. Next, you must
configure hobbit-clients.cfg so the Xymon server knows what to look for in the file data sent by the client. So: client-local.cfg defines
what raw data is collected by the client, and hobbit-clients.cfg defines how to analyze them.
PROPAGATION TO CLIENTS
The client-local.cfg file resides on the Xymon server.
When clients connect to the Xymon server to send in their client data, they will receive part of this file back from the Xymon server. The
configuration received by the client is then used the next time the client runs.
This method of propagating the configuration means that there is a delay of up to two poll cycles (i.e. 5-10 minutes) from a configuration
change is entered into the client-local.cfg file, and until you see the result in the status messages reported by the client.
FILE FORMAT
The file is divided into sections, delimited by "[name]" lines. A section name can be either an operating system identifier - linux,
solaris, hp-ux, aix, freebsd, openbsd, netbsd, darwin - or a hostname. When deciding which section to send to a client, Xymon will first
look for a section named after the hostname of the client; if such a section does not exist, it will look for a section named by the oper-
ating system of the client. So you can configure special configurations for individual hosts, and have a default configuration for all
other hosts of a certain type.
Apart from the section delimiter, the file format is free-form, or rather it is defined by the tools that make use of the configuration.
LOGFILE CONFIGURATION ENTRIES
A logfile configuration entry looks like this:
log:/var/log/messages:10240
ignore MARK
trigger Oops
The log:FILENAME:SIZE line defines the filename of the log, and the maximum amount of data (in bytes) to send to the Xymon server. FILENAME
is usually an explicit full-path filename on the client. If it is enclosed in backticks, it is a command which the Xymon client runs and
each line of output from this command is then used as a filename. This allows scripting which files to monitor, e.g. if you have logfiles
that are named with some sort of timestamp.
The ignore PATTERN line (optional) defines lines in the logfile which are ignored entirely, i.e. they are stripped from the logfile data
before sending it to the Xymon server. It is used to remove completely unwanted "noise" entries from the logdata processed by Xymon. "PAT-
TERN" is a regular expression.
The trigger PATTERN line (optional) is used only when there is more data in the log than the maximum size set in the "log:FILENAME:SIZE"
line. The "trigger" pattern is then used to find particularly interesting lines in the logfile - these will always be sent to the Xymon
server. After picking out the "trigger" lines, any remaining space up to the maximum size is filled in with the most recent entries from
the logfile. "PATTERN" is a regular expression.
COUNTING LOGENTRIES
A special type of log-handling is possible, where the number of lines matching a regular expressions are merely counted. This is
linecount:FILENAME, followed by a number of lines of the form ID:PATTERN. E.g.
linecount:/var/log/messages
diskerrors:I/O error.*device.*hd
badlogins:Failed login
FILE CONFIGURATION ENTRIES
A file monitoring entry is used to watch the meta-data of a file: Owner, group, size, permissions, checksum etc. It looks like this:
file:/var/log/messages[:HASH]
The file:FILENAME line defines the filename of the file to monitor. As with the "log:" entries, a filename enclosed in backticks means a
command which will generate the filenames dynamically. The optional [:HASH] setting defines what type of hash to compute for the file: md5,
sha1 or rmd160. By default, no hash is calculated.
NOTE: If you want to check multiple files using a wildcard, you must use a command to generate the filenames. Putting wildcards directly
into the file: entry will not work.
DIRECTORY CONFIGURATION ENTRIES
A directory monitoring entry is used to watch the size of a directory and any sub-directories. It looks like this:
dir:DIRECTORYNAME
The dir:DIRECTORYNAME line defines the filename of the file to monitor. As with the "log:" entries, a filename enclosed in backticks means
a command which will generate the filenames dynamically. The Xymon client will run the du(1) command with the directoryname as parameter,
and send the output back to the Xymon server.
NOTE: If you want to check multiple directories using a wildcard, you must use a command to generate the directory names. Putting wildcards
directly into the dir: entry will not work. E.g. use something like
dir:`find /var/log -maxdepth 1 -type d`
The "du" command used can be configured through the DU environment variable. On some systems, by default du reports data in disk blocks
instead of KB (e.g. Solaris). So you may want to configure the Xymon client to use a du command which reports data in KB, e.g. by setting
DU="du -k"
in the hobbitclient.cfg file.
NOTES
The ability of the Xymon client to calculate file hashes and monitor those can be used for file integrity validation on a small scale. How-
ever, there is a significant processing overhead in calculating these every time the Xymon client runs, so this should not be considered a
replacement for host-based intrusion detection systems such as Tripwire or AIDE.
Use of the directory monitoring on directory structures with a large number of files and/or sub-directories can be quite ressource-inten-
sive.
SEE ALSO
hobbit-clients.cfg(5), hobbitd_client(8), hobbitd(8), xymon(7)
Xymon Version 4.2.3: 4 Feb 2009 CLIENT-LOCAL.CFG(5)
