Agent information 🔗 link

wrote:

Hi Team

I am new to xymon and trying to learn about it. But I am unable to figure
out few questions.

1. I run xymon client installation by apt-get. but can you tell me what is
actually running or getting installed in my system is it a rpm or what?
2. how my agent works. how does it gains information from the system it is
running on.
3. what is the architecture of the xymon.

I would really appreciate your help. Please give me the insight of the
tool.

--
Thanks and Regards

*Sanjana *

On 28 January 2015 at 14:31, J.C. Cleaver <user-87556346d4af@xymon.invalid> wrote:

On Tue, January 27, 2015 7:14 pm, Jeremy Laidman wrote:

*snipped*

That's such an awesome summary I might just have to steal that for our
internal team documentation :)

wrote:

Sanjana

The apt-get tool is for Debian-based systems, including Ubuntu.  These use
the "deb" packaging format, which is different from the "rpm" (Red Hat
Package Manager) format that other systems (not just Red Hat) use.

You can list the files installed by a "deb" package using the "dpkg"
tool.  So the following might list the files that were installed by apt-get
for you:

  dpkg --listfiles xymon-client

I don't know the name of the package that you installed, but substitute as
appropriate.  If you don't know the package name either, running "dpkg
--list | grep xymon" might show you.

The client package typically creates a client directory structure with
subdirectories called "bin", "etc", "ext", "tmp" and "log".  Some of these
might be symbolic links to other directories.  You might find these all
under /usr/lib/hobbit/client/.

The client package would also install a start-up or "init" script to start
the "xymonlaunch" daemon at boot time.  In some releases of the package,
the init script actually runs another script called runclient.sh, and this
in turn runs xymonlaunch. Either way, the goal is to have xymonlaunch
running in memory.  Once started, the xymonlaunch process runs everything
else that's required to perform the Xymon agent tasks.

The xymonlaunch process looks at the clientlaunch.cfg file (probably in
the "etc" subdirectory) and starts processes that are defined in that
file.  The only thing that needs to run from clientlaunch.cfg is what is
defined in the [client] section.  This section tells xymonlaunch to run the
"xymonclient.sh" script every 5 minutes.

Assuming a default "central mode" installation, the xymonclient.sh script
has two main tasks.  The first task is to collect local client data (CPU
usage, disk usage, etc) for reporting to the Xymon server.  The second task
is to fetch any (optional) configuration data from the Xymon server and
store it in a temporary file.  The temporary file is used to collect
additional client data to send to the Xymon server on the next run.

As mentioned, the client data collection is performed by the
xymonclient.sh script.  One of the first things this script does it to work
out the type of system on which it is running.  It then runs an OS-specific
script as appropriate.  For example, on a Linux system, xymonclient.sh will
run xymonclient-linux.sh.  The OS-specific script is where the majority all
the data is actually collected.  It's all collated into a client message
format and written out for xymonclient.sh to collect and report back to the
Xymon server.

The client message is sent back to the Xymon server over a TCP connection
on port 1984.  The Xymon server collects this message, parses the different
sections for useful metrics, and uses the data to create status information
and RRD files for graphing.  All of the status information is stored in
html files on disk, so that a web server, such as Apache, can display it
all.  Some information, such as the various graphs of performance metrics,
is dynamic, and uses some CGI scripts to be called by the web server.

The Xymon server also runs a xymonlaunch process, and has a similar
configuration file called tasks.cfg.  There's much more that goes on here,
so there are many more processes started by the server from the tasks.cfg
file.

The Xymon server's different components communicate with each other via
various message formats.  I've mentioned a "client" message containing
client data.  There are other messages also, such as "status" messages that
some the Xymon server components can report "red" or "yellow" or "green"
conditions.  Each message type has its own "channel" handler.  For example,
a client message usually contains a [df] section with the output of the
"df" command, and this includes disk usage figures.  The xymond process
gives the message to the xymond_client process, which parses the [df]
section for disk usage levels, and if a threshold is exceeded (90% by
default) then xymond_client will send a "status" message over TCP port 1984
containing the alert colour ("yellow" for 90%) and other information.  The
status message is then received by xymond which updates the "disk" status
page for the server in question.  The xymond process also sends the status
message to the xymond_rrd process so that it can add the disk usage
percentages to an RRD file for graphing.

