Posts by mcktr

Hello,

your error occurs because you included the monitor.conf separately. All configuration files under zones.d are included by default, so delete your include "zones.d/monitors/monitor.conf" statement and it should work.

Dann schau mal in dem Verzeichnis /etc/apache2/sites-enabled/, dort sollte auf jeden Fall ein Symlink zu deiner Konfig.-Datei für Icinga Web 2 liegen.

Nach welcher Anleitung bist du vorgegangen und hast Icinga Web 2 installiert?

Sieht so aus, als ob der Apache nur auf einer IPv6-Adresse lauscht, aber nicht an einer IPv4-Adresse. Wie sieht denn deine Apache Konfig. aus? Normalerweise sollte im Verzeichnis /etc/apache2/sites-available/ eine entsprechende Konfig.-Datei für Icinga Web 2 liegen.

Of course is there a documentation, you can find it in the Icinga 2 docs.

I recommend you to bookmark the site, the documentation is very good and every time up to date.

For me it looks like you're service is checking the free memory and not the used memory. Try to set vars.nscp_memory_free explicitly to false.

Moin,

ja das geht. Du legst im Icinga Web 2 eine neue Rolle an (unter Konfiguration -> Authentifizierung) und dort unter monitoring/filter/objectsträgst du z.B. folgendes ein host_name=sv* damit werden nur noch alle Hosts angezeigt, die mit einem "sv" im Namen beginnen. Für Hostgruppen geht das auch mit z.B. hostgroup_name=linux-servers für alle Linux Server. Verknüpfte Service Objekte sind davon ebenfalls betroffen, sprich die dazugehörigen Services siehst du auch.

Natürlich musst du auch einen neuen User anlegen und diesen der Rolle zuweisen.

MfG

If you use the CLI command dashing start the port 3030 is used. Only with the script ./restart-dashing the port 8005 is set.

But anyway, good to know it is working now.

Hi,

have you used the script ("restart-dashing") to start your dashboard? If not dashing use the default port 3030, check if your dashboard is available at <YOUR IP>:3030.

In der zones.conf müssen auch alle Clients bzw. Endpoints stehen. Sieh dir dazu am besten nochmal das Thema Top Down Command Endpoint in der Doku an, dort ist das wirklich gut beschrieben.

Moin,

wie sieht den Deine Service Definition in der services.conf aus?

Hast du folgende Zeile in deiner Definition berücksichtigt?

Damit sagst du Icinga 2 auf welchem Endpoint der Check laufen soll.

dlex51 wrote:

In dem zones.d Ordner befinden sich derzeit 3 Unterordner: global-templates, satellite und master.

Im global-templates Ordner befindet sich die global-templates.conf mit folgendem Inhalt:

Code

1. object Zone "global-templates" { global = true;}

Diese Zone ist ebenfalls in der zones.conf des Satelliten und des Clients hinterlegt.

Auf Deinem Master sollte die Zone global-templates ebenfalls in der "globalen" zones.conf stehen.

dlex51 wrote:

Und im Ordner master habe ich alle Dateien aus dem conf.d Verzeichnis kopiert und dementsprechend in der icinga2.conf die Ordner angepasst (auf allen Servern). Die anderen Dateien auf dem Master sind erstmal default geblieben.

Was genau meinst Du hier? Welche Pfade hast Du in der icinga2.conf angepasst?

Viele Grüße

Hallo,

ich stehe momentan zwischen zwei Welt und möchte hier nach einem "Best Practice" fragen.

Wir setzten bereits Icinga 2 und IciningaWeb 2 ein, bisher habe ich die komplette Konfiguration händsich über die CLI gemacht. Nun möchte ich unseren Monitoring Stack aus Icinga 2 & Icinga Web 2 neu aufsetzen (bzw. einen 2. parallel aufbauen), da unter anderem ein altes noch bestehendes Nagios-System in einem Außenstandort abgelöst werden soll. Ich möchte die Neuinstallation gerne "sauber" halten und habe gedacht, dass der Director dafür hervorragend geeignet ist. Ein weiterer auch nicht ganz unwichtiger Punkt wäre, dass meine Kollegen dann über das Web-Interface weitere Hosts hinzufügen könnten, bisher bliebt die Erstellung neuer Hosts an mir hängen.

Das sind erstmal viele Punkt die für ein Einsatz des Director sprechen. Was mir bei dem Director nicht gefällt ist die Tatsache, dass ich die konfigurierten Hosts, Services, Notifications, etc. nicht in das Dateisystem exportieren kann - alles wird in der Director Datenbank gehalten. Ansich ist das keine schlimme Sache, dass der aktuelle Stand der Konfig. in der Director Datenbank gehalten wird, jedoch hätte ich gerne eine Möglichkeit die aktuelle Director Konfiguration zu exportieren und auf einem anderen System wieder zu importieren, um z.B. auf einem Test-System eine Änderungen der Konfig. zu testen auf Basis der Produktivdaten. Vielleicht gibt es diese Möglichkeit sogar und ich habe sie schlicht übersehen in meinen Tests mit dem Director.

Wie handhabt Ihr das ganze in Eurem Team? Erstellt ihr die Konfig. weiterhin über die CLI oder nutzt Ihr den Director? Ich hoffe auf ein paar denkanstöße von Euch und bin für jedes Feedback offen.

Viele Grüße!