Usefulness for xymonconfigsync?
I've seen this link:
http://sourceforge.net/projects/xymonconfigsync/
Could some of you please share what are some of the ways in which you are using this?
Thank you, and I am sorry if this has been answered before, I've not found it. I am trying to establish an active/standby setup and am running into issues which I hope this might help with.
.vadim
Hello,
I've seen this link:
http://sourceforge.net/projects/xymonconfigsync/
Could some of you please share what are some of the ways in which you are using this?
That module is used quite frequently over here. That is not really surprising, as I am the author of that perl module.
The module is written to be able to synchronize the Xymon configuration file bb-hosts with a configuration database. That database contains the devices to be monitored, some comment and above all the administrators of each device. Those administrators will receive an e-mail if there is a yellow or red condition for a test of "their" server. The database does *not* contain information about the tests to be performed. When regenerating the bb-hosts configuration file, information is taken as much as possible from the configuration database, and the rest of the information, especially the network tests, is taken from the old version of the bb-hosts configuration file.
As a result, a server becomes monitored (although with only one test "conn") as soon as it is defined in the configuration database, en it disappears from Xymon once it is removed from the database. Thus the administrators have a bit of control of what is being monitored, and who receives the alerts, as they are allowed to modify the configuration database.
To illustrate the benefits of this approach: bb-hosts is divided into about a dozen subfiles, glued together with "include" directives. One of them contains for each administrator a list of devices (s)he administers. There is a notes-file for each monitored device, which contains a link to that entry in the configuration database. In 2009, the configuration synchronization has (re)written more than 2700 times one of those configuration files.
A way of using the xymonconfigsync module is described in the POD within the module.
Regards, Wim Nelis.
The NLR disclaimer (http://www.nlr.nl/emaildisclaimer) is valid for NLR e-mail messages.
Hello,
I've seen this link:
http://sourceforge.net/projects/xymonconfigsync/
Could some of you please share what are some of the ways in which you are using this?
That module is used quite frequently over here. That is not really surprising, as I am the author of that perl module.
I wish Xymon had more stuff like this.
The module is written to be able to synchronize the Xymon configuration file bb-hosts with a configuration database. That database contains the devices to be monitored, some comment and above all the administrators of each device. Those administrators will receive an e-mail if there is a yellow or red condition for a test of "their" server. The database does *not* contain information about the tests to be performed. When regenerating the bb-hosts configuration file, information is taken as much as possible from the configuration database, and the rest of the information, especially the network tests, is taken from the old version of the bb-hosts configuration file.
How is the database created? Do you have a db create script? (sorry, haven't read the POD yet).
As a result, a server becomes monitored (although with only one test "conn") as soon as it is defined in the configuration database, en it disappears from Xymon once it is removed from the database. Thus the administrators have a bit of control of what is being monitored, and who receives the alerts, as they are allowed to modify the configuration database.
Makes sense, and are your admins delegated depending on their location/discipline and/or responsibilities?
To illustrate the benefits of this approach: bb-hosts is divided into about a dozen subfiles, glued together with "include" directives. One of them contains for each administrator a list of devices (s)he administers. There is a notes-file for each monitored device, which contains a link to that entry in the configuration database. In 2009, the configuration synchronization has (re)written more than 2700 times one of those configuration files.
My present bb-hosts is made up entirely of page, subpage, group-compress, title and dispinclude directives.
Since my bb-hosts itself does not contain any hosts, I've been toying with the idea of modifying menu/menu_items.js allowing me one entry for each dispinclude file/directory (using Chris Naude's bb-hosts.cgi for each dispinclude flat-files). The problem with that idea is that it becomes messy looking, and does not provide me with neither the ability to "hide" each file from other admins, nor allow me any sort of access control to those files; unless of course I setup some sort of ACL in the directories they are contained in.
A way of using the xymonconfigsync module is described in the POD within the module.
OK, I'll read the FM ;-) But any other help, pointers/ideas would be greatly appreciated.
Regards, Wim Nelis.
Thank you Wim,
.vadim
I've seen this link:
http://sourceforge.net/projects/xymonconfigsync/
Could some of you please share what are some of the ways in which you are using this?
[ ... ]
The module is written to be able to synchronize the Xymon configuration file bb-hosts with a configuration database. That database contains the devices to be monitored, some comment and above all the administrators of each device. Those administrators will receive an e-mail if there is a yellow or red condition for a test of "their" server. The database does *not* contain information about the tests to be performed. When regenerating the bb-hosts configuration file, information is taken as much as possible from the configuration database, and the rest of the information, especially the network tests, is taken from the old version of the bb-hosts configuration file.
How is the database created? Do you have a db create script? (sorry, haven't read the POD yet).
There are (PHP) scripts to build and maintain the database, but they are not useful to others. The database evolved from an IP address management tool in 1994 to a MySQL database with user authentication info, device info and license info. This database is very specific for this company. I guess that in most companies the same will be true. The xymonconfigsync module therefore deals only with the common part, the Xymon configuration files.
As a result, a server becomes monitored (although with only one test "conn") as soon as it is defined in the configuration database, en it disappears from Xymon once it is removed from the database. Thus the administrators have a bit of control of what is being monitored, and who receives the alerts, as they are allowed to modify the configuration database.
Makes sense, and are your admins delegated depending on their location/discipline and/or responsibilities?
I don't understand your question. We register per device and per function the administrator(s). This information is used to generate the alert configuration. Basically there is one page for each administrator, and an administrator get an alert if something is not green on his/her page. The administrators are authorized to change this information in the configuration database.
[...]
My present bb-hosts is made up entirely of page, subpage, group-compress, title and dispinclude directives.
Since my bb-hosts itself does not contain any hosts, I've been toying with the idea of modifying menu/menu_items.js allowing me one entry for each dispinclude file/directory (using Chris Naude's bb-hosts.cgi for each dispinclude flat-files). The problem with that idea is that it becomes messy looking, and does not provide me with neither the ability to "hide" each file from other admins, nor allow me any sort of access control to those files; unless of course I setup some sort of ACL in the directories they are contained in.
If the info is taken from a database, you can use the access control mechanisms of the database to achieve that goal. Moreover, the structure and layout of the Xymon pages will become independent of the (changing) access rules.
Regards, Wim Nelis.
The NLR disclaimer (http://www.nlr.nl/emaildisclaimer) is valid for NLR e-mail messages.
On Tuesday, 12 January 2010 15:47:40 W.J.M. Nelis wrote:
Hello,
I've seen this link:
http://sourceforge.net/projects/xymonconfigsync/
Could some of you please share what are some of the ways in which you are using this?
That module is used quite frequently over here. That is not really surprising, as I am the author of that perl module.
[...]
A way of using the xymonconfigsync module is described in the POD within the module.
Is there a reason we shouldn't be working on a consistent set of perl modules for Xymon, which is maintained upstream?
I started on a simple Xymon::Client (attached) module, to start looking at replacing what was being duplicated across a number of different perl extension scripts. The next step (to be able to have thresholds in hobbit-clients.cfg) I wanted to look at required parsing bb-hosts to represent the page layout (and other criteria for threshold matching), at which point I got stuck.
However, this would then also be useful to work on a new web interface (say in Catalyst).
Regards, Buchan
participants (3)
-
bgmilne＠staff.telkomsa.net
-
nelis＠nlr.nl
-
wiskbroom＠hotmail.com