checkmk 2: Konfiguration#

Diese Anwendung ist über Konfigurationsdateien und Laufzeiteinstellungen in hohem Maße anpassbar.

Konfigurationsdateien#

Beim Start wird versucht, die folgenden Dateien zu laden:

• /etc/idoitcmk/config.json (system-wide) und
• ~/.idoitcmk/config.json (user-defined)

Die Konfigurationsdateien sind als JSON (JavaScript Object Notation) formatiert, ein für Menschen und Roboter leicht lesbares Format.

Konfigurationsdatei automatisch erstellen#

Verwenden Sie den Befehl init, um Ihre eigene Konfigurationsdatei zu erstellen:

1

idoitcmk init

Dieser Befehl stellt Ihnen mehrere Fragen zu allen Einstellungen, die unten aufgeführt sind. Danach wird eine Konfigurationsdatei nach ~/.idoitcmk/config.json geschrieben.

Wenn Sie diesen Befehl mit Super-User-Rechten (root) ausführen, wird stattdessen eine Konfigurationsdatei in /etc/idoitcmk/config.json geschrieben.

Mit diesem Befehl können Sie sogar Ihre Konfigurationseinstellungen aktualisieren. Vorher wird im Hintergrund ein Backup erstellt.

Konfigurationsdateien manuell erstellen#

Für einen guten Start geben Sie die Beispielkonfiguration aus und bearbeiten sie sie lokal:

1
2
3

mkdir ~/.idoitcmk
idoitcmk print-example-config > ~/.idoitcmk/config.json
editor ~/.idoitcmk/config.json

Verfügbare Einstellungen#

Die Konfigurationseinstellungen sind nach Themen getrennt:

Erforderliche Themen sind i-doit und check_mk, andernfalls wird der Informationsaustausch zwischen ihnen nicht funktionieren. Alle anderen Themen können optional geändert werden.

Für fast jede Einstellung gibt es einen vordefinierten Standardwert. Sie können unveränderte Einstellungen aus Ihren lokalen Konfigurationsdateien entfernen.

Zugriff auf die JSON-RPC-API von i-doit#

Konfigurieren Sie den Zugriff auf die JSON-RPC-API von i-doit:

Zugriff zu checkmk's Web API und Livestatus#

Konfigurieren Sie den Zugriff auf die Web-API von checkmk:

Livestatus kann derzeit nicht über TLS verbunden werden.

Konfiguration der verwendeten Checkmk Version#

Konfiguration command push#

Konfigurieren Sie, wie Daten von i-doit an checkmk übertragen werden sollen:

Auto tagging#

Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
    "push": {
        "autoTagging": {
            "title": {
                "/^00/": {
                    "tag_agent": "cmk-agent",
                    "tag_criticality": "prod"
                },
                "/mail/": {
                    "tag_system": "mail"
                }
            },
            "hostname": {
                "/^vm/": {
                    "tag_networking": "dmz"
                }
            },
            "fqdn": {
                "/test\\.local$/": {
                    "tag_criticality": "test"
                }
            }
        },
        "autoMatching": "all"
    }
}

Versucht, alle Ausdrücke zu finden:

• Objekte, deren Titel (title) mit 00 beginnt, werden von einem Agenten geprüft und als produktiv eingestuft.
• Objekte, deren Titel (title) mit mail in der Mitte beginnt, werden als Mail-Hosts gekennzeichnet.
• Objekte, deren Hostnamen ( hostname) mit vm beginnen, werden der DMZ zugewiesen.
• Objekte, deren voll qualifizierte Domänennamen (fqdn) mit test.local enden, werden als test gekennzeichnet.

Konfigurieration command pull#

Konfigurieren Sie, wie Daten von Check_MK zu i-doit ziehen:

Identifiers#

In i-doit gibt es mehrere Attribute, die sich als eindeutige Bezeichner eignen, um sie mit Hosts in checkmk abzugleichen:

Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
    "pull": {
        "identifier": [
            "title",
            "hostname",
            "fqdn",
            "hostaddress",
            "alias",
            "user-defined"
        ],
        "minMatch": 2
    }
}

Attribute#

In i-doit ist jedes Objektattribut an eine sogenannte Kategorie gebunden. Diese Kategorien können geändert werden:

Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
    "pull": {
        "attributes": {
            "C__CATG__ACCESS": true,
            "C__CATG__APPLICATION": true,
            "C__CATG__CONTACT": true,
            "C__CATG__CPU": true,
            "C__CATG__DRIVE": true,
            "C__CATG__GRAPHIC": true,
            "C__CATG__IP": true,
            "C__CATG__MEMORY": true,
            "C__CATG__MODEL": true,
            "C__CATG__OPERATING_SYSTEM": true,
            "C__CATG__NETWORK_LOG_PORT": true,
            "C__CATG__NETWORK_PORT": true
        }
    }
}

