Saturday, May 18th 2013, 2:00pm UTC+2

You are not logged in.

  • Login
  • Register

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.

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

1

Thursday, April 5th 2012, 4:41pm

inGraph: Keine Performancedaten für services verfügbar

Hallo zusammen,

ich verwende icinga-web 1.7-dev mit inGraph 1.0.
Seit der Installation vom inGraph vor gut einer Woche gibt es immer noch keine Performance Daten für jegliche Services. Lediglich die host-alive ICMP Daten sind im Cronk per "mouse over" verfügbar.
In "/usr/local/icinga/var/perfdata/" gibt es jede Menge host-perfdata.*.bak files. ABER: Es gibt auch ein bereits 95MB großes "service-perfdata" file.

Ein Blick in die mysql DB vom ingraph mit einem "select * from service;" gibt eine leere Tabelle zurück...

Im LConf sehe ich die vier commands "process...". Das command "process-service-perfdata-file" wird wohl scheinbar niemals ausgeführt?

ps -ax | grep ingraph

Source code

1
2
3
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
15975 ?    	Sl 	0:02 python -m ingraph/bin/ingraphd -d /etc/ingraph -p /var/run/ingraph/ingraphd.pid -u ingraph -o  restart
16116 ?    	S  	0:02 python -m ingraph/bin/ingraph_collectord -d /etc/ingraph -p /var/run/ingraph/ingraph-collectord.pid -P /usr/local/icinga/var/perfdata -e *-perfdata.*[0-9] -l 50 -m BACKUP -s 60 -u ingraph -g icinga -o - restart


Hat jemand eine Idee, was ich beim Setup vergessen haben könnte??

Gruß,

Tim

lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

2

Monday, April 16th 2012, 10:26am

Hi,

vergleiche deine Konfiguration bitte mit folgenden Beispieleinträgen:

icinga.cfg

Source code

1
2
3
4
5
service_perfdata_file=/usr/local/icinga/var/perfdata/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=30
service_perfdata_file_processing_command=process-service-perfdata-file


commands.cfg

Source code

1
2
3
4
define command {
command_name    process-service-perfdata-file
command_line    mv /usr/local/icinga/var/perfdata/service-perfdata /usr/local/icinga/var/perfdata/service-perfdata.$TIMET$
}
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

audioslave

Beginner

Posts: 9

Number of monitoring servers: 1

Nagios Version: check_mk 1.1.12p6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 4

Number of services: 98

OS: Linux, Windows

Plugin Version: 1.1.12p6-1

NDO Version: 1

3

Monday, April 16th 2012, 11:36am

Hallo,

ich hänge mich mal an das Thema mit dran. Mein inGraph läuft seit ca. einer Stunde, aber das perfdata-Verzeichnis ist immer noch leer.
Habe die Einträge, die Du erwähnt hast überprüft und diese sind korrekt. Ich bin in der Materie ziemlich neu und wäre daher für Hilfe sehr dankbar!

audioslave

Beginner

Posts: 9

Number of monitoring servers: 1

Nagios Version: check_mk 1.1.12p6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 4

Number of services: 98

OS: Linux, Windows

Plugin Version: 1.1.12p6-1

NDO Version: 1

4

Monday, April 16th 2012, 12:38pm

Hat sich erledigt, der Fehler saß vorm Bildschirm :)

Posts: 7,238

Gender: male

Number of monitoring servers: 2

Nagios Version: 3.2.1

Icinga Version: Icinga 1.7.x

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: >70

Number of services: >200

OS: SLES11

Plugin Version: 1.4.15

Other Addons: NRPE 2.6, NSCA 2.7, PNP 0.4.14 / 0.6.18

5

Monday, April 16th 2012, 12:57pm

Quoted

Hat sich erledigt, der Fehler saß vorm Bildschirm
Vielleicht hilft es anderen, wenn du schreibst, was verkehrt war.

audioslave

Beginner

Posts: 9

Number of monitoring servers: 1

Nagios Version: check_mk 1.1.12p6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 4

Number of services: 98

OS: Linux, Windows

Plugin Version: 1.1.12p6-1

NDO Version: 1

6

Monday, April 16th 2012, 1:51pm

Hast recht.

Ich hatte vergessen den Icinga-Daemon durchzustarten nach dem ich process_performance_data=1 in der icinga.cfg gesetzt hatte. Somit wusste Icinga natürlich nicht, dass es Performance Daten sammeln soll :)

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

7

Monday, April 16th 2012, 4:25pm

Danke für die Rückmeldung!

Ich habe in der 'command_line' am Ende eine geschweifte Klammer zuviel gefunden. Da ich das ganze per LCONF editiere, kann es sein, dass ich zu großzügig Copy&Paste benutzt habe...

