NDOUtils 1.4b1 Released

[Marlo Bell]

Hey Andreas,

I appreciate the feedback on my suggestions, but I was a little confused by your objection to point number two. If point number 1 is true, some form of point number 2 must also be true. Currently Hosts and Services are linked by name in the objects table objects.name1=Host Name, objects.name2=Service Desc. If these go away (which we both agree they should), either the services table then needs to hold a hostname field with hostname(s) and/or a regex for a group of hosts. While it is programmatically possible to then explode this, it doesn’t make sense in a relational database. To truly reflect what nagios is capable of doing with hosts and service relationships (i.e. “*”,”Router*”,”Router1,Router2”)  and maintain some degree of normality an association table is needed. I have attached a quick diagram that I drew up of how this would look.

 
In looking at this a Service isn’t an object, a Host-Service is an object as well as a Host. By making it this way a Host can have many Services and a Service can exist on many hosts while still maintaining an optimized DB schema. It is a little bit of thought process change from using regex, but if the database is eventually going to become the authority on object configuration as well as logging, this is seems more appropriate.

I welcome anyone’s input on this to fix/improve/change/agree with my views.

Marlo

_____________________________________________
From: Andreas Ericsson [mailto:ae at op5.se] 
Sent: Tuesday, January 09, 2007 3:02 AM
To: Nagios Developers List <nagios-devel at lists.sourceforge.net>
Cc: <nagios at nagios.org>
Subject: Re: [Nagios-devel] NDOUtils 1.4b1 Released

I've only commented on the parts where I know what I'm talking about. I 
haven't delved into the ndo database in detail.

Marlo Bell wrote:
> 
> 1. objects.name1 and objects.name2 shouldn't exist. The names of objects should
> live in their respective tables. Hosts should have a hostname and a alias field.
> Services should have a service_description field. Hostgroups should have a
> hostgroup_name and a hostgroup_alias field. etc. etc. etc. I believe this to be
> the case because they are unique to each object and cannot be generified-the
> result is a bunch of NULLs in the objects table. This also makes joining objects
> together easier/possible. In the current NDO database I couldn't use a join to
> show me all the services in a particular servicegroup. This could possibly be
> done with a subquery, but that seems excessive for a seemingly simple query.
> 

Agree.

> 2. Host and Services should not be linked by name. At very least the id of the
> host and service object should be linked. But to truly model the Nagios works,
> it should be a many-to-many relationship with an association table.

Not really. Internally, Nagios explodes the

define service{
	service_description   foobar
	host_name       *
}

so that each host gets its own service "foobar". It's programmatically 
much easier to keep each service a separate object in the database as 
well, so it only has to have a host_id entry that links to the proper 
host definition in the database. This also allows for storing the 
current state of each host/service in the ndo database in a very simple 
way. Hacking up the PHP gui could then kick off very quickly and would, 
in practice, only have to use two tables to get all the tools viewing 
current status up and running. The reporting tools would still have to 
use more data than that.

> 
> 4. The acknowledgements and comments should be closely linked.
> Since an acknowledgement requires a comment, Why keep them separate?
> Just have the acknowledgements table link to the comment_id of the acknowledgement comment.
> 

Agreed.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel

----------------------------------------------------------------------
NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Host_Service_Objects.png
Type: image/png
Size: 19513 bytes
Desc: Portable Network Graphics Format
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20070110/fce09ca9/attachment.png>
-------------- next part --------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel