Wednesday, May 22nd 2013, 3:03am UTC+2

You are not logged in.

  • Login
  • Register

idomod: Error writing to data sink!

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.

ArnimS

Beginner

Posts: 6

Number of monitoring servers: 2

Nagios Version: Icinga 1.0RC1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 83

Number of services: 452

OS: CentOS 5.3

Plugin Version: 1.4.14

NDO Version: 2

1

Monday, November 2nd 2009, 9:50pm

idomod: Error writing to data sink!

Hallo,



ich teste gerade die Icinga 1.0RC1 auf einem CentOS 5.3.

Soweit sieht alles gut aus.



Bis auf eine Kleinigkeit:

Alle 16 Sekunden bekomme ich zwei Zeilen im Log



--------------------------------------------------------------------------------

Nov 2 21:16:00 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:16:00 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:16:16 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 112 queued items to flush.
Nov 2 21:16:16 localhost icinga: idomod: Successfully flushed 112 queued items to data sink.
Nov 2 21:16:16 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:16:16 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:16:32 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 138 queued items to flush.
Nov 2 21:16:32 localhost icinga: idomod: Successfully flushed 138 queued items to data sink.
Nov 2 21:16:50 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:16:50 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:17:06 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 254 queued items to flush.
Nov 2 21:17:06 localhost icinga: idomod: Error writing to data sink! Some output may get lost. 18 queued items to flush.
Nov 2 21:17:22 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 235 queued items to flush.
Nov 2 21:17:22 localhost icinga: idomod: Successfully flushed 235 queued items to data sink.
Nov 2 21:17:22 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:17:22 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:17:38 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 120 queued items to flush.
Nov 2 21:17:38 localhost icinga: idomod: Successfully flushed 120 queued items to data sink.
Nov 2 21:17:50 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:17:50 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:18:06 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 177 queued items to flush.
Nov 2 21:18:06 localhost icinga: idomod: Successfully flushed 177 queued items to data sink.
Nov 2 21:18:06 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:18:06 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:18:22 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 247 queued items to flush.
Nov 2 21:18:22 localhost icinga: idomod: Successfully flushed 247 queued items to data sink.
Nov 2 21:18:30 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:18:30 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:18:46 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 282 queued items to flush.
Nov 2 21:18:46 localhost icinga: idomod: Error writing to data sink! Some output may get lost. 51 queued items to flush.
Nov 2 21:19:02 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 306 queued items to flush.
Nov 2 21:19:02 localhost icinga: idomod: Error writing to data sink! Some output may get lost. 60 queued items to flush.
Nov 2 21:19:18 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 247 queued items to flush.
Nov 2 21:19:18 localhost icinga: idomod: Successfully flushed 247 queued items to data sink.
Nov 2 21:19:30 localhost icinga: idomod: Error writing to data sink! Some output may get lost...
Nov 2 21:19:30 localhost icinga: idomod: Please check remote ido2db log, database connection or SSL Parameters
Nov 2 21:19:46 localhost icinga: idomod: Successfully reconnected to data sink! 0 items lost, 300 queued items to flush.
Nov 2 21:19:46 localhost icinga: idomod: Error writing to data sink! Some output may get lost. 71 queued items to flush.
--------------------------------------------------------------------------------



Es ist ja nicht so, als ob der ido2db Prozess keine Daten schreiben kann; in der Datenbank sind die Werte da.

Es scheint auch so, dass kurzzeitig zum laufenden ido2bd Prozess ein 2. Prozess gestartet wird, der sich sofort wieder terminiert.



Hier meine etc/ido2db.cfg:

lock_file=/usr/local/icinga/var/ido2db.lock
ido2db_user=icinga
ido2db_group=icinga
socket_type=unix
socket_name=/usr/local/icinga/var/ido.sock
tcp_port=5668
use_ssl=0
db_servertype=mysql
db_host=localhost
db_port=3306
db_name=icinga
db_prefix=icinga_
db_user=icinga
db_pass=icinga
max_timedevents_age=1440
max_systemcommands_age=10080
max_servicechecks_age=10080
max_hostchecks_age=10080
max_eventhandlers_age=44640
max_externalcommands_age=10080
trim_db_interval=60
debug_level=0
debug_verbosity=1
debug_file=/usr/local/icinga/var/ido2db.debug
max_debug_file_size=1000000


