[Nagios-db-checkins] nagios-db HISTORY,1.1,1.2 README,1.3,1.4 TODO,1.1,1.2
Status: Beta
Brought to you by:
bench23
Menu
▾
▴
[Nagios-db-checkins] nagios-db HISTORY,1.1,1.2 README,1.3,1.4 TODO,1.1,1.2
|
From: Bench <be...@us...> - 2005-11-25 20:03:32
|
Update of /cvsroot/nagios-db/nagios-db In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31521 Modified Files: HISTORY README TODO Log Message: cleaner docs for file release Index: README =================================================================== RCS file: /cvsroot/nagios-db/nagios-db/README,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- README 5 Feb 2005 00:33:54 -0000 1.3 +++ README 25 Nov 2005 20:03:21 -0000 1.4 @@ -1,18 +1,18 @@ -Nagios-DB is, not surprisingly, designed to add database support to -nagios 2. Database support is important because Nagios' flat file -storage system doesn't make for acceptable UI performance as the -environment becomes large. Also, keeping data in a database allows -for more complex historical reports to quickly and easily be -generated. These have been the prime motiviations to date, and -hence, these pain points are the ones that have been addressed. +Nagios-DB is designed to add database support to nagios 2. Database +support is important because Nagios' flat file storage system doesn't +make for acceptable UI performance as the environment becomes large. +Also, keeping data in a database allows for more complex historical +reports to quickly and easily be generated. These have been the prime +motiviations to date, and hence, these pain points are the ones that +have been addressed. Pretty much every other cool feature Nagios offers has been ignored. -Effort has been made to make sure those features *could* be -incorporated into this framework, but that's about it. I appreciate -that those features are useful elsewhere, but there haven't been -important yet. +Effort has been made to make sure those features *could* be incorporated +into this framework, but that's about it. I appreciate that those +features are useful elsewhere, but there haven't been important to me +yet. -It would be totally sweet if somebody who cares about those ignored +It would be totally sweet if somebody who cares about those ignored nifty features came around and added support for them. (hint hint) Now, as for how it works....... @@ -21,76 +21,76 @@ OVERVIEW ======== -Nagios 2 adds a callback system called the Nagios Event Broker (NEB). -You write a shared library which registeres for various callbacks, and -then, while Nagios processes data, (surprise!) your library gets called -when nagios passes through those points. Because of the kind of data -Nagios-DB uses, it only bothers to register for host and service status -callbacks, as well as a callback after the configuration has been parsed -out. There are many other callbacks. Titus Anderson has written a -quality example NEB module that shows what's available. I've placed it in -neb/sampler/, and you can get it online at -http://www.louisville.edu/~tjande01/nagios. Eventually we might even get -Ethan to document this stuff. :) +Nagios 2 introduces a callback system called the Nagios Event Broker +(NEB). You write a shared library which registeres for various +callbacks, and then, as Nagios processes data, (surprise!) your library +gets called when nagios passes through those callback points. Because of +the kind of data Nagios-DB uses, it only bothers to register for host +and service status callbacks, as well as a callback after the +configuration has been parsed out. There are many other available +callbacks. Titus Anderson has written a quality example NEB module that +shows what's available. I've placed it in neb/sampler/, and you can get +it online at http://www.louisville.edu/~tjande01/nagios. Eventually we +might even get Ethan to document this stuff. :) -Anyway, NEB modules can do whatever you want them to - they're simply -shared libraries. The one in neb/postgres/ connects to a Postgres database -and calls some stored procedures. Likewise, neb/mysql/ houses a module -that does the same thing, but dumps its data into mysql. +NEB modules can do whatever you want them to - they're simply shared +libraries. The one in neb/postgres/ connects to a Postgres database and +calls some stored procedures. Likewise, neb/mysql/ houses a module that +does much the same thing, but uses mySQL instead of PostgreSQL. That's it, as far as Nagios itself is concerned. Nagios-DB is entirely supplemental. Data still gets written to Nagios' native flat files, but -with the UI included with Nagios-DB ignores it. +with the UI included with Nagios-DB ignores it. You can still use the +native Nagios UI if you wish. Speaking of the UI... In stock Nagios, the UI is a bunch of CGI programs that read Nagios' flat files. With this system, the UI reads data from the database. A rough UI hacked out in PHP in included, but it is easily -replaced and/or supplimented if somebody feels the itch. (In fact, Matthew -Kent is currently working on a much improved, template-based PHP system.) -Anyway, this new UI architecture is better for a number of reasons. First, -each web page load doesn't have parse Nagios' flat files on every run. -With thousands of objects, that is a HUGE win. Second, the web pages do -not need access to Nagios' flat files at all. That means the filesystems -on the webserver and Nagios can be independant. Third, the interface -doesn't have to be written in C (not that they had to be written in C -before, but it sure made things easier). +replaced and/or supplimented if somebody feels the itch. This new UI +architecture is better for a number of reasons. First, each web page +load doesn't have parse Nagios' flat files on every run. With thousands +of objects, that is a HUGE win. Second, the web pages do not need access +to Nagios' flat files at all. That means the filesystems on the +webserver and Nagios can be independant. Third, the interface doesn't +have to be written in C (not that they had to be written in C before, +but it sure made things easier). POSTGRES DATABASE DETAILS ========================= -In the postgres implementation, data is modified with stored proceedures. -For instance, there is one proceedure for service status messages and -another for host status messages. The thinking here was that the logic -for whether to insert a row or update a row isn't trivial, so putting it -in a stored proceedure keeps the server from recomputing the same plan -again and again. You get all the other benifits of stored proceedures, -too. Finally, it keeps the NEB module simple and free of raw SQL, which -is always good. +In the postgres implementation, data is modified with stored +proceedures. For instance, there is one proceedure for service status +messages and another for host status messages. The thinking here was +that the logic for whether to insert a row or update a row isn't +trivial, so putting it in a stored proceedure keeps the server from +recomputing the same plan again and again. You get all the other +benifits of stored proceedures, too. Finally, it keeps the NEB module +simple and free of raw SQL, which is always good. -In addition, because the NEB module is running inside the nagios -process, it has easy access to nagios' configuration after startup but -before steady state. Currently, the NEB module reads config data such as -hostgroups and monitoring features, and copies that information into the -database. This is very handy when generating reports. (Actually, because -the UI only has access to the database, and not neccessarily Nagios' -configuration files, putting such information into the database is the +Beecause the NEB module is running inside the nagios process, it has +easy access to nagios' configuration after startup but before steady +state. Currently, the NEB module reads config data such as hostgroups +and monitoring features, and copies that information into the database. +This is very handy when generating reports. (Actually, because the UI +only has access to the database, and not neccessarily Nagios' +configuration files, putting such information into the database is the only way to use it for reporting.) The table schema is simple. It is described in schema.sql. It is currently designed to host status information and hostgroup config, and not much else. It's easily expanded if more data becomes required. -In large environments (and honestly, are you going to bother with this +In large environments (and honestly, are you going to bother with this unless you have a large environment?) there will be a lot of updates. -It would be a very good idea to vacuum the database regularly. +It would be a very good idea to vacuum the dateabase regularly. -Finaly, about the materialized views. A database may offer powerful +Finaly, about the materialized views. A database may offer powerful information retrieval abilities, but parsing through the entire database -for every query is not going to offer much speed improvement over Nagios' -default flat files. Therefore, the schema makes liberal use of -materialized views. I am using materialized views as excellently described -at +for every query is not going to offer much speed improvement over +Nagios' default flat files. Therefore, the schema makes liberal use of +materialized views. I am using materialized views as excellently +described at http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html. Currently, the views are snapshot views, and I recommend updating them as often as your hardware allows. You can either do so via running @@ -98,25 +98,25 @@ consider splitting update_views.sql into multiple segments to take advantage of your hardware. -Let me explicitly restate this, because it's important: because the UI -reads from snapshot materialized views, the data read will NOT be up to -date. Depending on how often you refresh the views, it may or may not be -close to realtime. While that is unfortunate, it is still acceptable (to -me) to see data a minute or two old. On the other hand, it is NOT -acceptable to wait 30 seconds to bring up a page. If you'd rather wait -and make sure that you get the most recent data, even if it takes a long -time to bring it together, you can always make the UI read from the +Let me restate this, because it's important: because the UI reads from +snapshot materialized views, the data read will NOT be up to date. +Depending on how often you refresh the views, it may or may not be close +to realtime. While that is unfortunate, it is still acceptable (to me) +to see data a minute or two old. On the other hand, it is NOT acceptable +to wait 30 seconds to bring up a page. If you'd rather wait and make +sure that you get the most recent data, even if it takes a long time to +bring it together, you can always make the UI read from the non-materialized version of the view. MYSQL DATABASE DETAILS ====================== -A MySQL 4.1 module has been added and will be supported by Matthew -Kent. Although it implements the same schema as the postgres module -there are many differences in how it's written. Most of the differences -are not improvements but making up for some features which MySQL lacks -(like stored procedures) that make writting C for it more difficult. +A MySQL 4.1 module has been added and supported by Matthew Kent. +Although it implements the same schema as the postgres module there are +many differences in how it's written. Most of the differences are not +improvements but making up for some features which MySQL lacks (like +stored procedures) that make writting C for it more difficult. The module also includes some simple caching to take advantage of bulk inserts and updates. Queries are collected in memory and fed to the @@ -133,5 +133,5 @@ which database you choose to store your data in. Modifying ui/config.php is all you need to do to switch between them. Indeed, if you were insane, you could have Nagios load both NEB modules, save -data to both databases at the same time, and alter ui/config.php at +data to both databases at the same time, and alter ui/config.php at any moment to pull data out of the either database. Index: TODO =================================================================== RCS file: /cvsroot/nagios-db/nagios-db/TODO,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- TODO 5 Feb 2005 01:34:55 -0000 1.1 +++ TODO 25 Nov 2005 20:03:21 -0000 1.2 @@ -3,8 +3,7 @@ gui ---- - both - - redesign the interface. + - redesign the interface and make it less ugly. - look at importing code from nagios-php project (GPL) for all the features core nagios cgis support in terms of commands. @@ -18,9 +17,6 @@ moving them off into a seperate file wouldn't be a bad idea, since some of them are reallly long - postgres - - - neb ---- @@ -35,5 +31,4 @@ bookmarking avail reports and such, if they add a new hostgroup the ids will shift breaking the links. needs a configured = true/false to validate them at startup. do this for servicegroups as well. - - passing database info as args Index: HISTORY =================================================================== RCS file: /cvsroot/nagios-db/nagios-db/HISTORY,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- HISTORY 5 Feb 2005 00:48:50 -0000 1.1 +++ HISTORY 25 Nov 2005 20:03:21 -0000 1.2 @@ -1,3 +1,7 @@ +0.92 +- Fundamental change in the postgres NEB. See neb/postgres for more. +- Specify arguements for postgres NEB in nagios.cfg + 0.91 - Added support for MySQL - Added database abstraction in UI |
