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