Posts by smax

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.

    Offensichtlich: ja. Du kannst natürlich den Timeout-Wert höher setzen oder versuchen herauszufinden warum die Anwendung so lange benötigt zum reagieren und dies dann fixen.

    Selbst wenn die Eigenschaften der Ordner identisch sind, hast du ggf. unterschiedliche Regeln für die Ordner/Unterordner oder basierend auf Host-Tags oder Namen der Hosts? Das wäre jetzt mein Ansatz.

    Je nach Art der Switche werden bei uns auch per Ruleset definiert andere Interface per Discovery gefunden. Bei einem FC Switch interessieren mich z.B. nicht die bzw das eine ethernet Interface und bei einem Netzwerk-Switch brauch er nicht nach FC Interface suchen.

    Writing all the performance data for nice graphing kills every sd card and utilizes the cpu. If you just want to do some simple checks -> a raspberry pi could fit but I would take backups just in case.

    Otherwise: Your business and your company relies on your infrastructure and you are going to save up on the monitoring? If you can live with this multiple single points of failure (e.g. power unit or disk) you can use an Intel NUC or something. Performance will be enough for 50 services/checks.

    Login to your linux monitoring server where omd is installed. Change your user to the user the omd site is running. Normally the username is the same as the site name. If you are not sure, type in: "omd sites"

    Then you have the name of the site. With the command "su $sitename" you switch to the correct user. Replace $sitename with current name of course.

    Then you can execute the cmd commands

    Zum einen muss dafür afaik die Regel "Network Interface and Switch Port Discovery" dahingehend konfiguriert sein, dass auch Interfaces vom Typ "56 - fibreChannel" gefunden werden und dann gibt es noch je Regeln für "Fibrechannel Interfaces" bzw. "FibreChannel Ports (FCMGMT MIB)" abhängig davon was du hast und brauchst.

    Setzt aber voraus, dass der Agent auf den ESX Hosts die HBAs sauber erkennt und/oder du die Hosts per SNMP abfragen kannst.

    Basics: https://en.wikipedia.org/wiki/…twork_Management_Protocol

    What SNMP is and how it works is well known documented in various (e)books, blogs, wikis, manpages, and so on.


    Which agent did you installed, where did you downloaded it, how did you installed and configured it?

    Are your pfsense and the firewalls of the senior guys same hardware, same pfsense version, same plugins installed and configured, etc?


    Come on... maybe you should start some weeks in 1st level support to learn that others can only help you if they can unterstand and reproduce your errors. So give detailed information or otherwise no one can or will help you.

    Bist du als omdadmin angemeldet oder extra user? Der Fehler trat schon ein paar mal bei anderen auf, entweder hier im Forum oder auf der Mailingliste. Wenn ich mich korrekt erinnere half ein aufräumen des Browsers (Cookies, etc) bezüglich des Monitoring Servers.

    Ich habe selbst bisher leider keine gefunden. Naja außer wenn man einen kompletten Slave ersetzen will, kann man mit "omd backup" ein Backup erstellen und das recht einfach auf dem neuen Slave einspielen aber bei der reinen Migration einzelner Hosts sehe ich da keinen anderen Weg.


    Wobei einen gäbe es: Du lässt von allen deinen Seiten die RRDs auf einen zentralen Storage schreiben, dann sollte es mMn egal sein auf welchem Slave deine Hosts liegen, da von allen Slaves aus die RRDs im gleichen Pfad sind. Nachteil: Du machst dich abhängig von diesem zentralen Storage. Gerade das versuchen wir hier aber zu vermeiden, daher sind die Check_MK Server hier alle auch dediziert mit lokalem Speicher, damit sie möglichst unabhängig sind von der restlichen Infrastruktur.

    Migration underlaying OS and check_mk version in one step could be complicated. You could do the migration this way:

    1. Migrate your check_mk from 1.2.6 to 1.4.0 on old server and eliminate incompatibilities

    2. Create a full backup of the 1.4.0 on old server https://mathias-kettner.de/checkmk_backup.html. Your link is only for the check_mk appliance not for self installed setups

    3. Install your new server with 1.4.0 and restore your backup

    You have two options: 1) Create a "disabled services" rule for this check on the specific host or hostgroup/tag if there are multiple hosts or 2) create an exclusion for this/these host/hosts by rule "periodic service discovery" to disable the discovery.

    The article you've mentioned is for checks which can be implemented in the core functions of check_mk, you want something complete different.


    First you have to write your own monitoring script. In this script you have to call the REST API and process the response. The output of your script must match the criteria how check_mk expects plugin output. You can find examples here: https://mathias-kettner.de/checkmk_localchecks.html


    Save the script in the correct path, make it executeable for the omd site user. Next step is in the web interface:

    WATO > Host & Service Parameters > Datasource Programs > Individual program call instead of agent access


    There you can dcreate a new rule, define your script and the hosts you want the script for, save and activate the rule and then you have to do a re-discovery on the necessary hosts to inventorize your new check.

    There is an easy solution: You monitor the slave instance server from your master instance server and in the distributed monitoring configuration you have to set the slave instance server as status host for this site.

    If this slave instance host goes down, then all systems monitored by the slave instance will be marked als stale.

    there you have to define SQL statements for the parameters you want to check.


    You should check the mysql plugin mk_mysql to get some suggestions and ideas what to monitor, e.g. number of concurrent sessions, version, size of the databases and so on.


    Other option: use the mk_mysql plugin on another host of possible and create necessary piggyback rules to hand over the mk_mysql checks to the AWS RDS Instance dummy host. But with this variant you exchange sql statements against regex and I don't know if this is the best solution for your use case.

    mkp File auf deinen check_mk Server herunterladen und dann per GUI oder CLI wie hier beschrieben installieren:

    https://mathias-kettner.de/cms_mkps.html


    Dann kannst du, wie auf der Github-Seite ersichtlich, die Datei check_aacraid auf den zu überwachenden Client in das Verzeichnis

    /usr/lib/check_mk_agent/local/ kopieren und noch ausführbar machen.


    Abschließend noch ein Rediscovery des zu überwachenden Hosts und der Check sollte auftauchen.