That is how I handle it now - ext script runs every 5m checking to see if
change in database -- If change in database, write out alerts.cfg,
analysis.cfg, hosts.cfg
--
Sean Clark
Sr. Engineer, Software
ATG Network Operations & Planning Integrated Regional OSS
<http://www.twcable.com/DepartmentOverview/AdvancedTechnologyGroup/ATG/NOP/
OSS/Network.aspx>
user-2db5fbcae9a7@xymon.invalid <mailto:user-2db5fbcae9a7@xymon.invalid> devaudio
<aim://devaudio> <mailto:user-2db5fbcae9a7@xymon.invalid>
Cell: (XXX) XXX-XXXX
On 6/14/12 2:22 AM, "Vernon Everett" <user-b3f8dacb72c8@xymon.invalid> wrote:
I hate to sound greedy, but is there a way to have the best of both
worlds?
Assume a text config file that could be imported into a database table.
This table could be re-exported from the table to text file.
Changes to the table, (edited via the GUI) trigger an export to text file.
Changes detected in the text file are either automagically imported
into the table, or will need to be manually imported into the database
with an import tool. Haven't decided which is better yet, but I am
leaning towards a manual import.
Edit files, run cfg-import.
How to ensure simultanious edits are not occurring is left as an
exercise for the reader :-)
Right now, unless you use some form of version control, concurrent
edits are possible anyway, so we would be no worse off.
The advantage of this system is that the configs done using the GUI
will automatically be sanity checked. (I hope) In theory the GUI
shouldn't allow a config change that is completely wrong.
But, by importing the text file, into a database, the text file will
need to be sanity checked, probably using the same routine, and will
be rejected if it is obviously wrong too.
And it satisfies the grey-beards and the click-monkeys.
Two ways to edit. The best of both worlds.
Regards
Vernon
On 14/06/2012, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:Hi,
in another mail thread, another monitoring tool (Zenoss) was mentioned
which had the advantage of ³no hand editing of config files².
Text based config files have their ups and downs - they are infinitely
flexible and can adapt to all sorts of weird ways of defining your
setup, but it is also easier to "get it wrong" and put something in
there which doesn't work. Even happens to me occasionally.
It's the age-old debate over whether something is "powerful" or
"dangerous".
I am currently working on the next Xymon version (except I've been
swamped with for-pay work the past couple of months ... and a hefty
round of lay-offs in other departments than mine). This involves a
complete rewrite of the network testing tool, and for this rewrite I've
started using an SQLite database for storing some intermediate data used
by the network tester, instead of keeping it in a bunch of temporary
text-files.
And it has made me consider the idea of using a database for storing at
least some of the configuration - first of all the hosts.cfg
configuration of hosts, IP-adresses and network tests. This would make
some things simpler, others a bit more complex - "xymongrep", for
instance - but would also make it a lot easier to provide a GUI for
managing what hosts are being monitored.
This is not going to happen anytime soon, but since the subject was up
in the air - what do you think about it ? Is it a major problem that
Xymon has all configuration in text files ? How many of you
auto-generate the Xymon config by extracting the information from a
database already ?
Just looking for some feedback...
Regards,
Henrik
--
"While it is futile to try to eliminate risk, and questionable to try to
minimize it, it is essential that the risks taken be the right risks. "
- Peter F. Drucker
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.