It all depends how you structured the dependencies. If every ssh service check relies on a ping check, that will raise the number. If you also created cross-host service dependencies, the number could snowball quickly. I find that using the parent/child host relationship is better than creating a bunch of cross host ping service dependencies while providing more or less the same function. If you posted a sample of your config I could drill down a better answer for you.difasico wrote: Can anyone explain why the configuration generated 441 service dependencies? I think the calculation in this case is (nº of hosts)^(nº of service groups) -> 21^2 = 441
This doc may be of interest to you:
http://nagios.sourceforge.net/docs/3_0/ ... ncies.html
No more than any other check, unless the dependency chain goes really deep.Does this value has any impact in the performance of the server?
From the above document:Also, will the service dependencies prevent dependent service checks or just the notifications of these?
How Service Dependencies Are Tested
Before Nagios executes a service check or sends notifications out for a service, it will check to see if the service has any dependencies. If it doesn't have any dependencies, the check is executed or the notification is sent out as it normally would be. If the service does have one or more dependencies, Nagios will check each dependency entry as follows:
1. Nagios gets the current status* of the service that is being depended upon.
2. Nagios compares the current status of the service that is being depended upon against either the execution or notification failure options in the dependency definition (whichever one is relevant at the time).
3. If the current status of the service that is being depended upon matches one of the failure options, the dependency is said to have failed and Nagios will break out of the dependency check loop.
4. If the current state of the service that is being depended upon does not match any of the failure options for the dependency entry, the dependency is said to have passed and Nagios will go on and check the next dependency entry.
This cycle continues until either all dependencies for the service have been checked or until one dependency check fails.
Note Note: *One important thing to note is that by default, Nagios will use the most current hard state of the service(s) that is/are being depended upon when it does the dependeny checks. If you want Nagios to use the most current state of the services (regardless of whether its a soft or hard state), enable the soft_state_dependencies option.
Execution Dependencies
Execution dependencies are used to restrict when active checks of a service can be performed. Passive checks are not restricted by execution dependencies.
If all of the execution dependency tests for the service passed, Nagios will execute the check of the service as it normally would. If even just one of the execution dependencies for a service fails, Nagios will temporarily prevent the execution of checks for that (dependent) service. At some point in the future the execution dependency tests for the service may all pass. If this happens, Nagios will start checking the service again as it normally would. More information on the check scheduling logic can be found here.
In the example above, Service E would have failed execution dependencies if Service B is in a WARNING or UNKNOWN state. If this was the case, the service check would not be performed and the check would be scheduled for (potential) execution at a later time.
Notification Dependencies
If all of the notification dependency tests for the service passed, Nagios will send notifications out for the service as it normally would. If even just one of the notification dependencies for a service fails, Nagios will temporarily repress notifications for that (dependent) service. At some point in the future the notification dependency tests for the service may all pass. If this happens, Nagios will start sending out notifications again as it normally would for the service. More information on the notification logic can be found here.
In the example above, Service F would have failed notification dependencies if Service C is in a CRITICAL state, and/or Service D is in a WARNING or UNKNOWN state, and/or if Service E is in a WARNING, UNKNOWN, or CRITICAL state. If this were the case, notifications for the service would not be sent out.