WireGuard plugin

Ich versuche gerad das WireGuard Plugin zu aktivieren:

https://exchange.checkmk.com/p/wireguard

Installation und Agent-Deployment hat funktioniert. Der Agent liefert Output:

<<<wireguard:sep(9)>>>
[[wg0]]
......

Starte ich für den Host die Service-Discovery wird WireGuard aber nicht gefunden. Habe ich noch einen nötigen Config-Schritt übersehen?

Im Einsatz: 2.0.0p8 (CME)

Was passiert den bei einem Discovery für diesen Host mittels “cmk --debug -vvII hostname”?
Vielleicht kommt ja eine brauchbare Fehlermeldung.

Interessant …

$ cmk server
[agent] Version: 2.0.0p3, OS: linux, unexpected agent version 2.0.0p3 (should be 2.0.0p8)(!), execution  time 1.7 sec | execution_time=1.720 user_time=0.020 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=1.690

aber:

$ cmk --debug -vvII server
Hostname or tag specification 'server' does not match any host.
Traceback (most recent call last):
  File "/omd/sites/MHC/bin/cmk", line 92, in <module>
    exit_status = modes.call(mode_name, mode_args, opts, args)
  File "/omd/sites/MHC/lib/python3/cmk/base/modes/__init__.py", line 69, in call
    return handler(*handler_args)
  File "/omd/sites/MHC/lib/python3/cmk/base/modes/check_mk.py", line 1522, in mode_discover
    hostnames = modes.parse_hostname_list(args)
  File "/omd/sites/MHC/lib/python3/cmk/base/modes/__init__.py", line 160, in parse_hostname_list
    raise MKBailOut("Hostname or tag specification '%s' does "
cmk.utils.exceptions.MKBailOut: Hostname or tag specification 'server' does not match any host.

Es ist ein Host einer Remote-Site. Das Kommando habe ich auf den Master ausgeführt.

Naja das sollte dann auch auf der Remote Site ausgeführt werden halt dort wo der Host überwacht wird.

Aber Inventory über WATO am Master - logisch ist anders :slight_smile: also:

$ cmk --debug -II -vv  server
Discovering services and host labels on: server
server:
+ FETCHING DATA
  Source: SourceType.HOST/FetcherType.TCP
[cpu_tracking] Start [7fcfb81ac1f0]
Connecting via TCP to 127.0.0.1:6556 (5.0s timeout)
[TCPFetcher] Fetch with cache settings: DefaultAgentFileCache(base_path=PosixPath('/omd/sites/site/tmp/check_mk/cache/server'), max_age=MaxAge(checking=0, discovery=120, inventory=120), disabled=False, use_outdated=False, simulation=False)
Using data from cache file /omd/sites/site/tmp/check_mk/cache/server
Got 62587 bytes data from cache
[TCPFetcher] Use cached data
Closing TCP connection to 127.0.0.1:6556
[cpu_tracking] Stop [7fcfb81ac1f0 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.0))]
  Source: SourceType.HOST/FetcherType.PIGGYBACK
[cpu_tracking] Start [7fcfb81ac580]
No piggyback files for 'server'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[PiggybackFetcher] Fetch with cache settings: NoCache(base_path=PosixPath('/omd/sites/site/tmp/check_mk/data_source_cache/piggyback/server'), max_age=MaxAge(checking=0, discovery=120, inventory=120), disabled=False, use_outdated=False, simulation=False)
[PiggybackFetcher] Execute data source
[cpu_tracking] Stop [7fcfb81ac580 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.0))]
+ PARSE FETCHER RESULTS
  Source: SourceType.HOST/FetcherType.TCP
Loading autochecks from /omd/sites/site/var/check_mk/autochecks/server.mk
Trying to acquire lock on /omd/sites/site/var/check_mk/persisted/server
Got lock on /omd/sites/site/var/check_mk/persisted/server
Releasing lock on /omd/sites/site/var/check_mk/persisted/server
Released lock on /omd/sites/site/var/check_mk/persisted/server
Stored persisted sections: lnx_packages, lnx_distro, lnx_cpuinfo, dmidecode, lnx_uname, lnx_ip_r, lnx_sysctl, lnx_block_devices
Using persisted section SectionName('lnx_packages')
Using persisted section SectionName('lnx_distro')
Using persisted section SectionName('lnx_cpuinfo')
Using persisted section SectionName('dmidecode')
Using persisted section SectionName('lnx_uname')
Using persisted section SectionName('lnx_ip_r')
Using persisted section SectionName('lnx_sysctl')
Using persisted section SectionName('lnx_block_devices')
  -> Add sections: ['apt', 'check_mk', 'chrony', 'cifsmounts', 'cmk_site_statistics', 'cpu', 'df', 'diskstat', 'dmidecode', 'job', 'kernel', 'labels', 'livestatus_ssl_certs', 'livestatus_status', 'lnx_block_devices', 'lnx_cpuinfo', 'lnx_distro', 'lnx_if', 'lnx_ip_r', 'lnx_packages', 'lnx_sysctl', 'lnx_uname', 'local', 'logwatch', 'md', 'mem', 'mkeventd_status', 'mknotifyd', 'mounts', 'nfsmounts', 'omd_apache', 'omd_info', 'omd_status', 'ps_lnx', 'systemd_units', 'tcp_conn_stats', 'uptime', 'vbox_guest', 'wireguard']
  Source: SourceType.HOST/FetcherType.PIGGYBACK
