[Xymon] Does xymongrep work?

[J.C. Cleaver]

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.

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


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