Sunday, May 19th 2013, 2:08am UTC+2

You are not logged in.

  • Login
  • Register

Probleme mit NSClient++ - "Socket Timeout after 10 Seconds" bei hoher CPU Last

Dear visitor, welcome to Monitoring-Portal.
Although this is a german monitoring forum, please don't hesitate to post in English. Nearly everybody here understands you and will answer in English as well.
If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form to register here or read more information about the registration process. If you are already registered, please login here.

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

1

Tuesday, May 11th 2010, 6:34am

Probleme mit NSClient++ - "Socket Timeout after 10 Seconds" bei hoher CPU Last

Hallo zusammen,
nachdem ich hier schon ettliche Infos für meine Nagios Implementierung gefunden habe hänge ich nun an einem Punkt den ich scheinbar nicht ohne weiteres lösen kann.

Und zwar habe ich desöfteren das Problem, dass bei hoher CPU Last das Check_nrpe Plugin nicht funktioniert.
Beispiel: unser Backupserver hat abends gegen 22:30 Uhr richtig viel zu tun - genau dann kommt fast jeden Abend folgender Fehler auf allen Services die wir überwachen:

Source code

 
1

CHECK_NRPE: Socket timeout after 10 seconds.


Nach dieser einen Meldung zu der Zeit läuft alles problemlos weiter, ohne Auffälligkeiten.

Ich habe versucht, das Ganze mit einem Timeoutwert von 30 Sekunden zu verbessern - leider ohne Erfolg, die Meldung heist zwar nun "socket timeout after 30 seconds", gebracht hats aber leider nichts.

Der Service läuft auf den betroffenen Systemen durch, zumindest ist kein Eventlog Eintrag zu sehen.

Hat jemand eine Idee was ich noch tun könnte? Irgendwie kann ich mir nicht vorstellen, dass ich so produktiv gehe wenn ich jetzt schon bei 150 Services solche Probleme habe. Ziel soll sein auf ca. 500 Services zu gehen... Vor allem da wir auch Hochlastsysteme haben die sicher noch viel öfter diesen Fehler bringen.

Ich bin für jeden Vorschlag offen und dankbar!

Vielen Dank schonmal,
Gruß Tom

Eckdaten des Zielsystems:
Windows 2003 Server Standard
NSClient ++ -0.3.7-Win32

Beispielservice:

Source code

 
1
2
3
4
5
6
7
8

define service {

    	host_name           	bsls2zxa
    	service_description 	Disc Space All Drives
    	use                 	generic-service,srv-pnp
    	check_command       	check_nrpe!CheckDriveSize!MinWarn=5% MinCrit=3%!CheckAll!FilterType=FIXED
    	register            	1
    	}


Generic Service:

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

define service {
   	name                                 	generic-service
   	is_volatile                          	0
   	max_check_attempts                   	1
   	check_interval                       	4
   	retry_interval                       	1
   	active_checks_enabled                	1
   	passive_checks_enabled               	1
   	check_period                         	24x7
   	parallelize_check                    	1
   	obsess_over_service                  	1
   	check_freshness                      	0
   	event_handler_enabled                	1
   	flap_detection_enabled               	1
   	process_perf_data                    	1
   	retain_status_information            	1
   	retain_nonstatus_information         	1
   	notification_interval                	60
   	notification_period                  	24x7
   	notification_options                 	w,u,c,r
   	notifications_enabled                	1
   	contact_groups                       	admins
   	failure_prediction_enabled           	1
   	register                             	0

}


Command Definition:

Source code

 
1
2
3
4
5

define command {
   	command_name                         	check_nrpe
   	command_line                         	$USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c $ARG1$ -t 30 -a $ARG2$
 $ARG3$ $ARG4$
}

Wal

Intermediate

Posts: 311

Gender: male

Location: Essen

Number of monitoring servers: 2

Nagios Version: -

Icinga Version: Icinga 1.0.3

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: ~250

Number of services: ~2200

OS: Lenny

Plugin Version: 1.4.14

NagVis Version: 1.5

Other Addons: PNP 0.6.6 - livestatus+check_mk GIT

2

Tuesday, May 11th 2010, 7:17am

Wenn das System ausgelastet ist verarbeitet es die Anfrage halt nicht direkt.
Möglichkeit wäre vielleicht den Dienst schon mit einer höheren Priorität zu starten.

