Xymon Mailing List Archive search

host grepping

7 messages in this thread

list Galen Johnson · Thu, 9 Jan 2014 22:16:53 +0000 ·
Hey,

I have to be missing something obvious...is there a command, like xymongrep, that will grep the host file and honor the include? Yes, I could script it but it would be nice if it was avalable...or if xymon grep could search for more than the test but the host or modifiers (like CLIENT: or NAME:). Or am I just an idiot and missing something obvious.

thx

=G=
list John Thurston · Thu, 09 Jan 2014 13:46:30 -0900 ·
quoted from Galen Johnson
On 1/9/2014 1:16 PM, Galen Johnson wrote:
Hey,

I have to be missing something obvious...is there a command, like xymongrep, that will grep the host file and honor the include?  Yes, I could script it but it would be nice if it was avalable...or if xymon grep could search for more than the test but the host or modifiers (like CLIENT: or NAME:).  Or am I just an idiot and missing something obvious.
Maybe you are looking for the 'xymoncfg' utility?

xymoncfg(1) dumps the full hosts.cfg file to stdout. It follows 
"include" tags in the hosts.cfg files, and prints the full contents as 
seen by the xymongen(1) and xymonnet(1) utilities.

-- 
    Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Galen Johnson · Thu, 9 Jan 2014 23:01:27 +0000 ·
Found that shortly after I sent the mail (isn't that always the case?).  

Feature request: It would be handy to have xymongrep handle more than just test lookups to save some scripting time.  I think it would be awesome if it was extended to allow you to reference a host and have it return the tests for just that host (especially when it may be spread across multiple entries) and allow an argument to get the CLIENT, NAME or other modifier as needed.

:-)

=G=
quoted from John Thurston

From: Xymon <xymon-bounces at xymon.com> on behalf of John Thurston <user-ce4d79d99bab@xymon.invalid>
Sent: Thursday, January 9, 2014 5:46 PM
To: xymon at xymon.com
Subject: Re: [Xymon] host grepping

On 1/9/2014 1:16 PM, Galen Johnson wrote:
Hey,

I have to be missing something obvious...is there a command, like xymongrep, that will grep the host file and honor the include?  Yes, I could script it but it would be nice if it was avalable...or if xymon grep could search for more than the test but the host or modifiers (like CLIENT: or NAME:).  Or am I just an idiot and missing something obvious.
Maybe you are looking for the 'xymoncfg' utility?

xymoncfg(1) dumps the full hosts.cfg file to stdout. It follows
"include" tags in the hosts.cfg files, and prints the full contents as
seen by the xymongen(1) and xymonnet(1) utilities.

--
    Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Jeremy Laidman · Tue, 14 Jan 2014 16:27:54 +1100 ·
quoted from Galen Johnson
On 10 January 2014 10:01, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:
Feature request: It would be handy to have xymongrep handle more than just
test lookups to save some scripting time.  I think it would be awesome if
it was extended to allow you to reference a host and have it return the
tests for just that host (especially when it may be spread across multiple
entries) and allow an argument to get the CLIENT, NAME or other modifier as
needed.
Does this help:

$ $XYMON $XYMSRV 'hostinfo host=^hostname'
hostname.example.com
|192.168.67.101|testip|delayred=dns:15,conn:15|delayyellow=dns:10,conn:10|dns=SOA:
example.com|TRENDS:*,vmstat:vmstat\pvmstat3


From the "xymon" man page:

       hostinfo [CRITERIA]
              Retrieves the current configuration of a  host  (i.e.
              the  hosts.cfg(5) definition). CRITERIA selects which
              host(s) to report, and is identical to  the  CRITERIA
              in the xymondboard command.

              The  response  is one line for each host that matches
              the CRITERIA, or all hosts if no criteria  is  speci-
              fied.  The  line  is  composed of a number of fields,
              separated by a pipe-sign. The first two  fields  will
              always  be  the  hostname  and  the  IP-address.  The
              remaining fields - if any - are the hosts.cfg tags in
              no particular order.

