host_name and service_description examples
Andreas Ericsson
ae at op5.se
Tue Jun 14 19:23:10 CEST 2005
François Laupretre wrote:
>>I don't want to spend too much time trying to optimize the CGI speed,
>>as I am very much wanting them to disappear and be replaced by a new
>>interface soon. A DB backend makes the most sense for this, and
>>projects like nagios-db are a good start.
>
>
> I don't understand why the replacement of the CGIs by a new PHP UI seems to
> imply the replacement of the current transmission mechanism by a DB
> back-end.
It doesn't. Writing database enabled PHP-apps are so trivial that it's
sort of assumed that they will be using a database sooner or later.
Besides, script kiddies are the worst ever when it comes to performance
and will most likely botch any implementation technique unless 90% of
the logic is left out to seriously competent programmers (like the folks
at MySQL or PostgreSQL for instance).
> Does it mean that the new UI will directly access the DB ?
Yes.
> Why
> don't we define an intermediate layer and an API for the UI to access object
> and status data ?
Because that's what a database is. An intermediate, caching layer with a
structured query language to pull data out of it. Without the query
language any other implementation will be outperformed.
> This way, the user could choose between different
> communication channels. The DB would be one of the available channels, the
> core would feed any channels you choose to configure and the channel from
> which the UI would take its data is also a configuration choice.
>
This is actually the entire idea with the eventbroker modules. The core
feeds the modules through shared memory (the fastest possible
access-method) and the modules put it somewhere where the GUI can access
it nicely. Like a database, or binary files, or XML files (just
kidding). A module could even auto-generate HTML from the input it's
given (tac.cgi could easily be replaced by such an autogenerated page).
> The central point here is performance. For a configuration with several
> thousands of hosts and services, how much improvement do you expect from a
> DB back-end ? If the UI is not at least 20 times faster (on the same
> hardware), we still have the same problem as now (with plain text files).
>
The main point of having a db backend is so that queries can be issued
cleverly. Using a shared memory mechanism might prove equally fast
(provided I get my thumb out and hack in the new hash-algorithm) but
much less trivial. A db also has the great benefit of relieving Nagios
of the complex memory management issues that would have to be
implemented to maintain status-data in-core. Garbagemanagers are far
from trivial and leaves a fairly significant foot-print in the code.
Anyways, if you're monitoring more than 1000 or so hosts and 5000 or so
services, listing all of them as fast as possible isn't the issue, but
rather selecting those which are in one state or another. Without a
database you will have to resort to some fairly black magic, traverse
the entire list anyways or invent some form of query protocol to get
just the data you need and not have to parse the entire thing.
> I proposed an idea, which is totally compatible with a new UI. This way, I
> am sure to improve the read speed by a factor of 30 at least I am currently
> rewriting it in order to remove the alignment problems inherent to the
> 'generic object' approach. It also removes much CPU time from the core
> (writing status data is about 15 times faster).
With a database backend the status data will be written continually, so
there won't be any need for writing status.dat anymore. I'm fairly sure
that particular functionality will be moved to a module sooner or later.
> If you think that this work
> is definitely useless, please let me know and I will forget it.
>
I believe one major points for Ethan to want the GUI rewritten is so
that he can focus on the core and let some GUI-gurus take over design
and such other tedious tasks that real programmers don't have a suitably
aligned mind for. Most of the community feels that a database backend
would immensely improve the GUI's performance and give little or no
thought to us poor bastards who actually enjoy this type of intellectual
masturbation.
I, however, am thrilled to see such voodoo put to work. :)
> Regards
>
>
>
> ------------------------------------------------------------------------
>
> Ce message et ses pièces jointes (le "message") est destiné à l'usage
> exclusif de son destinataire.
> Si vous recevez ce message par erreur, merci d'en aviser immédiatement
> l'expéditeur et de le détruire ensuite. Le présent message pouvant
> être altéré à notre insu, CALYON Corporate and Investment Bank
> ne peut pas être engagé par son contenu. Tous droits réservés.
>
> This message and/or any attachments (the "message") is intended for
> the sole use of its addressee.
> If you are not the addressee, please immediately notify the sender and
> then destroy the message. As this message and/or any attachments may
> have been altered without our knowledge, its content is not legally
> binding on CALYON Corporate and Investment Bank. All rights reserved.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Lead Developer
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
More information about the Developers
mailing list