Eigenes Plugin wird aus dem Verzeichnis gelöscht

Global Community Deutsch
1

Hallo liebe Community,
ich kämpfe aktuell mit einem seltsamen Phänomen und bin mit meinen Ideen am Ende.

Wenn ich einen selbst erstellten Service in das Monitoring mit aufnehmen möchte und hierzu in der Service Configuration auf das + klicke, listet mir Checkmk den Service im Bereich Vanished services auf.
Der Grund hierzu ist auch schnell gefunden: das erstelle Plugin ist aus dem Verzeichnis gelöscht worden.

Füge ich das Plugin wieder hinzu, erkennt Checkmk den Service wieder und dieser wird mir auch auf der Oberfläche angezeigt.
Sobald ich jedoch diesen Service anpasse (bspw. um ihn zu den Disabled services zu verschieben), wird das Plugin wieder gelöscht.

In den Logs (/omd/sites/mySite/var/log) habe ich leider keine Hinweise finden können und auch die Periodic services discovery Rule kann es nicht sein. Der Mode steht hier auf “Add unmonitored services, new host labels”.

Hat jemand hier eine Idee was der Grund für die Löschung des Plugins sein kann?

Hier einmal der Aufbau des Plugins:

Agent
Inhaber des Skripts: root
Pfad des Skripts: /usr/lib/check_mk_agent/plugins/test_three_values
Ausgabe:

<<<test_three_values>>>
400 184 46.00

Instanz
Inhaber des Plugin: mySite
Berechtigung für das Plugin: rw- rw- r- -
Pfad des Plugin: /omd/sites/mySite/local/lib/check_mk/base/plugins/agent_based/test_three_values.py
Inhalt:

from .agent_based_api.v1 import Service, Result, State, register, Metric

def discover_three_values(section):
    yield Service()

def check_three_values(section):
    limit = int(section[0][0])
    usage = int(section[0][1])
    pct = float(section[0][2])

    level_warn = 80
    level_crit = 90

    if pct < level_warn:
        s = State.OK
    elif pct >= level_warn and pct < level_crit:
        s = State.WARN
    else:
        s = State.CRIT

    yield Metric("test_three_values", pct, levels = (level_warn, level_crit), boundaries = (0, 100))

    yield Result(state = s, summary = "Some text", details = "Some details")

register.check_plugin(
    name = "test_three_values",
    service_name = "_Test Three Values",
    discovery_function = discover_three_values,
    check_function = check_three_values
)
2

Ich glaube, du musst dein plugin einfach ins Dir /usr/lib/check_mk_agent/local legen, oder nicht?

3

Hast Du automatische Agenten-Updates aktiviert?

1 Like
4

In dem Pfad liegen doch die lokale Checks.

Die von mir genannten Pfade habe ich aus der Dokumentation für ein “echtes” Checkmk-Plugin übernommen. Daher sollten diese doch auch passen oder?

5

Ja, das automatische Agenten-Update ist aktiviert.

6

Standardverhalten beim Update des Agentenpaketes ist, nur /var/lib/check_mk_agent abzuräumen. Das bedeutet nicht, dass ein Plugin per Bakery-API manuell installierte Plugins abräumt.