Nun wurde mein 620MB service-perfdata file endlich mal gemoved. Mal abwarten obs bald Graphen im icinga gibt :)

edit: das kann wohl ein paar stunden dauern oder ab wann sollte in den ingraph prozess mal killen...?

Source code

1
2
PID USER  	PR  NI  VIRT  RES  SHR S %CPU %MEM	TIME+  COMMAND
15975 ingraph   20   0 3611m 3.3g 1340 S  100 21.3  72:39.46 python

This post has been edited 1 times, last edit by "timmer" (Apr 16th 2012, 5:05pm)


lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

8

Monday, April 16th 2012, 5:19pm

Der wird jetzt fleißig in die Datenbank einfügen - solltest du nicht von alleine killen müssen
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

9

Tuesday, April 17th 2012, 8:58am

Der wird jetzt fleißig in die Datenbank einfügen - solltest du nicht von alleine killen müssen
Der ingraph daemon läuft immer noch bei 100% Cpu Last. Bist du sicher, dass das ein normales Verhalten ist? Es sind auch nach wie vor noch keine Performancegraphen im icinga-web zu sehen.

lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

10

Tuesday, April 17th 2012, 10:36am

:S

Kannst du ein strace laufen lassen (1-2 Minuten sollte reichen):

Source code

1
# strace -p 15975 -s 1024 -o /tmp/ingraph.strace


und zusammen mit

Source code

1
mysql> show processlist;


hier anhängen?
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

11

Tuesday, April 17th 2012, 11:43am

Source code

1
2
3
4
5
6
7
8
9
10
11
mysql> show processlist;
+--------+-----------+-----------------+---------+---------+------+-------+------------------+
| Id 	| User  	| Host        	| db  	| Command | Time | State | Info         	|
+--------+-----------+-----------------+---------+---------+------+-------+------------------+
| 	40 | eventdbrw | localhost:53118 | eventdb | Sleep   |   39 |   	| NULL         	|
| 207515 | icinga	| localhost   	| icinga  | Sleep   |	1 |   	| NULL         	|
| 207663 | icinga	| localhost   	| icinga  | Sleep   | 2718 |   	| NULL         	|
| 223072 | root  	| localhost   	| NULL	| Query   |	0 | NULL  | show processlist |
| 223073 | eventdbrw | localhost   	| eventdb | Sleep   |	7 |   	| NULL         	|
+--------+-----------+-----------------+---------+---------+------+-------+------------------+
5 rows in set (0.00 sec)


Source code

1
2
/tmp$ cat ingraph.strace
futex(0xebadc0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>

lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

12

Wednesday, April 18th 2012, 10:36am

Kannst du noch ein strace vom ingraph-collectord nachschieben oder hast du ihn bereits abgeschossen?
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

13

Wednesday, April 18th 2012, 11:25am

nöö, ich bin ja geduldig ;-)

Source code