Hier die etc/idomod.cfg:

instance_name=default
output_type=unixsocket
output=/usr/local/icinga/var/ido.sock
tcp_port=5668
use_ssl=0
output_buffer_items=5000
buffer_file=/usr/local/icinga/var/ndomod.tmp
file_rotation_interval=14400
file_rotation_timeout=60
reconnect_interval=15
reconnect_warning_interval=15
data_processing_options=-1
config_output_options=2



Jemand eine Idee, was ich falsch gemacht habe?



Gruß

Arnim

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

2

Monday, November 2nd 2009, 11:30pm

... Interssant :-)

eventuell hast du das selbe Problem wie ich: https://dev.icinga.org/issues/show/154

Kannst du mal überprüfen ob meine Symtpome bei dir auch zutreffen?

debug_level=2
debug_verbosity=2

o.ä.

dnsmichi

Super Moderator

Posts: 5,981

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

3

Tuesday, November 3rd 2009, 1:18am

16 sekunden trifft soweit ich weiss auf die reconnect time zu, das ist also nichts ungewoehnliches. mich wuerde aber der volle debug_output interessieren, der zu diesen zeiten auftritt. vielleicht ists ja auch nur ein anderer kleiner bug - meist eine fehlerhafte query, die segfaults sollte ich mittlerweile alle draussen haben. den den ich heute gefixed habe in servicechecks, wirft keine fehler, sondern schreibt nur zu wenig in die table. also zwischen bugfix und rc1 sollte mal kein unterschied sein.
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ArnimS

Beginner

Posts: 6

Number of monitoring servers: 2

Nagios Version: Icinga 1.0RC1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 83

Number of services: 452

OS: CentOS 5.3

Plugin Version: 1.4.14

NDO Version: 2

4

Tuesday, November 3rd 2009, 12:54pm

Hallo,



habe den Debuglevel hochgesetzt und auf ausführlich eingestellt.

Dabei tritt ein kleines Problem auf:



Der ido2db Hauptprozess läuft mit PID 29585 und schreibt in das Logfile.

Dann startet irgendwann ein zweiter ido2db Prozess an und scheibt ebenfalls in das Logfile.

Nach einiger Zeit schlägt dann der Hauptprozess mit der Funktion ndo2db_parent_sighandler() start zu und erstellt die Debug-Datei neu...


Da ich es nicht besser wusste, habe ich via Putty die Dateiausgabe mitgelogt, siehe Anhang.



Braucht ihr noch weitere Informationen?



Danke erst einmal.

Gruß

Arnim
ArnimS has attached the following file:
  • putty.zip (79.77 kB - 65 times downloaded - Last download: Mar 4th 2013, 3:58am)

dnsmichi

Super Moderator

Posts: 5,981

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

5

Tuesday, November 3rd 2009, 6:39pm

hmmm da greift der sighandler wesentlich vor dem string escape rein, crush.

[1257248253.907117] [001.2] [pid=32763] ndo2db_handle_servicecheckdata() start

nach einem string to int geht das ding sterben. und das hier ist nicht die statuscommanddata query, sondern servicechecks. wobei das aeusserst strange ist. was ich aber grundsaetzlich nicht verstehe, wieso das debug log ueberschrieben wird, bzw neu angelegt. es ist normal, dass der parent process einen child forked der bei ankommender connection dann einen grandchild forked, der dann sessioneader wird. also die unterschiedlichen PIDs sind normal.

wie startest du die ido2db - via init-script?
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ArnimS

Beginner

Posts: 6

Number of monitoring servers: 2

Nagios Version: Icinga 1.0RC1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 83

Number of services: 452

OS: CentOS 5.3

Plugin Version: 1.4.14

NDO Version: 2

6

Tuesday, November 3rd 2009, 6:48pm

Ja. Start via init-Script.



Habe aber gestern auch mehrfach via commandline gestartet; gleicher Effekt.



Kann ich Dir noch mehr Infos geben?



Gruß

Arnim

dnsmichi

Super Moderator

Posts: 5,981

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

7

Monday, November 9th 2009, 6:34pm

sorry, ich hatte letzte woche ein wenig mehr zu tun bzw hab ich den oracle support improved, nachdem das meien primaer aufgabe in der arbeit ist.

