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