Xymon Mailing List Archive search

Does xymongrep work?

4 messages in this thread

list John Thurston · Fri, 12 Feb 2016 12:47:41 -0900 ·
I'm having difficulty with xymongrep, and it isn't related to 4.3.25 
because I see the same behavior on 4.3.22.

If I use the command:
  ~/server/bin/xymongrep --debug --hosts=./server/etc/hosts.cfg  *

I get
7667 2016-02-12 12:37:15.937475 Loading host configuration from ./server/etc/hosts.cfg
7667 2016-02-12 12:37:15.937872 Opening file ./server/etc/hosts.cfg
7667 2016-02-12 12:37:15.939296 Opening file ./server/etc//retired_hosts
7667 2016-02-12 12:37:15.939637 Opening file ./server/etc//external_hosts
I can't get it to kick back anything. I've tried prefixing it with 
xymoncmd, using --test-untagged, naming specific tests.
The undocumented --no-down causes it to
12870 2016-02-12 12:44:53.038374 Connect status is 0
12870 2016-02-12 12:44:53.038414 Sent 52 bytes
12870 2016-02-12 12:44:53.044933 Read 8192 bytes
12870 2016-02-12 12:44:53.044985 Read 13829 bytes
12870 2016-02-12 12:44:53.045010 Closing connection
Does xymongrep work for anyone else?

-- 
    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 Japheth Cleaver · Fri, 12 Feb 2016 14:44:50 -0800 ·
quoted from John Thurston

On Fri, February 12, 2016 1:47 pm, John Thurston wrote:
I'm having difficulty with xymongrep, and it isn't related to 4.3.25
because I see the same behavior on 4.3.22.

If I use the command:
  ~/server/bin/xymongrep --debug --hosts=./server/etc/hosts.cfg  *

I get
7667 2016-02-12 12:37:15.937475 Loading host configuration from
./server/etc/hosts.cfg
7667 2016-02-12 12:37:15.937872 Opening file ./server/etc/hosts.cfg
7667 2016-02-12 12:37:15.939296 Opening file ./server/etc//retired_hosts
7667 2016-02-12 12:37:15.939637 Opening file
./server/etc//external_hosts
I can't get it to kick back anything. I've tried prefixing it with
xymoncmd, using --test-untagged, naming specific tests.
The undocumented --no-down causes it to
12870 2016-02-12 12:44:53.038374 Connect status is 0
12870 2016-02-12 12:44:53.038414 Sent 52 bytes
12870 2016-02-12 12:44:53.044933 Read 8192 bytes
12870 2016-02-12 12:44:53.044985 Read 13829 bytes
12870 2016-02-12 12:44:53.045010 Closing connection
Does xymongrep work for anyone else?

Hi,

It looks like it's successfully reading the config files and/or getting
current data from xymond.

Have you tried escaping the '*'? It's possible your shell is eating it off
the command line.

For the specific tests, remember that this will only work for tests
actually specified in hosts.cfg (and includes).... "xymongrep conn" or
"xymongrep disk" won't work since those tests aren't proscribed in the
config. (For something similar, you can run a xymondboard command by hand
though...)


HTH,
-jc
quoted from John Thurston

--
    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 John Thurston · Fri, 12 Feb 2016 14:36:42 -0900 ·
quoted from Japheth Cleaver
On 2/12/2016 1:44 PM, J.C. Cleaver wrote:

On Fri, February 12, 2016 1:47 pm, John Thurston wrote:
I'm having difficulty with xymongrep, and it isn't related to 4.3.25
because I see the same behavior on 4.3.22.

If I use the command:
   ~/server/bin/xymongrep --debug --hosts=./server/etc/hosts.cfg  *
- snip -
quoted from Japheth Cleaver
Have you tried escaping the '*'? It's possible your shell is eating it off
the command line.
Bingo!  Thank you.

