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 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
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
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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.'.
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.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
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
participants (2)
-
cleaver＠terabithia.org
-
john.thurston＠alaska.gov