grundsaetzlich bedeutet dein fehleroutput folgendes:

Source code

 
1
2
3
4
5
6
7
8
9
10

[1257248253.907117] [001.2] [pid=32763] ndo2db_handle_servicecheckdata() start

        ndo2db_log_debug_info(NDO2DB_DEBUGL_PROCESSINFO, 2, "ndo2db_handle_servicecheckdata() start\n");

        if (idi == NULL)
                return NDO_ERROR;

        /* convert timestamp, etc */
        result = ndo2db_convert_standard_data_elements(idi, &type, &flags, &attr,
                        &tstamp);


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

[1257248253.907122] [001.2] [pid=32763] ndo2db_convert_standard_data_elements() start
[1257248253.907127] [001.2] [pid=32763] ndo2db_convert_string_to_int() start
[1257248253.907133] [001.2] [pid=32763] ndo2db_convert_string_to_int() end
[1257248253.907138] [001.2] [pid=32763] ndo2db_convert_string_to_int() start
[1257248253.907143] [001.2] [pid=32763] ndo2db_convert_string_to_int() end
[1257248253.907148] [001.2] [pid=32763] ndo2db_convert_string_to_int() start
[1257248253.907154] [001.2] [pid=32763] ndo2db_convert_string_to_int() end
[1257248253.907159] [001.2] [pid=32763] ndo2db_convert_string_to_timeval() start
[1257248253.907165] [001.2] [pid=32763] ndo2db_convert_string_to_unsignedlong() start
[1257248253.907176] [001.2] [pid=32763] ndo2db_convert_string_to_unsignedlong() end
[1257248253.907182] [001.2] [pid=32763] ndo2db_convert_string_to_unsignedlong() start
[1257248253.907187] [001.2] [pid=32763] ndo2db_convert_string_to_unsignedlong() end
[1257248253.907192] [001.2] [pid=32763] ndo2db_convert_string_to_timeval() end
[1257248253.907198] [001.2] [pid=32763] ndo2db_convert_standard_data_elements() end

        /* only process some types of service checks... */
        if (type != NEBTYPE_SERVICECHECK_INITIATE && type
                        != NEBTYPE_SERVICECHECK_PROCESSED)
                return NDO_OK;

        /* skip precheck events - they aren't useful to us */
        if (type == NEBTYPE_SERVICECHECK_ASYNC_PRECHECK)
                return NDO_OK;


bis daher gehts noch gut.

Source code

 
1
2
3
4

        result = ndo2db_convert_string_to_int(idi->buffered_input[NDO_DATA_CHECKTYPE], &check_type);

[1257248253.907203] [001.2] [pid=32763] ndo2db_convert_string_to_int() start
[1257248253.907208] [001.2] [pid=32763] ndo2db_convert_string_to_int() end


dann stehts hier an:

Source code

 
1

        result = ndo2db_convert_string_to_int(idi->buffered_input[NDO_DATA_CURRENTCHECKATTEMPT], &current_check_attempt);


dann sollte es aber weitegehen, da der timestamp nicht schluessig dazupasst...

[1257248364.185370] [001.2] [pid=29585] ndo2db_parent_sighandler() start

ich denke, da fehlt einiges an debugoutput. zieh dir bitte mal den aktuellen git master und probiers nochmals damit. und poste bitte alle warnings bei configure / make.

bzw wie du das ganze installierst, und Centos x86 oder x64?
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ArnimS

Beginner

Posts: 6

Number of monitoring servers: 2

Nagios Version: Icinga 1.0RC1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 83

Number of services: 452

OS: CentOS 5.3

Plugin Version: 1.4.14

NDO Version: 2

8

Tuesday, November 10th 2009, 5:31pm

Hallo,



ist ein CentOS 5.3 x86.



Habe jetzt folgendes gemacht:



# git clone git://git.icinga.org/icinga-core.git

# cd icinga-core/

# make clean

#./configure --enable-idoutils > ~/configure.out

# make all > ~/makeall.out

# make fullinstall

Output siehe Anhang.



Alte DB gekillt und neu angelegt:

# mysql -u root -p

mysql> drop DATABASE icinga;

mysql> CREATE DATABASE icinga;