Now the issue is, xymongrep does not seem to be .default. aware. So if I have a noconn tag on a specific host, I can xymongrep for it. But if that noconn tag on a .default. line, nothing is found even if it affects a hundred hosts :(  It is parsing enough to handle 'include' but not enough to handle '.default.'.

And what is up with its case-sensitivity?

On Solaris, a xymongrep for noprop* matches
   "NOPROPRED::+msgs" and "nopropyellow:+msgs"

But a xymongrep for client* returns nothing, while a xymongrep for CLIENT* finds a whole bunch of hosts with upper-cased tags.

On Linux (4.3.17), the matching all appears to be case-insensitive.

I'm probably going to scrap trying to use xymongrep for the task at hand. I've lived this long without it, it won't hurt me to to a little longer :)


FWIW, the man page doesn't match the source code. man offers:
xymongrep [--noextras] [--test-untagged] [--web] [--net] [--loadhostsfromxymond] TAG [TAG...]
while the source shows xymongen also handling:
   --help
   --no-down
   --version
   --hosts
Maybe these are intentionally un-doumented, but --hosts is pretty darned useful.

Also FWIW, the --loadhostsfromxymond may not be port-aware. When I try to use it on my linux box (4.3.17), the debug output indicates it is trying to talk to the "Xymon daemon" on port 1984. It does not succeed because my xymon is listening on port 1985. When I then prefix the xymongrep with a xymoncmd, it seems to refuse to honor the --loadhostsfromxymond tag and insists on loading from the hosts.cfg.
quoted from Japheth Cleaver


-- 
    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 Japheth Cleaver · Fri, 12 Feb 2016 17:39:30 -0800 ·
quoted from John Thurston
On Fri, February 12, 2016 3:36 pm, John Thurston wrote:
On 2/12/2016 1:44 PM, J.C. Cleaver wrote:

On Fri, February 12, 2016 1:47 pm, John Thurston wrote:
I'm having difficulty with xymongrep, and it isn't related to 4.3.25
because I see the same behavior on 4.3.22.

If I use the command:
   ~/server/bin/xymongrep --debug --hosts=./server/etc/hosts.cfg  *
- snip -
Have you tried escaping the '*'? It's possible your shell is eating it
off
the command line.
Bingo!  Thank you.

Now the issue is, xymongrep does not seem to be .default. aware. So if I
have a noconn tag on a specific host, I can xymongrep for it. But if
that noconn tag on a .default. line, nothing is found even if it affects
a hundred hosts :(  It is parsing enough to handle 'include' but not
enough to handle '.default.'.
Unfortunately, yes that'll be a problem. It was really more intended as a
literal replacement for grepping the hosts.cfg file that could handle
includes rather than a true hosts database dump from xymond... Even with
--loadhostsfromxymond, below, that's more about not having local access to
hosts.cfg than a post-parsed view.


One option might be to use the 'hostinfo' message type, which will pull
info from xymond in a more structured format, but you'll lose the ability
to look at textual data in hosts.cfg that xymond didn't understand, unless
you're also pulling in XMH_RAW. Kind of hairy.
quoted from John Thurston
And what is up with its case-sensitivity?

On Solaris, a xymongrep for noprop* matches
   "NOPROPRED::+msgs" and "nopropyellow:+msgs"

But a xymongrep for client* returns nothing, while a xymongrep for
CLIENT* finds a whole bunch of hosts with upper-cased tags.
That's... probably a bug :) I'll put that on the list.
quoted from John Thurston

On Linux (4.3.17), the matching all appears to be case-insensitive.

I'm probably going to scrap trying to use xymongrep for the task at
hand. I've lived this long without it, it won't hurt me to to a little
longer :)


FWIW, the man page doesn't match the source code. man offers:
xymongrep [--noextras] [--test-untagged] [--web] [--net]
[--loadhostsfromxymond] TAG [TAG...]
while the source shows xymongen also handling:
   --help
   --no-down
   --version
   --hosts
Maybe these are intentionally un-doumented, but --hosts is pretty darned
useful.

Also FWIW, the --loadhostsfromxymond may not be port-aware. When I try
to use it on my linux box (4.3.17), the debug output indicates it is
trying to talk to the "Xymon daemon" on port 1984. It does not succeed
because my xymon is listening on port 1985. When I then prefix the
xymongrep with a xymoncmd, it seems to refuse to honor the
--loadhostsfromxymond tag and insists on loading from the hosts.cfg.

--no-down should be documented, definitely. Parts of this are going to be
restructured a little bit in 4.4, since we're trying to "genericize" the
common options (like --loadhostsfromxymond) which can be used in multiple
programs.

xymongrep's historical lack of docs stems from its original intent as a
script command replacement. Since it was always running via xymonlaunch in
a pre-populated environment, it didn't have much in the way of
customization.

As a quick fix, you can pass it in via environment variables:
- ]$ XYMSRV=127.0.0.2 XYMONDPORT=9000 xymongrep --loadhostsfromxymond ssh

See http://lists.xymon.com/pipermail/xymon/2015-August/042138.html


HTH,
-jc