Hypothese: Die Checks erzeugen keine Background-Jobs.
Die Discovery funktioniert bei uns:
-
Wenn was neues dazukommt, bleibt der Service auf OK, ein Rediscovery wird vorgemerkt, Rediscovery mit Neuaufnahme wird durchgeführt. Change wird automatisch übernommen. Service ist durchgehend auf OK. Es gibt dazu dann auch keine (neuen) Events. Das Intervall ist entweder 120 Minuten oder 24 Stunden.
-
Wenn ein Service verschwindet, geht der Check auf WARN bis jemand von Hand ein Discovery macht (wenn der neue Zustand korrekt ist). Hier gibt es einen Event wegen der Statusänderung.
Bei 80.000 Services mit monatlich konstantem Zuwachs vertraue ich dem Konzept schon ein Stück weit. Die “verlustigen” Services sind bislang auch alle nachvollziehbar und gewollt. Z.B. gezogene GBics an Switchen, entfernte Netzwerkkarten in VMs, gelöschte VMs auf vCentern). Und wenn neue VMs auf knapp 40 Instanzen von verschiedenen Kunden angelegt werden, werden die Services auch im Monitoring angelegt ohne händisches Zutun. Sonst hätten mich meine Kollegen schon irgendwo verscharrt. 
Zum Ablauf des Tests:
Wenn du den Check alle 3 Minuten ausführen lässt, musst du mindestens 6 Minuten warten. Für die Feststellung des Deltas sogar 9 Minuten. Hier kommt es nicht auf die Frequenz an, sondern auf die Anzahl an durchgeführten Checks und die muss hier 2 sein (erstes Feststellen + Rediscovery) bzw. 3 wenn die Änderung als Statuswechsel sichtbar werden soll.
Gruß
Stefan