mysql> GRANT USAGE ON *.* TO [url='''http://www.nagios-portal.org/wbb/mailto:'icinga'@'localhost'''']'icinga'@'localhost'[/url] IDENTIFIED BY 'icinga' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;

mysql> GRANT SELECT , INSERT , UPDATE , DELETE ON icinga.* TO [url='''http://www.nagios-portal.org/wbb/mailto:'icinga'@'localhost'''']'icinga'@'localhost'[/url];

mysql> FLUSH PRIVILEGES ;

mysql> quit



# cd module/idoutils/db/

# mysql -u root -p icinga < mysql.sql



Datei /usr/local/icinga/etc/icinga.cfg editiert:

# Uncomment this to enable idomod.o
broker_module=/usr/local/icinga/bin/idomod.o config_file=/usr/local/icinga/etc/idomod.cfg


Dann gestartet:

# /etc/init.d/ido2db start

# /etc/init.d/icinga start



Result: Genau die gleichen Fehler...



Noch eine Idee?



Gruß

Arnim
ArnimS has attached the following file:
  • output.zip (4.38 kB - 61 times downloaded - Last download: Mar 18th 2013, 3:11pm)

dnsmichi

Super Moderator

Posts: 5,981

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

9

Tuesday, November 10th 2009, 5:55pm

sieht ganz normal aus, ausser dass die submodule nicht ausgecheckt sind, von dem her der api fehler (git submodule init && git submodule update helfen weiter).

ich muss jetzt laestig sein, aber ich kann mir nicht erklaeren, warum deine ido2db.debug derartig verstuemmelt wird. setz bitte mal die filesize so hoch wie moeglich (100mb oder gleich 1 GB, je nachdem, was dein filesystem erlaubt) und grep mal drueber ob da drinnen ausser dem sighandler beim starten noch einer aufschlaegt. bzw ein error zum zeitpunkt wie es in der /var/log/messages matched (unixtimesstamp.com hilft zum convertieren)
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ArnimS

Beginner

Posts: 6

Number of monitoring servers: 2

Nagios Version: Icinga 1.0RC1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 83

Number of services: 452

OS: CentOS 5.3

Plugin Version: 1.4.14

NDO Version: 2

10

Tuesday, November 10th 2009, 6:52pm

Habe die debugfilesize mal höher gesetzt.

Das Logfile wurde jetzt nicht mehr abgeschnitten, soweit so gut.



Im Anhang das Logfile. (In der Mitte gekürzt, da sonst zu groß für als Anhang)



Es hoffe, es hilft Dir weiter...



Gruß

Arnim
ArnimS has attached the following file:
  • ido2db.zip (225.95 kB - 52 times downloaded - Last download: Mar 4th 2013, 4:00am)

dnsmichi

Super Moderator

Posts: 5,981

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

11

Tuesday, November 10th 2009, 8:55pm

omfg was habe ich da gebaut... ich sehs schon. bin gerade im icinga skype meeting, ich fixe es nachher ;-)

edit: ok das ist mal sehr strange. das ist die status_update_time die da ned durchgeht, und kein 0er generiert wird fuer zeit zumindest im fehlerfall. ich versuche es mal nachzuvollziehen, koennte aber dauern, da ich grade einen monster mysql bug gefunden habe bez der unique keys in den tables.
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

This post has been edited 1 times, last edit by "dnsmichi" (Nov 10th 2009, 9:17pm)

dnsmichi

Super Moderator

Posts: 5,981

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

12

Tuesday, November 10th 2009, 10:14pm

ok, ich hab keinen tau warum da ts[0] leer ist, also der fehlendende value.. und das nur beim ersten wert so ist und beim rest alles normal.. bei postgres/oracle sehe ich den fehler nicht sowie meine aktuelle mysql version auch ganz normal tut. bei mir ists ein rhel 5.4 x64. aber bitte zieh dir mal den aktuellen git master und versuchs damit.

https://git.icinga.org/index?p=icinga-core.git;a=summary
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ArnimS

Beginner

Posts: 6

Number of monitoring servers: 2

Nagios Version: Icinga 1.0RC1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 83

Number of services: 452

OS: CentOS 5.3

Plugin Version: 1.4.14

NDO Version: 2

13

Wednesday, November 11th 2009, 10:31am

DU BIST DER BESTE!!!!!!!!!!!!!!!!!!!!!!!



Klappt jetzt, vielen Dank!



Gruß

Arnim

Similar threads