Saturday, May 18th 2013, 10:04pm UTC+2

You are not logged in.

  • Login
  • Register

ossmon

Beginner

Posts: 34

Location: Berlin

Number of monitoring servers: 1

Nagios Version: none

Icinga Version: 1.8

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 900

Number of services: 17000

OS: RHEL 6.0

Plugin Version: 1.4.15

Other Addons: pnp4nagios, mod_gearman

1

Thursday, June 28th 2012, 7:52am

Sinn von bestimmten INSERT/UPDATE in IDO

Hallo,

wenn ich den ido2db Process trace, sehe ich dass ständig UPDATE der Tabellen icinga_customvariablestatus und icinga_programstatus durchgeführt werden.

- Wozu sind diese Tabelle da ?
- Kann man diese Aktualisierung beeinflüssen ?

Danke.

dnsmichi

Super Moderator

Posts: 5,976

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

2

Thursday, June 28th 2012, 11:12am

RE: Sinn von bestimmten INSERT/UPDATE in IDO


wenn ich den ido2db Process trace, sehe ich dass ständig UPDATE der Tabellen icinga_customvariablestatus und icinga_programstatus durchgeführt werden.

- Wozu sind diese Tabelle da ?



http://docs.icinga.org/latest/de/db_mode…mvariablestatus - der status bzw value von custom variables, und ob er sich geaendert hat. das wird von idomod im zuge eins host/service/... status updates (getriggert durch einen nebcallback) ausgelesen, und mitgeschickt, womit dann ido2db nach einer host/service/... status update query auch diese durchfuehrt. dh du hast sequenziell nach regulaerem update auch die customvariablen als status update (sofern du welche hast fuer diesen host)

http://docs.icinga.org/latest/de/db_mode…m_programstatus - diese tabelle lesen bspweise icinga-web und nagvis um festzustellen, dass der core eh brav seine daten aktuell und frisch in die db schreibt. anderenfalls wuerde das bedeuten, dass in der kette was verstorben ist, und bewegt die gui dazu, dir einen fetten error hinzumalen.


- Kann man diese Aktualisierung beeinflüssen ?
.


customvariablestatus - keine definiert haben - keine updates.
programstatus - wird vom core als callback NEBCALLBACK_PROGRAM_STATUS_DATA initiiert.
das passiert oefters, folgender grep hilft dir die locations zu eruieren:

Source code

1
~/coding/icinga/icinga-core $ grep -r update_program_status *


zb

- alle 5 sekunden innerhalb der event loop (events.c)
- wenn time compensation stattfindet (events.c)
- alle 10 sekunden bei external commands (commands.c)
- wenn die eventhandler global geaendert werden (commands.c)
- wenn notifications program-wide enabled/disabled werden (commands.c)
- wenn host+service checks executed werden (start/stop) (commands.c)
- wenn passive host+service checks akzeptiert werden (start/stop) (commands.c)
- wenn eventhandler verwenden werden (start/stop) (commands.c)
- wenn obsess over host/service gestartet/gestoppt wird (commands.c)
- wenn host+service freshness aktiviert/deaktiviert wird (commands.c)
- wenn failure prediction enabled/disabled wird (commands.c)
- wenn performance data enabled/disabled wird (commands.c)
- wenns logfile rotiert wird (logging.c)
- wenn flapping an/aus gestellt wird (flapping.c)
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ossmon

Beginner

Posts: 34

Location: Berlin

Number of monitoring servers: 1

Nagios Version: none

Icinga Version: 1.8

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 900

Number of services: 17000

OS: RHEL 6.0

Plugin Version: 1.4.15

Other Addons: pnp4nagios, mod_gearman

3

Thursday, January 24th 2013, 5:23pm

ich brauche noch ein bisschen mehr Infos darüber:

wir definieren bei Hosts und Services custom variables in der config files.
ich frage nochmal wozu den Wert der custom variables ständig in der DB aktualisiert werden muss.
Der Wert ändern sich doch nicht ! Oder verstehe ich was nicht.

wenn ich ein Trace auf dem ido2db Prozess mache, bekomme ich ständig solche Statement die für mich keine Nutzung haben:

write(7, "\310\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='1174-41 1172-23' WHERE object_id=13918 AND varname='ANSPRECHPARTNER'", 204) = 204
write(7, "\315\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='rvGlobal Stralsund \\(4/4\\)' WHERE object_id=13918 AND varname='BEMERKUNG'", 209) = 209
write(7, "\265\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='St 0102' WHERE object_id=13918 AND varname='RAUM'", 185) = 185
write(7, "\271\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='B0094091' WHERE object_id=13918 AND varname='RACK-NR'", 189) = 189
write(7, "\300\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='-11 - -10' WHERE object_id=13918 AND varname='RACK-POSITION'", 196) = 196
write(7, "\303\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='SunOS 5\\.10' WHERE object_id=13918 AND varname='BETRIEBSSYSTEM'", 199) = 199
write(7, "\264\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='YES' WHERE object_id=13918 AND varname='1162-21'", 184) = 184
write(7, "\264\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='YES' WHERE object_id=13918 AND varname='1172-23'", 184) = 184
write(7, "\264\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='YES' WHERE object_id=13918 AND varname='1172-28'", 184) = 184
write(7, "\264\0\0\0\3UPDATE icinga_customvariablestatus SET instance_id=1, status_update_time=FROM_UNIXTIME(1359042081), has_been_modified=0, varvalue='YES' WHERE object_id=13918 AND varname='1172-25'", 184) = 184

Es belastet enorm den ido2db Prozess.

Kann man dieses Verhalten im Code irgendwie auskommentieren ?
irgendwie wie :
ndoutils - escape custom values

dnsmichi

Super Moderator

Posts: 5,976

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

4

Thursday, January 24th 2013, 10:22pm

der angefuehrte ndo link mit dem patch ist schon in den idoutils drinnen, und ist lediglich eine code refaktorisierung, wo anhand dem table_idx 2 verschiedene tabellen beschickt werden. hat aber nichts mit der eigentlichen frage zu tun imho.

jeder host/service/contact hat custom vars zugeordnet, die zur core laufzeit via command pipe modifiziert werden koennen, zb CHANGE_CUSTOM_SVC_VAR
http://docs.icinga.org/latest/en/extcommands2.html

deswegen findet bei einem host/service/contact status update darin verschachtelt ein update der custom vars ebenso statt.

dass der core keine diffs macht/kennt, sondern immer alles rausschiesst, ist ein architektur problem, bekannt, und wird sich in 1.x nicht mehr aendern (ausser jemand sponsort mir die imho sinnfreie zeit dafuer).
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

ossmon

Beginner

Posts: 34

Location: Berlin

Number of monitoring servers: 1

Nagios Version: none

Icinga Version: 1.8

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 900

Number of services: 17000

OS: RHEL 6.0

Plugin Version: 1.4.15

Other Addons: pnp4nagios, mod_gearman

5

Friday, January 25th 2013, 8:07am

"dass der core keine diffs macht/kennt, sondern immer alles rausschiesst, ist ein architektur problem, bekannt, und wird sich in 1.x nicht mehr aendern (ausser jemand sponsort mir die imho sinnfreie zeit dafuer)."

Kann ich verstehen. Wird es in icinga 2.0 ein redesign geben ? Nur Änderungen sollten gespeichert werden.

dnsmichi

Super Moderator

Posts: 5,976

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

6

Friday, January 25th 2013, 9:45pm

verfolgt mich jeden tag. in code form gibts das in 2.x noch nicht. ist mir aber als issue zugeordnet afaik.
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++