I have a hobbit setup where I have in my bb-hosts:
1.2.3.4 virtual.mydomain.com # CLIENT:realhostname.mydomain.com ... 1.2.3.5 realhostname.mydomain.com # conn ssh disk cpu
The problem I am experiencing is that the client data columns are displayed for "realhostname.mydomain.com", but they are not displayed for "virtual.mydomain.com".
---snip - bb-hosts man page --- CLIENT:hostname Defines an alias for a host, which will be used when identifying status messages. This is typically used to accomodate a local client that sends in status reports with a different hostname, e.g. if you use hostnames with domains in your Hobbit configuration, but the client is a silly Window box that does not include the hostname. Or vice versa. Whatever the reason, this can be used to match status reports with the hosts you define in your bb-hosts file. It causes incoming status reports with the specified hostname to be filed using the hostname defined in bb-hosts.
From reading this, the behavior I expect is that you can alias a host to another hostname, and you should get all the same data as the other hostname...is that wrong?
P.S. I also tried using "NAME:hostname", but that had the effect of changing realhostname.mydomain.com to virtual.mydomain.com on other pages, which is not what I want.
-Charles
On Tue, May 29, 2007 at 11:52:05AM -0700, Charles Jones wrote:
I have a hobbit setup where I have in my bb-hosts:
1.2.3.4 virtual.mydomain.com # CLIENT:realhostname.mydomain.com ... 1.2.3.5 realhostname.mydomain.com # conn ssh disk cpu
You cannot do that.
Hobbit's designed to put host status data on a single host entry, not multiple ones. The CLIENT tag is used only if the hostname used by the client isn't in the bb-hosts file (e.g. you have "foo.bar.com" in bb-hosts, but the client reports as "foo" without the domain).
Personally, I'd also hate getting 10 disk alerts because of one box running out of space. So client data are reported for the physical box, and virtual hosts only report the services they provide (typically, some sort of network service).
Regards, Henrik
participants (2)
-
henrik@hswn.dk
-
jonescr@cisco.com