Ich würde an dieser Stelle für den Testhost entweder das Agenten-Update deaktivieren oder gleich das Ausrollen mit dem Bakery vornehmen (siehe “Hello Bakery” in der Exchange.

7

Ich bin noch recht neu in Checkmk aber selbst geschriebene Plugins können doch nicht mit der Bakery ausgerollt werden oder irre ich mich? Damit können doch lediglich von Checkmk mitgeliefert Plugins geliefert werden.

8

Auf mich wirkt das Verhalten von Checkmk so, als ob eine Prüfung bei der Python-Datei vorgenommen wird.

Muss hier auf etwas bestimmtes geachtet werden wie bestimmte Berechtigungen oder Besitzer?
Der Pfad scheint laut Dokumentation ja zu stimmen. Ein expliziter Besitzer der Datei wurde zwar nicht angegeben. Ich habe daher den Instanzbenutzer verwendet.

9

Hi @p4rad0xus,

das klingt tatsächlich ungewöhnlich.

Nur zur Klarstellung: was genau meinst du mit " das erstelle Plugin ist aus dem Verzeichnis gelöscht worden."

Meinst du, dass eine Datei aus einem Verzeichnis verschwindet oder der Service in der Service Übersicht auf “vanished” geht?
Das Agentseitige Plugin /usr/lib/check_mk_agent/plugins/test_Plugin? (der Pfad ist soweit richtig.

wäre sehr ungewöhnlich - rpm/deb Paketmanager löschen ja normal keine Dateien, die sie nicht auch selbst platziert haben, vor allem würde der Paketmanager ja nur aktiv werden, wenn du überhaupt neue Agenten in der Bakery bäckst)

Das Plugin im Checkmk Server? /omd/sites/mySite/local/lib/check_mk/base/plugins/agent_based/test_Plugin.py? Pfad auch richtig, gefühlt das einzige Checkplugin das auch Großbuchstaben im Namen verwendet, aber das dürfte kaum relevant sein, so oder so, hab ich noch nicht erlebt, dass Checkmk hier Dateien löscht.

Was mich noch wundert, du nutzt als service_name einen String der mit “_” startet - ist das Absicht?

Der Name der Funktion “check_Plugin” ist vllt etwas unglücklich, da nur das P vs. p es von der Checkmk eingebauten “register.check_plugin” funktion unterscheidet, aber denke auch das müsste Python abkönnen.

10

Doch, seit 2.0.0 geht das offiziell:

11

Per Bakery API können prerm-Schnippsel mitgegeben werden. Es kann ohne exakt die ausgelieferten Plugins zu kennen, also zumindest nicht ausgeschlossen werden, dass es ein Plugin beim Aufräumen zu gut meint.

12

Das klingt wie “gut gemeint” :slight_smile:

gibt es auch standard Plugins von t29, die das machen, oder gibt es nur die Möglichkeit? Gefühlt könnte das zu sehr schwierigem Troubleshooting führen :D.

13

Es ist von unserer Seite nicht vorgesehen, übergründlich aufzuräumen… Und ja, Troubleshooting ist derzeit nicht einfach, da alle postinst/prerm Snippets in einer Datei landen. Ein zu gut gemeintes exit 0 und alles, was folgt, fällt hinten runter.

Wir arbeiten dran, versprochen.

1 Like
14

Danke Euch beiden für die bisherige Hilfe!

Auf der Monitoring-Instanz habe ich soeben mal nach den Konfigurationen in der Agent Bakery gesehen.
Hier wurde eine Konfiguration für die Monitoring-Instanz hinterlegt. In den Einstellungen selbst konnte ich allerdings keinen Anhaltspunkt für mein Problem feststellen.
Außerdem habe ich die angegebenen Pfade aus der Dokumentation zur Bakery-API kontrolliert.

local/lib/check_mk/base/cee/plugins/bakery/ existiert nur bis base. Daher könnte es doch nicht zu einem zu gut gemeinten Aufräumen durch ein postinst/prerm Snippet kommen - richtig?

Ich meine hiermit, dass sobald ich den Service in der Service Übersicht ändere, die Python-Datei im Verzeichnis local/lib/check_mk/base/plugins/agent_based/ verschwindet bzw. gelöscht wird.
Der betroffene Service in der Übersicht wird daraufhin auf “vanished” gesetzt.

Mit dem Agentseitigen Plugin unter /usr/lib/check_mk_agent/plugins/ geschieht nichts. Hier passieren keine Änderungen.

Der “_” am Anfang des service_name ist Absicht. So wird mir der Service in der Übersicht ganz oben dargestellt.

Hier wollte ich wohl zu sehr Text im Beispielcode sparen - bitte entschuldigt. Der Funktionsname ist in echt länger. Ich habe dies in meinem Post angepasst.

Kann es Eurer Meinung nach vielleicht eine Misskonfiguration in der Checkmk-Instanz geben, was zu der Löschung führen kann?

15

Welche Checkmk-Version nutzt Du? 2.1.0p21 oder höher? Ich habe da einen Verdacht bzgl. des neuen MKP Managements. Packe mal alle Dateien, die zu dem Plugin gehören in ein MKP und inkrementiere die Versionsnummer nach jeder Änderung.

Das steht ab heute Nacht im MKPs Artikel im master:

Tipp: Verwenden Sie zur Arbeit an MKPs (Anpassung/Erstellung) eine Test-Site und kopieren Sie die MKPs fürs Deployment auf die produktiv genutzte Site! Dies wird Ihnen vor allem zwei potentielle Probleme ersparen, die dadurch entstehen, wenn geänderte Dateien nicht rechtzeitig zu MKPs gepackt werden:

  1. Beim Checkmk-Update werden lokal geänderte Dateien durch den letzten Stand des MKPs überschrieben (dem Autor dieses Satzes ist genau dies passiert).
  2. Im verteilten Setup wundern Sie sich, weil sich Plugins auf Remote Sites anders verhalten als auf der Central Site, denn die Remote Sites erhalten weiterhin den zuletzt gepackten Stand.
1 Like
16

Derzeit wird die Version 2.0.0p26 verwendet.

Die Idee mit den MKP klingt sehr spannend. Bei dem Test habe ich gesehen, dass zwei Packete auch derzeit verwendet werden: dell_idrac_redfish v1.1, dell_powervault_me4 v2.5 und emcunity v3.2.

Das MKP habe ich über das CLI-Tool “mkp” erstellen müssen. Die Oberfläche der Instanz steht mir nicht direkt zur Verfügung, sondern ist als Host mit der Einstellung “Monitored on site” in einer anderen Instanz eingebunden.

Folgendes MKP-Skript habe ich erstellt:

{'author': 'Add your name here',
 'description': 'Please add a description here',
 'download_url': 'http://example.com/test_package/',
 'files': {'agent_based': ['test_three_values.py'],
            'agents': [],
            'alert_handlers': [],
            'bin': [],
            'checkman': [],
            'checks': [],
            'doc': [],
            'inventory': [],
            'lib': [],
            'locales': [],
            'mibs': [],
            'notifications': [],
            'pnp-templates': [],
            'web': [],
 'name': 'test_package',
 'title': 'Title of test_package',
 'version': '1.0',
 'version.main_required': '2.0.0p26',
 'version.packaged': '2.0.0p26',
 'version.usable_until': None}

Nachdem ich den Service in der Übersicht wieder geändert habe, war allerdings die Python-Datei wieder aus dem Verzeichnis verschwunden. Die Dateien der anderen beiden MKP’s sind jedoch schon immer vorhanden geblieben.
Auch wenn ich anschließend das erstellte MKP nochmals installiere, verschwindet die Datei wieder aus dem Verzeichnis.

Ebenfalls verschwindet das MKP-Skript jedesmal aus dem Verzeichnis var/check_mk/packages/.
Die erstelle MKP-Datei hatte ich noch nach /tmp/ gesichert, dadurch wurde sie nicht gelöscht.

17

Danke! Ich habe in den letzten Wochen einiges am neuen MKP Management ausprobiert, dokumentiert und einige Male bei den Kollegen der Entwicklung nachgehakt. Und ich arbeite an einem Blog-Artikel zu dem Thema. Meine primäre Testumgebung ist allerdings eine 2.2.0 Beta. Ich versuche morgen mal, das Problem auf einer frischen 2.1.0p26 nachzustellen und werde ggf. direkt ein Bug-Ticket einreichen.

Warte mal, das ist ein Distributed Setup, und Du arbeitest auf einer der Remote Sites? Dann ist das wahrscheinlich erwartetes Verhalten, das wir noch nicht dokumentiert haben: Hier gilt die Central Site als Single Source of Truth. :see_no_evil:

1 Like
18

@mschlenker @p4rad0xus benutzt 2.0.0p26, nicht 2.1.0p26

19

Präzisierung aus Transparenzgründen nach interner Klärung: Synchronisation von Erweiterungen bedeutete schon immer, dass auf Remote Sites exakt das vorhanden ist, was auf der Central da ist. Das impliziert Löschung von Dingen, die auf der Central Site nicht vorhanden sind.

Falls es einmal funktioniert haben sollte, in solch einem Setup auf einer Remote Site Plugins zu entwickeln, die nicht zeitnah gelöscht wurden, war das ein Bug und so nie vorgesehen.

Jetzt, da die Verteilung über MKPs und nicht Einzeldateien funktioniert, gilt umso mehr: Bitte auf einer Testinstanz entwickeln und dann in die Produktivinstanz deployen.

5 Likes
20

Vielen Dank für die umfangreiche Hilfe und das Nachfragen!
Ich werde das schnellstmöglich Nachtesten und eine Rückmeldung geben.

1 Like