1
2
cat /tmp/ingraph_collectord.strace
recvfrom(7,  <unfinished ...>


danke für deine hilfe!

lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

14

Wednesday, April 18th 2012, 4:34pm

Du darfst jetzt beide Daemons beenden :D.

Kurz zum Problem:
Der ingraph_collector liest die 620MB Performance-Daten ein und sendet diese nach Formatierung an den ingraph Daemon, welcher in die Datenbank einfügt. Da der ganze Prozess Arbeitsspeicher-intensiv ist, wird wie blöd ins Dateisystem ausgelagert, was den ganzen Prozess SEHR träge macht.

Die "neue" Version des ingraph_collector im Anhang, teilt die zu sendenden Daten auf, sodass immer nur eine erträgliche Menge verarbeitet werden muss.

Bei mir liegt der ingraph_collector hier:
/usr/lib/python2.6/site-packages/ingraph-1.0-py2.6.egg/ingraph/bin/ingraph_collectord.py
Auf deinen System kann der Pfad natürlich abweichen (andere Python Version), aber diese Datei muss überschrieben werden.

Wenn das erledigt ist, kannst du beide Daemons wieder starten.
lippser has attached the following file:
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

15

Wednesday, April 18th 2012, 5:00pm

bevor ich deine antwort bemerkt hatte, hatte ich bereits den ingraphd gekillt. anschließend habe ich nochmal einen strace vom collector gemacht. sah aus als hätte er dann endlich gearbeitet...

Source code

1
2
3
4
5
6
cat /tmp/ingraph_collectord.strace2
socket(PF_NETLINK, SOCK_RAW, 0)     	= 7
bind(7, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(7, {sa_family=AF_NETLINK, pid=16116, groups=00000000}, [12]) = 0
sendto(7, "\24\0\0\0\26\0\1\3e\317\216O\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0e\317\216O\364>\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1\10\0\2\0\177\0\0\1\7\0\3\0lo\0\0<\0\0\0\24\0\2\0e\317\216O\364>\0\0\2\30\200\0\2\0\0\0\10\0\1\0\n\233\fj\10\0\2\0\n\233\fj\10\0\4\0\n\233\f\377\t\0\3\0eth0\0\0\0\0\24\0\6\0\377\377\377\377\377\377\377\377\23\5\0\0\23\5\0\0\340\220\2700\377\177\0\0\360\22\225\2\0\0\0\0\240!D\0\0\0\0\0\320\340\202\2\0\0\0\000000000;5000.000000;0.000000 pl=0%;80;100\222\r7\366\300\177\0\0\360\336*;\0\0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\1\0\0\0\0\0\0\0\20\221\2700\377\177\0\0\323R6\366\300\177\0\0\220\354\260\2\0\0\0\0\340\231\273\2\0\0\0\0\220\354\260\2\0\0\0\0\0\0\0\0\0\0\0\0\20\221\2700\377\177\0\0\277\"D\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0TA::rta=0.519000ms;3000.\0\0\0\0\0\0\0\000000.000000;0.000000 pl=0%;80;100;0\tHOSTCHECKCOMMAND::check-host-alive\tHOSTSTATE::UP
usw.

hab dein skript eingebunden und die daemons gestartet... abwarten :D

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

16

Thursday, April 19th 2012, 9:55am

soooo... heute morgen sieht es schon deutlich besser aus. Es gibt für jeden Host und Service schöne bunte Graphen!
Seltsamerweise enden alle host /service performance Graphen am 16.04. 14Uhr ?(

lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

17

Thursday, April 19th 2012, 11:02am

Sorry, da muss ich dir nochmal ein Update nachreichen.
Deine Version sendet erst Daten zum ingraph Daemon wenn mdt. 25000 Updates gesammelt wurden. Die angehängte Version zusätzlich alle 30 Sekunden.
Ich hoffe du hast deine Performance-Dateien noch (*.bak)? Da müsstest du den suffix entfernen, damit diese nochmal eingelesen werden.
lippser has attached the following file:
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

timmer

Beginner

Posts: 9

Gender: male

Location: Hamburg

Number of monitoring servers: 1

Nagios Version: Icinga Core 1.6.1

Icinga Version: Icinga Web 1.7

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 800

OS: Ubuntu Server 11.10

Plugin Version: 1

NDO Version: 1

18

Thursday, April 19th 2012, 11:50am

Danke erstmal! Fließen deine Änderungen eigentlich in die nächste ingraph Version mit ein?

Wer oder was räumt das perfdata dir auf? Ich habe da nun 65000 .bak files drin.
Ich würde dann per "rename 's/\.bak$//' *.bak" alle files umbennen... Ob wohl wieder was unvorhergesehenes passiert, wenn der ingraph soviel zu fressen bekommt?

lippser

Intermediate

Posts: 184

Gender: male

Occupation: Application Developer

Nagios Version: -

Icinga Version: 1.8.0

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: -

Number of services: -

OS: Ubuntu 12.04

Plugin Version: 1.4.16

19

Thursday, April 19th 2012, 12:15pm

Ja fließen Sie, ich bin einer der Entwickler.

Es gibt zwei Modes für den collector: BACKUP (default) und REMOVE. Diesen kannst du via /etc/default/ingraph-collector ändern:

Source code

1
2
# cat /etc/default/ingraph-collector
INGRAPH_COLLECTOR_FILE_MODE="REMOVE"


Zum umbennen würde ich lieber sowas machen:

Source code

1
for file in $(find $PERFDATADIR -type f -name \*.bak -mtime -7); do mv $file ${file%.bak}; done;


Finde alle Dateien im $PERFDATADIR mit Suffix .bak, die nicht älter als 7 Tage sind (das Minus ist wichtig, oder du machst "! -mtime 7") und bennen diese um.
NETWAYS GmbH http://www.netways.de
NETWAYS Blog http://blog.netways.de

zalubom

Beginner

Posts: 7

Number of monitoring servers: 1

Nagios Version: Icinga 1.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 120

Number of services: 60

OS: Debian

Plugin Version: Ingraph

NDO Version: 1

20

Friday, June 22nd 2012, 10:15am

Hallo lippser,

ich habe Deine Anpassungen ausprobiert und diese Zeile:

Source code

1
if last_flush + 30 < time.time() or len(updates) >= 25000:


führt bei mir dazu, dass einige Services nicht in der Datenbank landen, sondern ignoriert werden.

Bitte schau doch da noch mal drüber.

Danke.

Hartmut