Xymon clients can also send message types other than "client" messages,
and the most common one is the "status" message that I've already
mentioned.  In fact, the forerunner to Xymon, called Big Brother, status
messages almost exclusively, and the "client" message is a much more recent
invention.

One of Xymon's awesome features is how extensible it is, and the "status"
message is the classic way to extend Xymon's functionality.  The "ext"
subdirectory on a client is usually where extension scripts are located
(but they could be anywhere).  You can write a script to monitor anything
you like, and report it to the Xymon server using a status message.  Such a
script can be as simple as:

#!/bin/sh
RESULT=`sudo smartctl -H /dev/sda0 2>&1`
if echo "$RESULT" | grep "Status: OK"; then
    COL="green"
else
    COL="red"
fi
printf "status $MACHINE.smart $COL SMART status $COL\n$RESULT\n" | $XYMON
$XYMSRV @

You simply arrange for the script to be run every 5 minutes as an "ext"
script, and you'll end up with a new "smart" status page (and a
corresponding green, yellow or red dot on the summary page) on your Xymon
server web interface.

This is fairly simplistic overview, and there are many features I haven't
mentioned, but I hope it answers some of your questions.  The official
introduction to Xymon is here:

http://xymon.sourceforge.net/xymon/help/manpages/man7/xymon.7.html

Cheers
Jeremy

On 28 January 2015 at 00:09, Sanjana Ahlawat <user-77fc87da24c5@xymon.invalid

wrote:

Hi Team

I am new to xymon and trying to learn about it. But I am unable to figure
out few questions.

1. I run xymon client installation by apt-get. but can you tell me what
is actually running or getting installed in my system is it a rpm or what?
2. how my agent works. how does it gains information from the system it
is running on.
3. what is the architecture of the xymon.

I would really appreciate your help. Please give me the insight of the
tool.

--
Thanks and Regards

*Sanjana *

-- 

On Tue, January 27, 2015 10:37 pm, Sanjana Ahlawat wrote:

Thanks for the prompt reply. Many of my doubts got cleared from what you
have answered but I would be really pleased if u can provide little more
information on the process of data collection by client. It is clear that
xymonclient.sh collects the data and is than forwarded to the server. But
my main query is how does this collects(xymonclient.sh) data. I have an
understanding that message data is read from system logs or error logs,
but what about the cpu, disk and other information.

Thanks and Regard
Sanjana

On Wed, Jan 28, 2015 at 8:44 AM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
wrote:

Sanjana

The apt-get tool is for Debian-based systems, including Ubuntu.  These
use
the "deb" packaging format, which is different from the "rpm" (Red Hat
Package Manager) format that other systems (not just Red Hat) use.

You can list the files installed by a "deb" package using the "dpkg"
tool.  So the following might list the files that were installed by
apt-get
for you:

  dpkg --listfiles xymon-client

I don't know the name of the package that you installed, but substitute
as
appropriate.  If you don't know the package name either, running "dpkg
--list | grep xymon" might show you.

The client package typically creates a client directory structure with
subdirectories called "bin", "etc", "ext", "tmp" and "log".  Some of
these
might be symbolic links to other directories.  You might find these all
under /usr/lib/hobbit/client/.

The client package would also install a start-up or "init" script to
start
the "xymonlaunch" daemon at boot time.  In some releases of the package,
the init script actually runs another script called runclient.sh, and
this
in turn runs xymonlaunch. Either way, the goal is to have xymonlaunch
running in memory.  Once started, the xymonlaunch process runs
everything
else that's required to perform the Xymon agent tasks.

The xymonlaunch process looks at the clientlaunch.cfg file (probably in
the "etc" subdirectory) and starts processes that are defined in that
file.  The only thing that needs to run from clientlaunch.cfg is what is
defined in the [client] section.  This section tells xymonlaunch to run
the
"xymonclient.sh" script every 5 minutes.

Assuming a default "central mode" installation, the xymonclient.sh
script
has two main tasks.  The first task is to collect local client data (CPU
usage, disk usage, etc) for reporting to the Xymon server.  The second
task
is to fetch any (optional) configuration data from the Xymon server and
store it in a temporary file.  The temporary file is used to collect
additional client data to send to the Xymon server on the next run.

