I know this approach to use virtual hosts definitions, but this mean
a) replace sending tests information as of behalf of virtual host
instead of from real host.
This mean we loose mapping to real host. It is not suitable for me, I
need this map, because many related events occure at that host (for
example CPU load or disk space usage)
b) to make this working in normal way we should start client process
with hostname parameter for each target.
or we should customize our scripts to use target object name (db name
for instance) instead of real machine name.
It is not big deal, but really is not the best approach.
It would be much more better to have standard feature of XyMon that
allow to have another level for grouping events.
Best regards,
Andrey Chervonets
SIA CoMinder
http://www.cominder.eu/
Mobile: +XXX XXXXXXXX
Fax: +XXX XXXXXXXX
On 20.03.2013 14:37, user-87556346d4af@xymon.invalid wrote:
I vote for the feature discussed. It can be very useful.
Another thing I would like to offer is to add new dimension: target object
and some king of screen display with grouping by target objects of user
defined type or just per target level.
......
Another option, depending on how complex your page generation already is,
s to create separate host entries for each service. I'm using pseudo DNS
names to track "instances" of apps or dbs as distinct servers. I can then
report status results (and store client data) for each service
independently.
To wit - our config generator creates a separate page for each DB/App
server, with groupings below it for each instance on that box. For
snapshoting purposes, I have a script listening on the stachg channel for
anything relating to app or db hosts that sends a spurious status flap for
a "tied" test for each related instance/node on that box to ensure that
clientdata gets recorded for each of them.
With a small patch to allow for generic/unknown clientOS types, you can
even got logfetch and client-local.cfg working properly for per-instance
error logs and such.
HTH,
-jc