Checkmk 2 - Bestehende Agenten Section für weitern check anzapfen

[asthor (Gino Elflein)]

Hallo Checkmk-Freunde,

ich würde gerne auf Windows-Hosts die Agent Section <<< mem>>> für einen weiteren eigenen Check mit benutzen.

Laut der CheckAPI Docu muss der name im Checkplugin der Agent Section entsprechen.

Hier mein Beispiel-Code mit dem ich dies versucht habe:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

from .agent_based_api.v1 import *

def discover_mem_physical(section):
    yield Service()


def check_mem_physical(section):
    print(section)

    yield Result(state=State.OK, summary=f"Memory physical {section}")


register.check_plugin(
    name="mem",
    service_name="Memory physical",
    discovery_function=discover_mem_physical,
    check_function=check_mem_physical,
)

Leider wird kein neuer Service erzeugt.

Habt ihr eine Idee, wie ich die bestehende Agent Section anzapfen kann?

Gruß
Gino

[r.sander (Robert Sander)]

Nicht ganz. Dein Check sollte schon einen eigenständigen, eindeutigen Namen haben.

register.check_plugin() hat für Deinen Zweck noch den Parameter sections, mit dem eine Liste von Daten-Sektionen übergeben werden können, wenn der Checkname nicht der Sektionsname ist.

Also in etwa so:

register.check_plugin(
    name="dein_check_name",
    sections=["mem"],
    …
)

[tosch (Tobias Schönau)]

Hallo @r.sander,

kurze Frage dazu. Gibt es diese Möglichkeit in der alten API auch? Stehe auch an so einer ähnlichen Stelle aktuell.

[r.sander (Robert Sander)]

In der alten Check-API von checkmk 1.6 musste ein Subcheck gebaut werden, also in dem Fall mem.dein_check_name. Dieser hat dann auch die Daten erhalten.
Der Subcheck musste aber in der gleichen Datei implementiert werden, sonst hatte zumindest die Raw-Edition ein Problem.

[Dirk]

@tosch

Gibt es diese Möglichkeit in der alten API auch?

@r.sander

In der alten Check-API von checkmk 1.6 musste ein Subcheck gebaut werden

Das ist nicht ganz richtig. Bei checkmk 1.6 gibt es den Parameter extra_sections:

check_info['this_check'] = {
    'check_function':      check_this_check,
    'inventory_function':  inventory_this_check,
    'parse_function':      parse_this_check,
    'service_description': 'This check',
    'extra_sections':      ['that_check', 'other_check'],
}

Wenn du einen Check so definierst, dann wird die check-Funktion nicht nur mit dem Rückgabewert der (eigenen) parse-Funktion aufgerufen, sondern mit einem Tupel von Rückgabewerten der beteiligten Parse-Funktionen:

def check_this_check(item, params, parsed):

    parsed_this, parsed_that, parsed_other = parsed

    if not parsed_this:
        return None
        
    ...

Die Inventory-Funktion wird ebenfalls mit einem Tupel aufgerufen und sollte dann nur parsed[0] (also die eigenen Daten) bearbeiten.

Wie sich das ganze verhält, wenn die “extra-Checks” keine Parse-Funktion haben bzw. allgemein im “Mischbetrieb”, weiß ich leider nicht mehr. Ich habe dieses Verfahren bisher nur für eigene Checks verwendet, und die haben alle immer eine Parse-Funktion.

Könnte aber gut sein, dass die Check-Funktion dann mit sowas wie (parsed_this, info_that, info_other) aufgerufen wird, d.h. “gemischten” Parametern. Das musst Du im Zweifel ausprobieren oder im checkmk-Code nachgucken.

[andreas-doehler (Andreas)]

Würde aktuell eh nix mehr für 1.6 neu erstellen
Die “.” Checks nach 2.0 migrieren ist schon anstrengend genug.