xymon feature I would like to add too
list Andrey Chervonets
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. For example, on some hosts we monitor databases (there may be several per host), on some application server instances. Now I have implemented loop at client side to test and show status for each database instance per host and calculate overall status for metric (dbup, dbpga, etc.) Problems with this are: a) when we have both databases and application server on same host - screen width is naturally to short to display all metrics (I use Opera browser and it just compact to display all the screen, so this a bit resolve the problem for me, but formatting is not so good). b) we can't see statistics and history per target (database/application server instance) , so if I need to check problems of the exact instance I have to check all events for the metric, check details for each event and filter out only required in my memory. So my offer is to add onether one dimension target object (that can be of user defined type, by default all is grouped by target type=host) I know it is not very simple to implement, but may be you will find this may be useful. Best regards, Andrey Chervonets SIA CoMinder http://www.cominder.eu/ Mobile: +XXX XXXXXXXX Fax: +XXX XXXXXXXX
list Japheth Cleaver
▸
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. For example, on some hosts we monitor databases (there may be several per host), on some application server instances. Now I have implemented loop at client side to test and show status for each database instance per host and calculate overall status for metric (dbup, dbpga, etc.) Problems with this are: a) when we have both databases and application server on same host - screen width is naturally to short to display all metrics (I use Opera browser and it just compact to display all the screen, so this a bit resolve the problem for me, but formatting is not so good). b) we can't see statistics and history per target (database/application server instance) , so if I need to check problems of the exact instance I have to check all events for the metric, check details for each event and filter out only required in my memory. So my offer is to add onether one dimension target object (that can be of user defined type, by default all is grouped by target type=host) I know it is not very simple to implement, but may be you will find this may be useful.
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
list 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: +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