Objekt-typen#

Verwendete Objekt-typen gekennzeichnet durch ihre Konstanten:

Object titles#

Used objects identified by their titles:

Roles#

This is a list of i-doit roles for contact groups used in contact assignments:

Ignorierte Objekt-typen#

Diese Liste von Objekt-typen wird von Standard vollständig ignoriert:

Es ist nicht möglich, Objekt-Typen aus dieser Liste zu entfernen (bitte erstellen Sie Ticket, wenn Sie dies trotzdem tun wollen). Aber Sie können diese Liste um andere Objekt-Typen erweitern.

Im nächsten Beispiel werden auch alle Objekte vom Typ Client ignoriert. Um diesen Objekt-Typ zu identifizieren, verwenden Sie seine Konstante anstelle seiner (englischen oder deutschen) Bezeichnung:

1
2
3
4
5

{
    "blacklistedObjectTypes": [
        "C__OBJTYPE__CLIENT"
    ]
}

LogLevel#

Das CLI-Tool idoitcmk hat verschiedene Log-Ebenen:

Es gibt eine Konfigurationseinstellung log.verbosity, um die Standard-Protokollstufe anzupassen. Dieser Wert wird verwendet, wenn weder die Laufzeitoption -v|--verbose noch -q|--quiet verwendet werden. Der aktuelle Standardwert ist 31. Das bedeutet, dass alle Log-Meldungen außer Debug-Meldungen enthalten sind.

Auf der einen Seite setzt die Laufzeitoption -v|--verbose diese Konfigurationseinstellung temporär auf 63, was alle Loglevel einschließt. Auf der anderen Seite setzt die Laufzeitoption -q|--quiet diese Einstellung temporär auf 3 (nur Fatals und Fehler).

Zusätzliche Konfigurationsdateien#

Optional können Sie eine oder mehrere zusätzliche JSON-formatierte Konfigurationsdateien mit der Option -c oder --config übergeben. Wiederholen Sie die Option für mehr als eine Datei. Zum Beispiel:

1

idoitcmk push --config i-doit-testing.json --config check_mk-testing.json

Laufzeit-Einstellungen#

Sie möchten einige Einstellungen während der Laufzeit ändern? Das können Sie mit den Optionen -s und --setting tun. Trennen Sie verschachtelte Schlüssel mit ., zum Beispiel:

1
2

idoitcmk push --setting "push.activateChanges=true"
idoitcmk pull -s ['pull.attributes={"C__CATG__ACCESS": true,"C__CATG__APPLICATION": true,"C__CATG__CONTACT": true,"C__CATG__CPU": true,"C__CATG__DRIVE": true,"C__CATG__GRAPHIC": true,"C__CATG__IP": true,"C__CATG__MEMORY": true,"C__CATG__MODEL": true,"C__CATG__OPERATING_SYSTEM": true,"C__CATG__NETWORK_LOG_PORT": true,"C__CATG__NETWORK_PORT": true}']

Option "Wiederholen" für mehr als eine Einstellung.

Reihenfolge der Konfigurationseinstellungen ist wichtig#

Wie Sie bereits gelesen haben, haben Sie verschiedene Möglichkeiten, Ihre bevorzugten Einstellungen an diese Anwendung zu übergeben. Diese Anwendung folgt dieser Reihenfolge:

1. Die Standardeinstellungen werden überschrieben durch
2. Systemweite Einstellungen (/etc/idoitcmk/config.json) werden überschrieben mit
3. Benutzerdefinierte Einstellungen (~/.idoitcmk/config.json) werden überschrieben mit
4. Zusätzliche Konfigurationsdateien (Optionen -c FILE oder --config FILE) werden überschrieben mit
5. Laufzeiteinstellungen (Optionen -s KEY=VALUE oder --setting KEY=VALUE)

Testen Sie Ihre Konfiguration#

Mit dem Befehl configtest können Sie eine detaillierte Überprüfung Ihrer Konfigurationseinstellungen durchführen. Dies ist sehr nützlich, nachdem Sie Ihre Einstellungen erstellt oder geändert haben:

1

idoitcmk configtest

Geben Sie Ihre Konfiguration aus#

Wenn Sie eine Reihe von Konfigurationsdateien und Laufzeiteinstellungen haben, ist es manchmal gut zu wissen, was Ihre kompilierten Einstellungen sind:

1

idoitcmk print-config

Damit werden Ihre aktuellen Konfigurationseinstellungen JSON-formatiert auf STDOUT ausgegeben.