Oder eben - wenn es einfach am Backup liegt - für diesen Zeitraum das Monitoring oder die Benachrichtigung deaktivieren.

Sonst guck dir vieleicht noch check_mk an, so bekommst viele Infos in nur einer Abfrage und musst das System nicht noch zusätzlich belasten.
Wobei das auch scheitern könnte, da gerade die Abfrage der Perfcounter gern hängt, wenn das System viel zu tun hat.

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

3

Tuesday, May 18th 2010, 8:02am

Hi,

einen Dienst mit hoher Priorität zu starten ist leider nicht ganz so einfach.
Backup ist nur ein Fall - teilweise haben wir Datenbankserver die einfach sporadisch Last erzeugen und dann der Zugriff nicht möglich ist.

Ich muss sagen dass ich derzeit recht enttäuscht bin von den Windows Clients. Ich sehe die Arbeit von Monaten schwinden, weil die Überwachung bzw. das Monitoring von Windows Servern nun nicht realisierbar aussieht. Blöd wenn man das erst beim Client Rollout feststellt...

Hat noch jemand eine Idee was man tun könnte? Gibt es einen Client der zumindest antwortet, auch wenn er gerade keine Chance hat Werte zu liefern?

tesso

Professional

Posts: 625

Gender: male

Number of monitoring servers: 1

Nagios Version: 3.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 88

Number of services: 690

OS: Debian etch

Plugin Version: 1.4.14

NagVis Version: 1.4.rc3

NDO Version: 1.4b7

Other Addons: NSClient++ ,PNP 0.4.13,NPCD,dokuwiki

4

Tuesday, May 18th 2010, 12:51pm

Warum setzt du nicht max_check_attempts etwas höher, um nicht jedes Timeout sofort als Fehler zu melden?

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

5

Tuesday, May 18th 2010, 2:37pm

Sorry, die Info habe ich nicht weitergegeben.

Bin schon dabei es schrittweise zu erhöhen. Derzeit bin ich bei
max_check_attempts 3

was leider immer noch nicht reicht. Viel höher möchte ich aber auch nicht gehen weil die Verzögerung sonst für eine Alarmierung nicht mehr ausreichend ist.

Gruß Tom

tesso

Professional

Posts: 625

Gender: male

Number of monitoring servers: 1

Nagios Version: 3.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 88

Number of services: 690

OS: Debian etch

Plugin Version: 1.4.14

NagVis Version: 1.4.rc3

NDO Version: 1.4b7

Other Addons: NSClient++ ,PNP 0.4.13,NPCD,dokuwiki

6

Tuesday, May 18th 2010, 5:28pm

retry_interval evtl. erhöhen?

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

7

Wednesday, May 19th 2010, 7:49am

Wenn ich retry_interval richtig verstehe kann ich den Wert nicht höher setzen.

"retry_interval 2" würde ja bedeuten, dass ich bis zu 6 Minuten warten muss bis ich einen Hard-State, also eine Alarmierung bekomme, weil er ja zwischen jedem Retry 2 Minunten wartet. Oder sehe ich das falsch?

Dann gehe ich lieber auf "max_check_attempts 4" und spare noch 2 Minuten :)

vicodas

Intermediate

Posts: 480

Birthday: Aug 16th 1965 (47)

Gender: male

Location: Deutschland

Occupation: Systemadmin Linux, DMZ

Number of monitoring servers: 5

Hobbies: Laufen, Angeln, Computa

Nagios Version: OMD mk Subskription

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: ~ 800

Number of services: sehr viele

OS: Nagios auf Debian, überwacht einiges ;-)

Plugin Version: OMD mk Subskription

NagVis Version: OMD mk Subskription

Other Addons: check_mk, SNMPTT, eigene,

8

Wednesday, May 19th 2010, 8:01am

also ich schalte für solche Zeiten die Benachrichtigung einfach aus.
Nutze dazu das Script sched_downtime.pl von Nic le Roux.

hth vicodas
+++ Github

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

9

Wednesday, May 19th 2010, 8:34am

Wenn mir die Zeiten bekannt wären, in denen die Server hohe Last fahren wäre das ja machbar. Leider kann ich das aber weder steuern noch auf ein bestimmtes Zeitfenster festlegen.

Andere Überlegung: Wäre es möglich, die Nichtereichbarkeit des NSClients, also den Socket-Error nicht als "Critical" zu werten? Das würde mir schon sehr helfen...