No persisted sections loaded
  -> Add sections: []
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
Trying host label discovery with: apt, check_mk, chrony, cifsmounts, cmk_site_statistics, cpu, df, diskstat, dmidecode, job, kernel, labels, livestatus_ssl_certs, livestatus_status, lnx_block_devices, lnx_cpuinfo, lnx_distro, lnx_if, lnx_ip_r, lnx_packages, lnx_sysctl, lnx_uname, local, logwatch, md, mem, mkeventd_status, mknotifyd, mounts, nfsmounts, omd_apache, omd_info, omd_status, ps_lnx, systemd_units, tcp_conn_stats, uptime, vbox_guest, wireguard
  cmk/os_family: linux (check_mk)
  cmk/device_type: vm (labels)
  cmk/check_mk_server: yes (omd_info)
+ PERFORM HOST LABEL DISCOVERY
Trying to acquire lock on /omd/sites/site/var/check_mk/discovered_host_labels/server.mk
Got lock on /omd/sites/site/var/check_mk/discovered_host_labels/server.mk
Releasing lock on /omd/sites/site/var/check_mk/discovered_host_labels/server.mk
Released lock on /omd/sites/site/var/check_mk/discovered_host_labels/server.mk
+ EXECUTING DISCOVERY PLUGINS (41)
  Trying discovery with: mkeventd_status, mounts, omd_apache, check_mk_only_from, domino_tasks, livestatus_status, omd_status, cpu_loads, systemd_units_services_summary, logwatch_ec_single, kernel_performance, mknotifyd, mknotifyd_connection, local, job, mem_win, nfsmounts, mem_vmalloc, cpu_threads, vbox_guest, md, kernel_util, mem_linux, logwatch_ec, check_mk_agent_update, cifsmounts, tcp_conn_stats, docker_container_status_uptime, logwatch_groups, k8s_stats_network, kernel, logwatch, df, uptime, cmk_site_statistics, lnx_if, chrony, apt, systemd_units_services, ps, diskstat
Trying to acquire lock on /omd/sites/site/var/check_mk/autochecks/server.mk
Got lock on /omd/sites/site/var/check_mk/autochecks/server.mk
Releasing lock on /omd/sites/site/var/check_mk/autochecks/server.mk
Released lock on /omd/sites/site/var/check_mk/autochecks/server.mk
  1 apt
  1 check_mk_agent_update
  1 chrony
  1 cmk_site_statistics
  1 cpu_loads
  1 cpu_threads
  1 df
  1 diskstat
  1 kernel_performance
  1 kernel_util
  1 livestatus_status
  3 lnx_if
  4 logwatch
  1 mem_linux
  1 mkeventd_status
  1 mknotifyd
  1 mounts
  1 omd_apache
  1 omd_status
  1 ps
  1 systemd_units_services_summary
  1 tcp_conn_stats
  1 uptime
SUCCESS - Found 28 services, 3 host labels

Auch ohne Cache-File bleibt das Ergebnis das selbe.

Ich habe nach dem Output das mal ein wenig umgebaut und mit einem Label versehen. Jetzt geht das. Allerdings gibt es jetzt ein neues Problemchen.

