Posts by InTheWild

This forum was archived to /woltlab and is now in read-only mode.

    Ja jaa, immer diese Brillen ;) Ich habe halt mehr die Anwender-Brille, aber mit dieser muss man sehr aufpassen dass man sich nicht im Wald verirrt...


    Ich vermute mal, dass der fehlende Kickstart das Resultat eines Bugs war - ich habe mit der Director Version 1.0 angefangen, da wäre sowas nicht ungewöhnlich. Zudem fehlte der Kickstart sowohl auf meiner Test-VM, als auch auf der produktiven Überwachung.


    Aber jetzt habe ich ja meine Command Objekte, also alles bestens vor'm Wochende :thumbsup:

    Zuerstmal vielen Dank für den Link, der hat mich auf die richtige Spur gebracht. Im Verzeichnis "/etc/icingaweb2/modules/director" war die Datei "kickstart.ini" nicht vorhanden. Ich habe sie lt. Beschreibung erstellt und nach einem

    Code
    1. icingacli director kickstart run

    hatte ich 171 neue Command-Objekte im Director, darunter auch das fehlende "jmx4perl". Alles gut also :thumbsup:


    Nur zum Verständnis:

    Hätte diese Prozedur inkl. der Erstellung der kickstart.ini nicht durch das Setup des Directors durchgeführt werden sollen?

    Die ITL ist in der icinga2.conf eingerichtet. Habe jetzt nochmal icinga2 durchgestartet - aber das jmx4perl-Kommando ist nach wie vor nicht im Director vorhanden.

    Icinga selbst hat es korrekt als Objekt registriert (überprüft über "icinga2 object list").


    Da Du den Director Kickstart erwähnt hast: wo kann ich nachsehen, ob der überhaupt etwas gemacht hat, bzw. wie der konfiguriert ist? Vielleicht habe ich hier ja ein Problem...

    Hi all,


    ich stecke gerade beim Import eines Command-Objekts in den Direktor fest - vielleicht kann mir bitte hier jemand weiterhelfen.


    Konkret versuche ich gerade, das Command-Objekt "jmx4perl" aus der ITL zu importieren. Hierzu habe ich mir im Director eine Import-Quelle "Import Icinga Check Commands" für Check Commands erstellt. Im Reiter "Preview" finde ich u.a. auch das Object "jmx4perl".


    Anschließend habe ich eine SyncRule "Onetime Import jmx4perl" erstell, hänge jetzt aber bei der Definition der Properties. Soweit ich das verstanden habe, muss ich hier eine Art Mapping zwischen der

    Quelle und dem Ziel definieren. Wie genau muss ich das in meinem Fall angeben - die mir hier angezeigten Opionen verwirren mich etwas...


    Grüße

    Wild

    Sorry for the late response, I was too busy to read the posts in the last weeks...


    We use the check_http-command to check our internal web-servers (https direct access, and http redirected to https), and the certificate expiration, all configured with the director, and it works like charm.


    It looks like the directors setup add all the the command arguments to it's field list, with exception of the arguments used with the "set_if"-keyword, so there is no http_ssl-argument by default. My way to create a check for a https-page was like that:

    • Go to the Icinga Director menu, and then to "Define data fields"
    • Add a new field:
      • Field Name: http_ssl
      • Caption: http_ssl
      • Description: Whatever you want - my description was: "true", if the SSL-connection should be checked, otherwise "false" not use it.
      • Data Type: Boolean
      • Store that
    • Go to the Commands menu, select "http", and in the right pane select the "Fields" tab
    • Add at least the following fields:
      • http_ssl
      • http_vhost
    • Now you can add a new check-Template for ssl-websites:
      • Fill out Fields Name ("https", for example), Import like you want, use "http" for the Check-command
      • In the Custom properties section, set the value for "http_ssl" to "Yes" and save this

    Now you can add checks for your ssl-webpages based on the check-template you created before, just add the url into the http_vhost-property.


    Hope that helps.

    Hi,


    if you didn't already solved it by yourself, try the following (I'm refering to your screenshot "2.png"):

    * In the command definition go to the tab "arguments" and for the "-w"-parameter change the value from "0" to a more selfexplaining value, like "$my_warning_parameter$" for example. Store that

    * Change to the "Fields" tab. In the Field-Dropdown, under the "argument_macros" section select your parameter (in my example: $my_warning_parameter$). Hit "Add"

    * Go to the "Command" tab, Now under the "Custom properties" you can set a default value for your parameter ("0", in your case). After storing that, you can see the the results in the "Preview" tab.


    Regards

    Wild

    Evtl. hilft es, in der /etc/environment einen Eintrag zu setzen, in welchem Verzeichnis die TNSNAMES.ORA liegt - habe ich so noch nie versucht, evtl. funktioniert es ja, dann kannst Du wieder den DB-Namen verwenden.


    Code
    1. TNS_ADMIN=/verzeichnis/von/tnsnames

    Nur mal zur Kontrolle: Poste doch mal bitte Deine fehlerhaften bzw. "korrekten" Connect-Strings, und wie aktuell der betreffende Eintrag in der "resources.ini" von icingaweb2 aussieht.


    Da in der Fehlermeldung "TNS-nnnnn" bzw. "ORA-nnnnn" fehlt, sieht mir der Auslöser der Fehlermeldung eher nach icingaweb2 aus.

    Ja, sollte eigentlich auch funktionieren. Allerdings arbeiten wir i.d.R. über TNSNAMES.ORA, daher bin ich mir nicht sicher ob diese Syntax nicht eine explizite Unterstützung benötigt. Alternativ kannst Du als dbname es auch mit folgendem String versuchen:

    Code
    1. (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=myport))(CONNECT_DATA=(SERVICE_NAME=mysid)))

    Alles ohne Leerzeichen, für "myhost", "myport" und "mysid" musst Du natürlich noch Deine korrekten Werte einsetzen.

    Dann hätte ich hierzu ein paar Korrekturanregungen zur Doku:


    Unter "6.9 Configuration Modes" ist in den Konfigurationsbeispielen bei den Zone-Objekten die übergeordnete Zone im parent-Attribut angegeben. In den Beispielen unter "6.10 Scenarios" fehlt in den Konfigurationsbeispielen das parent-Attribut jedoch überall in den Satellite- bzw. Client-Zonen. Im Text unterhalb der Konfiguration ist die parent zone zwar erwähnt ("...The only important thing is that they know about the parent zone and their endpoint members..."), aber das parent-Attribut sollte trotzdem in die Beispiele - wo erforderlich - aufgenommen werden, um die Objektkonfiguration zu vervollständigen.


    Bei 6.10.2 ist im ersten Konfigurationsbeispiel in der "master"-zone zwei mal der gleiche Endpoint aufgeführt. Ich denke mal das sollte eigentlich so aussehen:

    Code
    1. object Zone "master" {
    2. endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
    3. }


    Desgleichen ist bei 6.10.3 im ersten Konfigurationsbeispiel (zones.conf) für die Zonen "master" und "satellite" ebenfalls jeweils zwei mal der gleiche Endpoint aufgeführt.


    Wenn Du nach den folgenden Zeilen suchst, findest Du die betreffenden Stellen schneller:
    endpoints = [ "icinga2-master1.localdomain", "icinga2-master1.localdomain" ]
    endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ]


    Grüße,
    Frank

    Da bei mir eine u.U. Erweiterung des Monitorings auch auf externe Standorte ansteht, habe ich mich in die Doku zum Distributes Monitoring eingelesen, damit ich schonmal grob die zukünftige Struktur planen kann. Doch zuerst einmal Kompliment für die überarbeitete Doku zum Distributed Monitoring. Sie ist exzellent, sehr umfangreich und aufgrund der Schema-Bilder auch (gemessen an der Komplexität des Themas) gut verständlich.


    Jetzt zum eigentlichen Thema:
    Wenn ich das soweit richtig verstanden habe, ist es in einer Top-Down-Konfiguration mit mehreren Zonen erforderlich, dass in jedem Zone-Objekt die direkte übergeordnete Zone über das parent-Attribut zu definieren ist. Ist das soweit korrekt?


    Grüße,
    Frank

    Interessant - wusste bislang nicht dass es diese Möglichkeit gibt. Da ich jedoch bislang noch nichts mit Perl gemacht habe, werde ich darauf erstmal verzichten.


    Was die komplexen Abfragen betrifft: diese liegen bei mir alle bereits in einem Package auf der Oracle-Datenbank. Mir ging es tatsächlich nur darum, dass das Plugin zu allen Rückgabewerten die Werte für Warnings bzw. Critical zurückgibt (wie bereits beim ersten Wert der Fall).


    Gruß,
    Frank

    Was in meinem Fall bedeutet, dass ich aus jedem Check der mehr als einen Wert zurückliefert, einzelne Checks machen muss die jeweils einen Wert zurückgeben. Das ist eigentlich schade, da zumindest in diesem Fall beide Werte zusammengehören und daher auch zum gleichen Zeitpunkt ermittelt werden sollten...


    Gibt es eine Möglichkeit, dass in einer zukünftigen Version die Übergabe mehrere Werte für Warnings/Critical möglich sind?


    Ansonsten tolles Plugin, macht richtig Spass damit zu arbeiten :) .


    Grüße,
    Frank

    Hallo,


    ich habe folgendes Problem: Ich führe mittels check_oracle_health eine SQL-Abfrage aus, die mir zwei Werte (Spool und Druck) zurückgibt. Wenn ich jetzt mittels --warning bzw. --critical Schwellenwerte übergebe, werden diese nur für den ersten Rückgabewert angewandt, nicht jedoch für den zweiten. Gibt es hierfür eine Lösung, oder mache ich einfach nur was mit meinem Check falsch?
    Beispiel:

    Code
    1. check_oracle_health --connect 191.168.4.123:1521/oradb --user icinga --password blub --mode sql --name 'select 0, 123 from dual' --name2 'Spool Druck' --warning 8000 --critical 9000
    2. OK - spool druck: 0 123 | 'spool'=0;8000;9000 'druck'=123;;

    Grüße,
    Frank