Konfiguration#

Diese Anwendung ist über Konfigurationsdateien und Laufzeiteinstellungen in hohem Masse anpassbar.

Konfigurationsdateien#

Beim Start wird versucht, die folgenden Dateien zu laden:

• /etc/idoitcmk/config.json (systemweit) und
• ~/.idoitcmk/config.json (benutzerdefiniert)

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

Konfigurationsdatei automatisch erstellen#

Verwende den Befehl init, um deine eigene Konfigurationsdatei zu erstellen:

1

idoitcmk init

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

Wenn du diesen Befehl mit Superuser-Rechten (root) ausführst, wird stattdessen eine Konfigurationsdatei in /etc/idoitcmk/config.json geschrieben.

Mit diesem Befehl kannst du sogar deine Konfigurationseinstellungen aktualisieren. Vorher wird im Hintergrund ein Backup erstellt.

Konfigurationsdateien manuell erstellen#

Für einen guten Start gibst du die Beispielkonfiguration aus und bearbeitest 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. Du kannst unveränderte Einstellungen aus deinen lokalen Konfigurationsdateien entfernen.

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

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

Zugriff auf Checkmks Web API und Livestatus#

Konfiguriere den Zugriff auf die Web-API von Checkmk:

Livestatus kann derzeit nicht über TLS verbunden werden.

Konfiguration der verwendeten Checkmk Version#

Konfiguration command push#

Konfiguriere, 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) mail enthält, werden als Mail-Hosts gekennzeichnet.
• Objekte, deren Hostname (hostname) mit vm beginnt, werden der DMZ zugewiesen.
• Objekte, deren voll qualifizierter Domaenname (fqdn) mit test.local endet, werden als test gekennzeichnet.

Konfiguration command pull#

Konfiguriere, wie Daten von Checkmk zu i-doit gezogen werden:

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
        }
    }
}

Objekttypen#

Verwendete Objekttypen, gekennzeichnet durch ihre Konstanten:

Object titles#

Verwendete Objekte, identifiziert durch ihren Titel:

Roles#

Liste von i-doit-Rollen für Kontaktgruppen, die bei Kontaktzuweisungen verwendet werden:

Ignorierte Objekttypen#

Diese Liste von Objekttypen wird standardmäßig vollständig ignoriert:

Es ist nicht möglich, Objekttypen aus dieser Liste zu entfernen (bitte erstelle ein Ticket, wenn du dies trotzdem tun willst). Aber du kannst diese Liste um andere Objekttypen erweitern.

Im nächsten Beispiel werden auch alle Objekte vom Typ Client ignoriert. Um diesen Objekttyp zu identifizieren, verwende 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 wird. Der aktuelle Standardwert ist 31. Das bedeutet, dass alle Log-Meldungen ausser 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 fatale Fehler und Fehler).

Zusätzliche Konfigurationsdateien#

Optional kannst du eine oder mehrere zusätzliche JSON-formatierte Konfigurationsdateien mit der Option -c oder --config übergeben. Wiederhole 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#

Du möchtest einige Einstellungen während der Laufzeit ändern? Das kannst du mit den Optionen -s und --setting tun. Trenne 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}']

Wiederhole die Option für mehr als eine Einstellung.

Reihenfolge der Konfigurationseinstellungen ist wichtig#

Wie du bereits gelesen hast, hast du verschiedene Möglichkeiten, deine 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)

Teste deine Konfiguration#

Mit dem Befehl configtest kannst du eine detaillierte Überprüfung deiner Konfigurationseinstellungen durchführen. Dies ist sehr nuetzlich, nachdem du deine Einstellungen erstellt oder geändert hast:

1

idoitcmk configtest

Gib deine Konfiguration aus#

Wenn du eine Reihe von Konfigurationsdateien und Laufzeiteinstellungen hast, ist es manchmal gut zu wissen, was deine kompilierten Einstellungen sind:

1

idoitcmk print-config

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