crush

Intermediate

Posts: 210

Gender: male

Occupation: ChefChoch-Engineer

Number of monitoring servers: ~5

Nagios Version: 3.x, icinga

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: ~200

Number of services: ~2000

OS: Ubuntu 9.04 LTS / Debian Stable

Plugin Version: up to date

NagVis Version: up to date

NDO Version: up to date

Other Addons: snmptt, nagtrap, nconf

10

Wednesday, May 19th 2010, 9:09am

hi

Hast du der aktuellste nsclient? ggf. mal einen ältern build versucht?

Passiert dies nur bei den CPU checks?

ist die CPUBufferSize = 1h ?

Gruss

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

11

Wednesday, May 19th 2010, 9:53am

NSClient 0.3.7

Ich habe jetzt nochmal nachgeschaut, der Fehler taucht eigentlich nur (sofern ich das jetzt in den Logs sehen konnte) beim Service "Disk Space All Drives" auf (check_nrpe!CheckDriveSize)

hm, muss ich wohl nochmal schauen...

shecki

Intermediate

Posts: 460

Gender: male

Location: Saarbrücken

Occupation: Sysadmin

Number of monitoring servers: 1

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 49

Number of services: 450

OS: Debian Squeeze

Plugin Version: 1.4.14

Other Addons: NagiosGrapher, SNMP, NSClient++

12

Wednesday, May 19th 2010, 10:13am

Ich geb mal nen Schuss ins Blaue ab und sage, du hast Probleme wenn die Platten viel zu tun haben, nicht die CPU und den 2. Schuss gleich hinterher, ihr nutzt Software Raid bzw. einen sehr einfachen Raid-Controller. Wenn beides stimmt, hast du nen Problem mit dem Raid, nicht mit Nagios. Weil das Phänomen, Rechner zuckt nicht mehr, wenn er hohe IO-Last hat, kenne ich und mit gescheiten Raid-Controller wars dann erledigt :)

tombug

Beginner

Posts: 13

Gender: male

Occupation: Admin

Number of monitoring servers: 1

Hobbies: MMORPG; Fotografie

Nagios Version: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 200

Number of services: 600

OS: Debian Lenny

Plugin Version: 1.4.14

Other Addons: NagiosQL 3.0.3; PnP4Nagios 0.6.2

13

Wednesday, May 19th 2010, 11:16am

Jau die Vermutung hatte ich nach der Erkenntnis oben auch. Allerdings haben wir recht performante Raids, überwiegend LSI (z.b. in einem Primergy Rx300 S3)

Ich muss jetzt mal versuchen den Fehler einzugrenzen, vermutlich liegts aber echt nur an den Raidsystemen, was mich jetzt einigermassen beruhigt, denn beim Plattencheck habe ich schon die Chance die Intervalle weitaus höher zu stellen.

Schonmal besten Dank für die Mithilfe bisher, ich meld mich wieder

Simon L.

Trainee

Posts: 124

Birthday: Oct 16th

Gender: male

Location: Münster

Number of monitoring servers: 2

Hobbies: Fussball

Nagios Version: 3.2.3

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ca. 200

Number of services: ca. 1500

OS: Ubuntu LTS 12.04

Plugin Version: 1.4.16

Other Addons: OMD 0.56

14

Friday, May 21st 2010, 3:49pm

Hallo,

ich habe das gleiche Problem. Zu Beginn habe ich check_nt genutzt, um meine Windows Server zu überwachen, da hatte ich ständig Timeouts. Was bei mir aber ein Grund war, dass die Server alle sehr langsam waren. Unser ESX war ausgelastet und so war die RTA auch sehr oft über 100 ms.

Ich bin dann von NSClient ( check_nt ) auf NRPE umgestiegen, als Client auf den Servern nutze ich NSClient++. Den Timeout habe ich bei den Befehlen auf 30 sec. hochgsetzt und so das Problem zu 99% lösen können. Leider kommen sporadisch immer noch Timeout Meldungen durch. Ich hatte dieses Verhalten auch nicht nur bei Festplattenchecks, sondern generell bei allen Prüfungen.

Mich wundert wirklich, warum kein Zweiter sowas schonmal hatte, kann mir nicht vorstellen, dass unsere Infrastruktur einfach nur schlecht ist :)

Similar threads