Nagios invoked oom-killer

[estebanmonge]

Last time I put that we had about 600, now we have 907. It's difficult to measure the metric in 232 hosts and 1235 services.

OK I make this task:

tailf syslog > prueba.log

For one minute, before worked with the file:
cat prueba.log | grep "PASSIVE SERVICE" | wc -l
145 Passive Service Checks for minute
cat prueba.log | grep "PASSIVE HOST" | wc -l
60 Passive Host Checks for minute

[slansing]

Are those processes being killed off now? Because when you see those processes are spooling up when returning NSCA check data to the Nagios system.

[estebanmonge]

Are those processes being killed off now? Because when you see those processes are spooling up when returning NSCA check data to the Nagios system.

Sorry but don't understand you. This behavior is bad?

[slansing]

No, you should see new NSCA child processes start when they are required to receive check data from your checks. The way it seemed earlier was that the NSCA processes were not being killed after they were being called and used. This would be an issue, but as it seems they clear out after a certain amount of time you should be fine.

[estebanmonge]

In average we have three or four process, we use check_procs for determine it.

[slansing]

You should be fine then, nothing to worry about as Nagios and NSCA fork themselves for different checks.

[estebanmonge]

OK, returning to original question, the amount of checks that you need is the correct info?

[scottwilkerson]

Apparently I don't understand the question... Could you re-phrase it?

[estebanmonge]

Hello I make more testing in remote Nagios and passive checks.

Recently I needed to add more or less 400 passive check from remote Nagios to Prinicipal Nagios, but constantly passive checks get loss.

I tried to check if remote Nagios can sent checks, but the log never shows a incorrect sent package.

What could cause the problem?

[scottwilkerson]

Can you run the following and post the results

Code: Select all

cat /etc/xinetd.d/nsca