As mentioned, the client data collection is performed by the
xymonclient.sh script.  One of the first things this script does it to
work
out the type of system on which it is running.  It then runs an
OS-specific
script as appropriate.  For example, on a Linux system, xymonclient.sh
will
run xymonclient-linux.sh.  The OS-specific script is where the majority
all
the data is actually collected.  It's all collated into a client message
format and written out for xymonclient.sh to collect and report back to
the
Xymon server.

The client message is sent back to the Xymon server over a TCP
connection
on port 1984.  The Xymon server collects this message, parses the
different
sections for useful metrics, and uses the data to create status
information
and RRD files for graphing.  All of the status information is stored in
html files on disk, so that a web server, such as Apache, can display it
all.  Some information, such as the various graphs of performance
metrics,
is dynamic, and uses some CGI scripts to be called by the web server.

The Xymon server also runs a xymonlaunch process, and has a similar
configuration file called tasks.cfg.  There's much more that goes on
here,
so there are many more processes started by the server from the
tasks.cfg
file.

The Xymon server's different components communicate with each other via
various message formats.  I've mentioned a "client" message containing
client data.  There are other messages also, such as "status" messages
that
some the Xymon server components can report "red" or "yellow" or "green"
conditions.  Each message type has its own "channel" handler.  For
example,
a client message usually contains a [df] section with the output of the
"df" command, and this includes disk usage figures.  The xymond process
gives the message to the xymond_client process, which parses the [df]
section for disk usage levels, and if a threshold is exceeded (90% by
default) then xymond_client will send a "status" message over TCP port
1984
containing the alert colour ("yellow" for 90%) and other information.
The
status message is then received by xymond which updates the "disk"
status
page for the server in question.  The xymond process also sends the
status
message to the xymond_rrd process so that it can add the disk usage
percentages to an RRD file for graphing.

Xymon clients can also send message types other than "client" messages,
and the most common one is the "status" message that I've already
mentioned.  In fact, the forerunner to Xymon, called Big Brother, status
messages almost exclusively, and the "client" message is a much more
recent
invention.

One of Xymon's awesome features is how extensible it is, and the
"status"
message is the classic way to extend Xymon's functionality.  The "ext"
subdirectory on a client is usually where extension scripts are located
(but they could be anywhere).  You can write a script to monitor
anything
you like, and report it to the Xymon server using a status message.
Such a
script can be as simple as:

#!/bin/sh
RESULT=`sudo smartctl -H /dev/sda0 2>&1`
if echo "$RESULT" | grep "Status: OK"; then
    COL="green"
else
    COL="red"
fi
printf "status $MACHINE.smart $COL SMART status $COL\n$RESULT\n" |
$XYMON
$XYMSRV @

You simply arrange for the script to be run every 5 minutes as an "ext"
script, and you'll end up with a new "smart" status page (and a
corresponding green, yellow or red dot on the summary page) on your
Xymon
server web interface.

This is fairly simplistic overview, and there are many features I
haven't
mentioned, but I hope it answers some of your questions.  The official
introduction to Xymon is here:

http://xymon.sourceforge.net/xymon/help/manpages/man7/xymon.7.html

Cheers
Jeremy

On 28 January 2015 at 00:09, Sanjana Ahlawat
<user-77fc87da24c5@xymon.invalid

wrote:

Hi Team

I am new to xymon and trying to learn about it. But I am unable to
figure
out few questions.

1. I run xymon client installation by apt-get. but can you tell me what
is actually running or getting installed in my system is it a rpm or
what?
2. how my agent works. how does it gains information from the system it
is running on.
3. what is the architecture of the xymon.

I would really appreciate your help. Please give me the insight of the
tool.

--
Thanks and Regards

*Sanjana *

--
Thanks and Regards


*Sanjana Wily Admin Team,Gateway Software Solutions Pvt. Ltd.249(A) , 1st
FloorEast of Kailash , Sant NagarNew Delhi-110065,
user-28e2a8438efa@xymon.invalid <user-77fc87da24c5@xymon.invalid>*

On 29 January 2015 at 06:29, J.C. Cleaver <user-87556346d4af@xymon.invalid> wrote:

All of those values are collected as the raw output from various unix
shell commands.