wir haben auf die p18 Version aktualisiert und danach keine Daten mehr aus dem vCenter erhalten. Nach einer Recherche auf der CLI, haben wir das Passwort als Fehlerquelle herausgefunden.
CLI: agent_vsphere: OK: Daten werden abgeholt
WATO: keine Daten: Service unknown
Das Passwort hatte ein “!” Ausrufezeichen. Nach der Änderung in einen “.” Punkt war es behoben.
kannst du via cmk -vv [--debug] <host> mal schauen, wie das Passwort an den special Agent übergeben wird? Wenn hier Anführungszeichen statt Hochkommata verwendet werden schlägt die Bash zu und versucht den String zu interpretieren.
bei dem Aufruf von cmk -vvv --debug --plugins agent_vsphere --no-cache vcenter.local.net
sollte eine Zeile in der Ausgabe erscheinen, wie Calling: /omd/sites/<site>/share/check_mk/agents/special/agent_vsphere '-u' '<user>' '-s=<secret>' '-i' 'licenses' '-P' '--spaces' 'underscore' '<host>'.
Diese ist interessant und die Frage ist, ob die Ausführung exakt dieser Zeile auch zum Fehler führt. Damit könnte man eingrenzen, an welcher Stelle der Fehler auftritt.
Ich habe leider keine Möglichkeit bei uns das Passwort zu ändern, sonst hätte ich es versucht nachzustellen.
OMD[SITE]:~$ cmk --debug --plugins agent_vsphere -vv --no-cache VCENTER
Checkmk version 2.0.0p18
Try license usage history update.
Trying to acquire lock on /omd/sites/SITE/var/check_mk/license_usage/next_run
Got lock on /omd/sites/SITE/var/check_mk/license_usage/next_run
Trying to acquire lock on /omd/sites/SITE/var/check_mk/license_usage/history.json
Got lock on /omd/sites/SITE/var/check_mk/license_usage/history.json
Next run time has not been reached yet. Abort.
Releasing lock on /omd/sites/SITE/var/check_mk/license_usage/history.json
Released lock on /omd/sites/SITE/var/check_mk/license_usage/history.json
Releasing lock on /omd/sites/SITE/var/check_mk/license_usage/next_run
Released lock on /omd/sites/SITE/var/check_mk/license_usage/next_run
+ FETCHING DATA
Source: SourceType.HOST/FetcherType.PIGGYBACK
[cpu_tracking] Start [7f01fc75b400]
No piggyback files for 'VCENTER'. Skip processing.
No piggyback files for '158.168.178.188'. Skip processing.
[PiggybackFetcher] Fetch with cache settings: NoCache(base_path=PosixPath('/omd/sites/SITE/tmp/check_mk/data_source_cache/piggyback/VCENTER'), max_age=MaxAge(checking=0, discovery=120, inventory=120), disabled=True, use_outdated=False, simulation=False)
Not using cache (Cache usage disabled)
[PiggybackFetcher] Execute data source
Not using cache (Cache usage disabled)
[cpu_tracking] Stop [7f01fc75b400 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.0))]
[cpu_tracking] Start [7f01fc81dc10]
+ PARSE FETCHER RESULTS
Source: SourceType.HOST/FetcherType.PIGGYBACK
No persisted sections loaded
-> Add sections: []
Received no piggyback data
Loading item states
Trying to acquire lock on /omd/sites/SITE/tmp/check_mk/counters/VCENTER
Got lock on /omd/sites/SITE/tmp/check_mk/counters/VCENTER
Releasing lock on /omd/sites/SITE/tmp/check_mk/counters/VCENTER
Released lock on /omd/sites/SITE/tmp/check_mk/counters/VCENTER
Saving item states
No piggyback files for 'VCENTER'. Skip processing.
No piggyback files for '158.168.178.188'. Skip processing.
[cpu_tracking] Stop [7f01fc81dc10 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.0))]
execution time 0.0 sec | execution_time=0.000 user_time=0.000 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.000
OMD[SITE]:~$
Ich weiß nicht, was in deiner Installation anders ist. Ich habe mir am Freitag extra eine neue p18 aufgebaut und unser vCenter dazu gepackt. Bei jeder Konstellation an command line Parametern für cmk bekomme ich die Ausgabe für den Aufruf des agent_vsphere.
Sicher, dass der Host VCENTER der ist, für den das vsphere-Plugin aktiv ist? Ich sehe in deiner Debug-Ausgabe nur die Verarbeitung für Piggy-Back-Daten.
am Freitag hatte ich die restlichen Instanzen von 2.0.0p17 auf 2.0.0p21 aktualisiert und dabei ist das Passwortproblem wieder aufgetreten. Nach dem erneuten Setzen des Passwortes im Wato konnte ich diesen Fehler beheben.
Es ist nachvollziehbar, dass beim Update >p17 der Passwortspeichermechanismus sich geändert hat und das bestehende Passwort nicht übernommen wurde.
Und dies unabhängig der vsphere_agent Konsolenausgabe.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.