I like this one because a client can query its own configuration remotely,
or the test and configuration functions of the Xymon server can
(potentially) be distributed.

J
list Galen Johnson · Tue, 14 Jan 2014 15:35:52 +0000 ·
I'll have a look at that.  However, at first glance, it still requires that you know the hostname of the server that you are monitoring.  This is a bit problematic for amazon hosted servers that all begin with ec2 (^ec2).  I am setting up the NAME to be my key for the actual server since most of the servers are not in DNS (apparently zenoss can work with  amazon using tags which I may end up "re-discovering" for myself).  Here is what I ended up doing (yet it's kludgey and could like be done better using an awk script but my awk is very rusty)...

XYMONCFG=$XYMON_HOME/server/bin/xymoncfg
XYMON_NAME=`$XYMONCFG | $GREP $BBHOSTNAME | $SED -e 's/ /\n/g' | grep NAME`

yes...that is ugly and will likely suck for anything but my particular case.  That's why I was hoping xymongrep could be extended to handle grepping for more than just test names.

=G=
quoted from Jeremy Laidman

From: Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
Sent: Tuesday, January 14, 2014 12:27 AM
To: Galen Johnson
Cc: John Thurston; xymon at xymon.com
Subject: Re: [Xymon] host grepping

On 10 January 2014 10:01, Galen Johnson <user-87f955643e3d@xymon.invalid<mailto:user-87f955643e3d@xymon.invalid>> wrote:
Feature request: It would be handy to have xymongrep handle more than just test lookups to save some scripting time.  I think it would be awesome if it was extended to allow you to reference a host and have it return the tests for just that host (especially when it may be spread across multiple entries) and allow an argument to get the CLIENT, NAME or other modifier as needed.

Does this help:

$ $XYMON $XYMSRV 'hostinfo host=^hostname'

hostname.example.com<http://hostname.example.com>|192.168.67.101|testip|delayred=dns:15,conn:15|delayyellow=dns:10,conn:10|dns=SOA:example.com<http://example.com>|TRENDS:*,vmstat:vmstat\pvmstat3
quoted from Jeremy Laidman


From the "xymon" man page:

       hostinfo [CRITERIA]
              Retrieves the current configuration of a  host  (i.e.
              the  hosts.cfg(5) definition). CRITERIA selects which
              host(s) to report, and is identical to  the  CRITERIA
              in the xymondboard command.

              The  response  is one line for each host that matches
              the CRITERIA, or all hosts if no criteria  is  speci-
              fied.  The  line  is  composed of a number of fields,
              separated by a pipe-sign. The first two  fields  will
              always  be  the  hostname  and  the  IP-address.  The
              remaining fields - if any - are the hosts.cfg tags in
              no particular order.

I like this one because a client can query its own configuration remotely, or the test and configuration functions of the Xymon server can (potentially) be distributed.

J
list Galen Johnson · Wed, 15 Jan 2014 03:56:45 +0000 ·
Actually, I think this will make my sed command more sane.  I can at least be sure that splitting on the pipe will ensure I have a complete section regardless of whitespace.

=G=
quoted from Galen Johnson

From: Galen Johnson
Sent: Tuesday, January 14, 2014 10:35 AM
To: Jeremy Laidman
Cc: John Thurston; xymon at xymon.com
Subject: RE: [Xymon] host grepping

I'll have a look at that.  However, at first glance, it still requires that you know the hostname of the server that you are monitoring.  This is a bit problematic for amazon hosted servers that all begin with ec2 (^ec2).  I am setting up the NAME to be my key for the actual server since most of the servers are not in DNS (apparently zenoss can work with  amazon using tags which I may end up "re-discovering" for myself).  Here is what I ended up doing (yet it's kludgey and could like be done better using an awk script but my awk is very rusty)...

