Xymon Mailing List Archive search

xymon feature I would like to add

4 messages in this thread

list Henrik Størner · Tue, 19 Mar 2013 10:10:09 +0100 ·
Hi,


On 14-03-2013 19:25, Tux Toes wrote:
I did float my feature suggestion on the regular mailing list - but I
think I was way to subtle.  Here is the gmane archive link - it does
explain what I want to do.

http://permalink.gmane.org/gmane.comp.monitoring.hobbit/32063
thanks for your mail. Good ideas for enhancements are always welcome, and it certainly makes sense to be able to split the disk-status reports the way you propose.

I was planning this feature, in a more general fashion. It can equally well be used for other of the combined status-reports, e.g. "procs" would be an obvious candidate for splitting up this way. So it is something that I plan on implementing via an enhancement to the analysis.cfg file. Right now my plan is to add a STATUS definition at a level above the current HOST/PAGE/GROUP ... definitions, something like:

STATUS=disk_sys
    HOST=*
      DISK / 70 90
      DISK /var 80 95

STATUS=disk_db
    HOST=%^oraserv
      DISK %^/oradata 95 98
      DISK %rollback 60 90
    HOST=%mysql
      DISK /var/lib/mysql 80 90

so you can define the criteria that trigger a "disk_db" status by selecting on hostnames or any of the other criteria, and then defining the tests that go into the "disk_db" status.

This would also allow you to combine tests that are now separate, e.g. all tests regarding a database instance:

STATUS=dbw1
     HOST=*
        DISK ^/oradata/dbw1 80 90
        PROC ora_dbw1_wssu1


I expect this to be ready for the 5.0 release, since this release involves a lot of enhancements to the xymond_client / analysis.cfg code.

I have cross-posted this mail to the normal Xymon mailing list, since I expect there may be others who are interested in this. I hope you don't mind.


Regards,
Henrik
list Larry Barber · Tue, 19 Mar 2013 14:00:54 -0500 ·
That would extremely helpful. Any idea when 5.0 will be released?

Thanks,
Larry Barber
quoted from Henrik Størner

On Tue, Mar 19, 2013 at 4:10 AM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:
Hi,


On 14-03-2013 19:25, Tux Toes wrote:
I did float my feature suggestion on the regular mailing list - but I
think I was way to subtle.  Here is the gmane archive link - it does
explain what I want to do.

http://permalink.gmane.org/**gmane.comp.monitoring.hobbit/**32063<http://permalink.gmane.org/gmane.comp.monitoring.hobbit/32063>;
quoted from Henrik Størner
thanks for your mail. Good ideas for enhancements are always welcome, and
it certainly makes sense to be able to split the disk-status reports the
way you propose.

I was planning this feature, in a more general fashion. It can equally
well be used for other of the combined status-reports, e.g. "procs" would
be an obvious candidate for splitting up this way. So it is something that
I plan on implementing via an enhancement to the analysis.cfg file. Right
now my plan is to add a STATUS definition at a level above the current
HOST/PAGE/GROUP ... definitions, something like:

STATUS=disk_sys
   HOST=*
     DISK / 70 90
     DISK /var 80 95

STATUS=disk_db
   HOST=%^oraserv
     DISK %^/oradata 95 98
     DISK %rollback 60 90
   HOST=%mysql
     DISK /var/lib/mysql 80 90

so you can define the criteria that trigger a "disk_db" status by
selecting on hostnames or any of the other criteria, and then defining the
tests that go into the "disk_db" status.

This would also allow you to combine tests that are now separate, e.g. all
tests regarding a database instance:

STATUS=dbw1
    HOST=*
       DISK ^/oradata/dbw1 80 90
       PROC ora_dbw1_wssu1


I expect this to be ready for the 5.0 release, since this release involves
a lot of enhancements to the xymond_client / analysis.cfg code.

I have cross-posted this mail to the normal Xymon mailing list, since I
expect there may be others who are interested in this. I hope you don't
mind.


Regards,
Henrik

______________________________**

Xymon at xymon.com<
list Kevin Hanrahan · Wed, 20 Mar 2013 22:49:46 -0400 ·
When do you anticipate the 5.0 release?
quoted from Henrik Størner


On Mar 19, 2013, at 5:10 AM, "Henrik Størner" <user-ce4a2c883f75@xymon.invalid> wrote:
Hi,


On 14-03-2013 19:25, Tux Toes wrote:
I did float my feature suggestion on the regular mailing list - but I
think I was way to subtle.  Here is the gmane archive link - it does
explain what I want to do.

http://permalink.gmane.org/gmane.comp.monitoring.hobbit/32063
thanks for your mail. Good ideas for enhancements are always welcome, and it certainly makes sense to be able to split the disk-status reports the way you propose.

I was planning this feature, in a more general fashion. It can equally well be used for other of the combined status-reports, e.g. "procs" would be an obvious candidate for splitting up this way. So it is something that I plan on implementing via an enhancement to the analysis.cfg file. Right now my plan is to add a STATUS definition at a level above the current HOST/PAGE/GROUP ... definitions, something like:

STATUS=disk_sys
  HOST=*
    DISK / 70 90
    DISK /var 80 95

STATUS=disk_db
  HOST=%^oraserv
    DISK %^/oradata 95 98
    DISK %rollback 60 90
  HOST=%mysql
    DISK /var/lib/mysql 80 90

so you can define the criteria that trigger a "disk_db" status by selecting on hostnames or any of the other criteria, and then defining the tests that go into the "disk_db" status.

This would also allow you to combine tests that are now separate, e.g. all tests regarding a database instance:

STATUS=dbw1
   HOST=*
      DISK ^/oradata/dbw1 80 90
      PROC ora_dbw1_wssu1


I expect this to be ready for the 5.0 release, since this release involves a lot of enhancements to the xymond_client / analysis.cfg code.

I have cross-posted this mail to the normal Xymon mailing list, since I expect there may be others who are interested in this. I hope you don't mind.


Regards,
Henrik

list Henrik Størner · Thu, 21 Mar 2013 09:48:10 +0100 ·
On Wed, 20 Mar 2013 22:49:46 -0400, Kevin Hanrahan
<user-80c5d6fed79a@xymon.invalid> wrote:
When do you anticipate the 5.0 release?
When it's done.

Seriously, I have stopped making predictions on release-dates. Real life
activities have a nasty habit of interfering with the amount of time I have
for coding.


Regards,
Henrik