Traceback (most recent call last):
  File "/omd/sites/site/bin/cmk", line 98, in <module>
    exit_status = modes.call("--check", None, opts, args)
  File "/omd/sites/site/lib/python3/cmk/base/modes/__init__.py", line 69, in call
    return handler(*handler_args)
  File "/omd/sites/site/lib/python3/cmk/base/modes/check_mk.py", line 1631, in mode_check
    return checking.do_check(
  File "/omd/sites/site/lib/python3/cmk/base/decorator.py", line 37, in wrapped_check_func
    status, infotexts, long_infotexts, perfdata = check_func(hostname, *args, **kwargs)
  File "/omd/sites/site/lib/python3/cmk/base/checking.py", line 213, in do_check
    num_success, plugins_missing_data = _do_all_checks_on_host(
  File "/omd/sites/site/lib/python3/cmk/base/checking.py", line 344, in _do_all_checks_on_host
    success = execute_check(
  File "/omd/sites/site/lib/python3/cmk/base/checking.py", line 487, in execute_check
    submit, data_received, result = get_aggregated_result(
  File "/omd/sites/site/lib/python3/cmk/base/checking.py", line 582, in get_aggregated_result
    result = _aggregate_results(check_function(**kwargs))
  File "/omd/sites/site/lib/python3/cmk/base/checking.py", line 813, in _aggregate_results
    perfdata, results = _consume_and_dispatch_result_types(subresults)
  File "/omd/sites/site/lib/python3/cmk/base/checking.py", line 857, in _consume_and_dispatch_result_types
    for subr in subresults:
  File "/omd/sites/site/lib/python3/cmk/base/api/agent_based/register/check_plugins.py", line 89, in filtered_generator
    for element in generator(*args, **kwargs):
  File "/omd/sites/site/local/lib/python3/cmk/base/plugins/agent_based/wireguard.py", line 109, in check_wireguard
    for peer, data in peers.iteritems():
AttributeError: 'dict' object has no attribute 'iteritems'

Scheint ein Bug zu sein …

Alle Command Line Tests müssen auf der Remote Instanz durchgeführt werden sonst nirgendwo.

Also bitte einfach mal auf der Remote Instanz ein “cmk --debug -vvII hostname” machen.
Wird hier was gefunden vom Wireguard oder nicht?
Achtung da es eine verteilte Installation ist gehe ich davon aus, dass das installierte Wireguard MKP auch schon auf alle Slave Instanzen verteilt ist.

Zu der Fehlermeldung bräuchte man noch den Agent Output. Da hier scheinbar beim parsen was nicht funktioniert.

Ist der Fall

Ist klar ein Problem beim Parsen:

<<<wireguard:sep(9)>>>
[[wg0]]
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=    1.2.3.4:50379      10.252.1.1/32   1626890613      750168  243364  off
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb=    5.6.7.8:52683      10.252.1.2/32   1626890551      7903116 1048136 off
ccccccccccccccccccccccccccccccccccccccccccc=    (none)  10.252.1.3/32   0       0       0       off
ddddddddddddddddddddddddddddddddddddddddddd=    (none)  10.252.1.4/32   0       0       0       off
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee=    (none)  10.252.1.5/32   0       0       0       off
fffffffffffffffffffffffffffffffffffffffffff=    (none)  10.252.1.6/32   0       0       0       off

Heisst: zwei Peers mit aktiver Verbindung und vier ohne.

Ok - ändere mal im Plugin die Zeile 109 von

for peer, data in peers.iteritems():

nach

for peer, data in peers.items():

wenn es dann funktioniert kannst ja auch gleich auf Github noch nen Bugreport machen.

Da ist tatsächlich noch ein iteritems() drin, sowas.

Danke, das hat das Problem gelöst, aber :slight_smile:

Im Inventory taucht das jetzt alles auf und ist grün, allerdings wird es nicht in den Host mit übernommen. Die Wireguard-Services werden also nicht überwacht.

EDIT: Ich hab jetzt einfach mal einen der Services auf “undecided” gesetzt und wieder zurück. Damit waren dann Änderungen da. Nach dem ich die comitted hatte war das Problem weg und die neuen Services so wie sein sollen.

1 Like

Wie ist das mit dem Deployment. Obwohl alles fehlerfrei installiert wurde und der Agent Daten liefert wird WireGuard im Service-Scan nicht gefunden. Erst als ich alles mit Lables versehen hatte ging es. Warum ist das so? “Früher” ™ war das mal bei anderen Plugins anders :slight_smile:

Was wurde wie mit Labeln versehen?

Ich habe die Korrektor mit items() in wireguard-1.3.mkp eingearbeitet. Mit den Agentendaten von oben erhalte ich ohne Probleme die passende Anzahl von Service Checks:

Es werden hier 0 aktive Peers angezeigt, weil es laut Wireguard-Dokumentation einen Timeout von 300s für den Wert “latest-handshake” gibt.

Das Plugin:

image

Und der Host. Erst dann wurde der Service bei der Discovery erkannt.

Ach so, in der Regel für die Agentenbäckerei. Naja, irgendwie muss das Agentenplugin ja auf die passenden Hosts verteilt werden.

Anders :slight_smile:

Ursprünglich hatte ich in der Agent-Deployment-Rule unter Explicite-Hosts die Hosts eingetragen. Damit wurde der Agent mit dem Plugin versorgt und die Daten kamen auch vom Agent. Dann habe ich versucht per Discovery im Host die WG-Services hinzuzufügen. Dort sind sie aber nicht aufgetaucht.

Dann habe ich die Rule und die Hosts mit Labels versorgt und dann ging alles. Das mit den Labels ist so wie so besser, aber die “alte Methode” funktioniert halt aus Gründen nicht.

Das hat dann aber nichts mit der Erweiterung zu tun.

Glaube ich auch, dennoch hatte ich so etwas noch nie, besser gesagt: so etwas ist mir noch nie aufgefallen. Egal, mit Label geht es ja.

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.