XYMONCFG=$XYMON_HOME/server/bin/xymoncfg
XYMON_NAME=`$XYMONCFG | $GREP $BBHOSTNAME | $SED -e 's/ /\n/g' | grep NAME`

yes...that is ugly and will likely suck for anything but my particular case.  That's why I was hoping xymongrep could be extended to handle grepping for more than just test names.

=G=

From: Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
Sent: Tuesday, January 14, 2014 12:27 AM
To: Galen Johnson
Cc: John Thurston; xymon at xymon.com
Subject: Re: [Xymon] host grepping

On 10 January 2014 10:01, Galen Johnson <user-87f955643e3d@xymon.invalid<mailto:user-87f955643e3d@xymon.invalid>> wrote:
Feature request: It would be handy to have xymongrep handle more than just test lookups to save some scripting time.  I think it would be awesome if it was extended to allow you to reference a host and have it return the tests for just that host (especially when it may be spread across multiple entries) and allow an argument to get the CLIENT, NAME or other modifier as needed.

Does this help:

$ $XYMON $XYMSRV 'hostinfo host=^hostname'
hostname.example.com<http://hostname.example.com>|192.168.67.101|testip|delayred=dns:15,conn:15|delayyellow=dns:10,conn:10|dns=SOA:example.com<http://example.com>|TRENDS:*,vmstat:vmstat\pvmstat3


From the "xymon" man page:

       hostinfo [CRITERIA]
              Retrieves the current configuration of a  host  (i.e.
              the  hosts.cfg(5) definition). CRITERIA selects which
              host(s) to report, and is identical to  the  CRITERIA
              in the xymondboard command.

              The  response  is one line for each host that matches
              the CRITERIA, or all hosts if no criteria  is  speci-
              fied.  The  line  is  composed of a number of fields,
              separated by a pipe-sign. The first two  fields  will
              always  be  the  hostname  and  the  IP-address.  The
              remaining fields - if any - are the hosts.cfg tags in
              no particular order.

I like this one because a client can query its own configuration remotely, or the test and configuration functions of the Xymon server can (potentially) be distributed.

J
list Henrik Størner · Sun, 19 Jan 2014 23:07:20 +0100 ·
quoted from Galen Johnson
Den 14-01-2014 16:35, Galen Johnson skrev:
I'll have a look at that.  However, at first glance, it still requires
that you know the hostname of the server that you are monitoring.  This
is a bit problematic for amazon hosted servers that all begin with ec2
(^ec2).  I am setting up the NAME to be my key for the actual server
since most of the servers are not in DNS (apparently zenoss can work
with  amazon using tags which I may end up "re-discovering" for
myself).
I took this as a suggestion to implement some searching features for 'hostinfo' and 'xymondboard' commands which I have wanted to do for some time.

Essentially, 4.3.14 lets you search on any of the tags defined in hosts.cfg. So you can e.g. get all of the hosts.cfg entries whose IP begins with 192.168 with

    xymon 127.0.0.1 "hostinfo XMH_IP=^192.168"

or all entries with a NAME containing "iis"

    xymon 127.0.0.1 "hostinfo XMH_DISPLAYNAME=iis"

The XMH_* names are listed in the xymon-xmh(5) man-page.

You can also pick the data that is included in the output. 'hostinfo' by default gives you the hostname, the ip and the raw hosts.cfg entry, but you can add a "fields" parameter to limit the output:

    xymon 127.0.0.1 "hostinfo tag=^http fields=ip,hostname,matchedtag"

searches for all the hosts that have a tag beginning with "http" (i.e. all hosts with a web-check) and outputs the IP, hostname and the http-tags that matched the search pattern. Much like xymongrep does.


The change is a bit large for posting to the mailing list, but I plan to ship 4.3.14 in a few days - the alert-crashing bug introduced in 4.3.13 is reason enough for a quick update.


Regards,
Henrik