Posts by TheLucKy

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.

    Da müssen doch schon mal mehr Leute drüber gestolpert sein.

    In der Tat, wurde jedoch nie gelöst.


    Jetzt würde ich natürlich gerne diesen Workaround einpflegen:

    Das musst du wohl in eine der Dateien aus dem traceback reinschmeißen. Möglicherweise die erste. die aufgerufen wird:


    /omd/sites/xxx_monitoring/bin/mkeventd

    Da steht Code
    ScriptStatistics: Plugin C:0 E:0 T:0 Local C:0 E:0 T:0

    Ok, also erkennt der Agent noch nicht einmal, dass ein Skript im local Ordner liegt. C: müsste eigentlich die Anzahl der Skripte im local dir wiedergeben.

    Es gab mal ein Werk, der win Problem mit der Ausführung von plugins und local checks gefixt hat. Lade dir mal bitte das aktuelle Source Pakte der cmk-raw-edition herunter, extrahiere den Windows-Agenten und installiere den Agenten auf dem betroffenen Host.

    Ich will nicht wissen, ob der entsprechende <<<local>>> output kommt, ich will wissen, was bei "ScriptStatistics" am Anfang agent output steht...

    Der einfachste Nachweis, ob ein Skript ausgeführt wird oder nicht, ist ein echo/print o.ä. an erster Stelle des Skripts.

    Sind die im cmk auch mit der selben "snmp config" angelegt? Also beide als SNMPv1 oder v2 Host?


    Ich hatte so ein Problem mal als ich versucht habe über snmpv1 einen testtrap an mein cmk zu schicken. Da es sich eigentlich um ein SNMPv2 "device" handelte, ist auch so ein ValueConstraintError aufgetaucht. Als ich dann snmpv2 für den Test nutzte war alles gut.


    Stell also sicher, dass Firewall und CMK von beiden Seiten her die selbe SNMP Version für diesen Host nutzen.

    Ruf mal den special agent direkt für einen Host auf, bei dem es richtig angezeigt wird und bei dem es falsch angezeigt wird:


    ~/share/check_mk/agents/special/agent_vsphere -u USER -s SECRET HOSTIP


    Da gibt es dann die Sektion esx_vsphere_datastores, die von Interesse wäre.

    Use omd backup instead to backup your whole site. Since you want to upgrade to cmk 1.4.0x (I assume from your last thread) you will not be able to restore from snapshots then anyways. This functionality is removed and got replaced by a different backup method in 1.4.0x.

    If anything goes wrong you can restore your old site via omd restore. Before upgrading you can also restore the backup to a new site first (I am not sure if omd cp copies the perfdata) to have the site running as a new instance while upgrading your original site to 1.4.0x.


    You wrote in your last thread you are running the enterprise edition. Don't you have any developer support then?

    Das bedeutet jetzt also bei rotated wird nicht für jedes Logfile (sagen wir wir haben 5 Logfiles der letzen 5 Tage in dem Verzeichnis) ein eigener Check angelegt UND ich muss nicht wenn ein neues dazu kommt (logischerweise dann mit anderem Namen da sich ja das Datum geändert hat) dieses manuell übers Inventory hinzufügen? Der Agent sieht dann also textfile-2012-12-13.log, textfile-2012-12-12.log, etc als ein Logfile wenn in der INI als textfile*.log angegeben ist?

    Ja genau. Aber hab ich selbst auch noch nicht im Einsatz gehabt. Hab es wie gesagt auch vorhin erst gelesen, dass das geht.

    Ist diese Funktion in check_mk 1.2.8p20 bzw. dessen Agent überhaupt vorhanden?

    Hab mal kurz in die Werks geschaut. Ist wohl erst ab Version 1.4.0x vorhanden. Kann aber sein, dass es ausreicht den Agenten auf dem Host auf 1.4.0x hochzuziehen. Habe hier auch einen 1.4.0p10er Agenten bei ner Server Version von 1.2.8p25.

    nd woher weiß der Agent das sich sich um ein neues File handelt?

    Er checkt die creation time nehme ich ganz stark an...



    Wie genau darf man sich die Funktionsweise der Option rotated vorstellen?

    Das ist halt für Logs in einem Verzeichnis die rotieren/jeden Tag neu erstellt werden. Der Agent liest das älteste bis zum Schluss und macht dann mit dem nächst jüngeren weiter. Z.Bsp:


    textfile = rotated C:\logs\LOG-*.log


    Heute: C:\logs\LOG-2017-12-13.log -> Der Agent liest diese Datei aus.

    Morgen: C:\logs\LOG-2017-12-14.log -> Der Agent liest LOG-2017-12-13.log bis zum Schluss und springt dann zu LOG-2017-12-14.log und ignoriert das ältere ab dem Zeitpunkt.


    Also ist rotated für dich sinnvoll.


    BTW, die ganzen Infos stehen bei mir nicht in der INI Datei Sonst hätte ich sie ja gelesen

    Naja das kam dann erst in einer späteren Version als die, die du auf deinem Host zu allererst installiert hattest, da steht es natürlich nicht in der check_mk.ini. Aber bei jeder Aktualisierung des Agenten wird auch die check_mk.example.ini neu erstellt, wo man mal reinschauen kann.

    Wird das state file dann entsprechend korrigiert bzw. angepast ans neue Logfile?

    Bei neuen files wird immer die last line gelesen. Da greift der logstate nicht mehr.

    Es gibt da aber auch noch die rotated Option habe ich grad gesehen, die eine Rotation von logfiles beachtet.

    Steht aber eigentlich alles im Infotext der check_mk.ini: