[Xymon] xymon feature I would like to add too

[Andrey Chervonets]

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: +371 26517848
Fax: +371 66066346

On 20.03.2013 14:37, cleaver at terabithia.org 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
>