Guten morgen,

ich glaube ich habe einen Bug beim Import der Service Dependencies entdeckt. Oder das soll natürlich so sein

Wir arbeiten bei uns sehr viel mit Service Dependencies. So hat jeder Host bei uns um die 20-30 Dependencies. Wenn ich das ganze jetzt importieren möchte importiert der zu jedem Host immer nur eine. Also nie alle.
Ich habe den import schon nach mehreren Varianten probiert.
1. Jede Dependencie einzeln
Bsp:
define servicedependency {
host_name belinda
service_description Snmp Daemon
dependent_host_name belinda
dependent_service_description /boot FS
inherits_parent 0
notification_failure_options u,c,p
execution_failure_options u,c,p
}
define servicedependency {
host_name belinda
service_description Snmp Daemon
dependent_host_name belinda
dependent_service_description / FS
inherits_parent 0
notification_failure_options u,c,p
execution_failure_options u,c,p
}


usw... wenn ich nur die beiden importiere, übernimmt der nur den letzten (Häckchen zum überschreiben gesetzt). Nehme ich das Häckchen zum überschreiben in DB raus nimmt er nur den ersten. Dabei ist es ihm auch egal ob die beiden in einer .cfg stehen oder in zwei verschiedenen.

2. Variante
abhängige Dependencies zusammengefasst

define servicedependency {
host_name belinda
service_description Snmp Daemon
dependent_host_name belinda
dependent_service_description / FS, /boot FS, CPU Fan, CPU Load, CPU State, CPU Temperature, Case fan, IP Traffic, Logical drive condition, Logical drive state, NRPE, Physical drive condition, Physical drive state, RAID controler condition, RAID ctrl board status, SMART drive state, SME Server, Server Temperature, TSM Client, TSM Console, Thermal condition, VNC Server, dump FS, home FS, interfaces FS, itacmessuite FS, lenze_data FS, logfiles FS, opt FS, oracle FS, oracle/dump FS, oracle/product FS, server FS, sme FS, tmp FS, transfer FS, usr FS, var FS
inherits_parent 0
notification_failure_options u,c,p
execution_failure_options u,c,p
}
define servicedependency {
host_name belinda
service_description SME Server
dependent_host_name belinda
dependent_service_description ERP Server, MAT Server, NameServer, OPM Server, QM Server, RM Admin Server, RecipeApi Server, ServletRunner Process
inherits_parent 0
notification_failure_options u,c,p
execution_failure_options u,c,p
}

Wenn ich das so importiere nimmt er auch wieder nur einen. ( jenachdem ob das Häckchen gesetzt ist zum überschreiben)
Ich hätte eigentlich erwartet, dass es so funktioniert denn wenn ich die Konfig von NagiosQL schreiben lasse gruppiert er das auch so.

Achja und wenn ich einen importiere und den zweiten per Hand über NagiosQL anlege zeigt er mir auch beide an, sofern ich den Konfigurationsnamen unterschiedliche wähle. Ich vermute mal das ein Unique auf den Konfigurationsnamen in der DB gesetzt ist und daher nicht mehrfach z.B. Belinda da auftauchen darf.
In meinen Dependencies config wähle ich jedoch gar keinen Konfigurations namen und er nimmt automatisch immer den Hostname. Wenn der Unique Constraint von der entsprechenden Spalte entfernt wird sollte das ganze funktionieren. Oder aber der Konfigurationsname wird ein zusammengesetzter Name aus host_name und service_description.

Jetzt stellt sich mir gerade nur die Frage ist das ganze von euch so gewollt oder ist das nur noch nie jemanden aufgefallen?
Achja und warum sind bei euch eigentlich Hostgroup und abhängige Hostgroups Pflichtfelder? Denn nicht jeder Host gehört bei uns immer zu einer Hostgroup, ist laut Nagios auch keine Pflicht.

Das solls erstmal gewesen sein. Ich hoffe ihr könnt damit was anfangen und mir helfen.


Gruß Nico

Das liegt daran, wie NagiosQL bei einem zu importierenden Block herauszufinden versucht, ob dieser schon exisiert oder nicht um doppelte Daten zu verhindern.

Aktuell ist diese bei Servicedependencies noch sehr ungenau, es wird lediglich in der DB gesucht nach Übereinstimmungen des dependent_host oder der dependent_hostgroup. Exisiert eine solche schon, wird der Block nicht importiert. D.H es kann nur eine einzige Konfiguration mit dem dependent_host "belinda" importiert werden.

Das ist in der Tat nicht optimal, aber da kaum jemand Servicedependendies benutzt (zumindest nicht importiert) hat dies wohl auch noch nie jemand bemängelt

Wir werden uns generell eine neue Technologie für den Import suchen müssen, da es immer Spezialfälle geben wird. Der im Moment angedachte Weg ist ein zusätzliches Tabellenfeld (import_hash) welches einen hash der "Textsumme" aller relevanten Felder enthält. Wir würden also wert = md5(host.dependent_host.hostgroup.dependent_hostgroup.service_description.dependent_service_description) da reinspeichern. Allerdings müsste dieser Wert ständig aktuell gehalten werden oder vor jedem Import ein "rehash-lauf" über die gesamte DB erfolgen, damit der Wert beim Import auch aktuell ist

Ganz Trivial ist die Änderung also nicht und wird somit erst bei 3.1.x enthalten sein.

Hostgroup und abhängige Hostgruppe sind nur Pflichtfelder, wenn Host oder abhängiger Host leer ist - dies ist aber beim Hilfepunkt "?" noch genau erklärt.