Posts by friesoft

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

    Oh... you are totally right.. I forgot about Array#join ...


    Thanks for pointing this out! I was able to replace my array_to_string function call with calls to join("\n"). Much better :)


    So what's left now are just some function calls (by_ssh_command, logfile_tag). Can this be handled with director?

    The only remotely related thing I was able to find was: https://github.com/Icinga/icin…dule-director/issues/1168


    Thanks for your help! :)

    I used another approach now but I'm not able to use it with director yet. It is also a bit ugly as I'm using commandline arguments to pass over the check_logfile parameters.

    Configuring this via Director is not yet possible (or at least I didn't manage). Maybe this would be worth a feature request? Please comment :)


    Implementation

    This creates a Template Service which can be be applied to all logfiles (custom array variable from the host objects). You can configure all critical/warning/ok patterns as well as the critical/warning exceptions through the icinga configuration.


    It also creates an unstick service for every check_logfile. They are linked to each other using icingaweb2 shared navigation.


    Code: /etc/icingaweb2/navigation/service-actions.ini
    1. [My Log Crosslink]
    2. groups = "admins"
    3. type = "service-action"
    4. target = "_next"
    5. url = "monitoring/service/show?host=$host_name$&service=$_service_navigation_link$"
    6. icon = "check"
    7. filter = "service_description=My Log *"
    8. owner = "friedreb"

    What do you think? Is there a better aproach?

    How can I get this into director? :)

    Something like this seems like a possible solution to me.


    Still: is applying services for services possible? Is this way the recommended?


    And most importantly:

    Can I create such a host config using Icinga Director? According to this bugreport it doesn't look like: https://github.com/Icinga/icin…odule-director/issues/773

    Hello,


    I would like to generate a service for other services.


    Example:

    I have 2 check_logfiles services on one host - for each check_logfiles service I would like to generate a check_logfiles instance with another command (unstick option set).


    Some pseudo code:

    Code
    1. foreach (host : getAllHosts())
    2.     foreach (service : host.getServices())
    3.         if (service.name startswith("Logfile"))
    4.              generateService("Logfile Reset " + extractLogPath(service.name))

    Is something like this possible? Could this grow into a performance problem or is this only evaluated once?


    How could this be done differently? Only solution I could think of is an array in the host object containing all logfiles and using two apply for rules to generate the check_logfiles service itself and another one for unstick.


    Thanks & Best regards,
    Bernhard

    Hello,


    I would like to add check_logfiles monitoring for all our logfiles automatically. That means I can create a service using Icinga Director which I can apply everywhere.


    Usecase: OutOfMemory should be checked for all Tomcat logfiles.


    To simplify configuration I don't want to create config files for each service but instead configure the service using Icinga Director (one field with an array for warningexceptions, one field with an array for criticalpatterns, ...).


    To make this work I need check_logfiles to be fully configurable using the commandline.


    Basically something like that config, just from commandline:

    I couldn't get that to work as it seems to ignore my patterns :( Is something like that possible? Has anyone tried?


    Thanks,

    Bernhard

    Haha :D you were a bit faster than me :D I am also working on a Grafana module and am in the final steps (adding configuration ui, ...)


    Nice work :) Will try for sure!


    [edit]: I just tried it. You took a different approach in using the render API and fetching on the icinga server. I implemented the module using the iframe embed method. This works better together with our SSO solution protecting Grafana. It also leads to graphs being zoomable etc.. well it's Grafana after all :)

    I couldn't get your module to work as we don't have the http auth enabled and can only use the Bearer header.

    I like the configuration options, especially the per service configuration of the graphs.

    What my module supports is different backends, currently influxdb and graphite. The only real change needed is that metrics need to be escaped for graphite.

    You definitely, did some nice work! Hopefully I'm allowed to publish my module as well so we can learn from each other :)

    Hallo,


    ist es aktuell möglich die Anmeldung über HTTP Header zu regeln? Unsere Lösung für Single Signon schützt die komplette Domain und stellt der Applikation in den HTTP Headern die nötigen Informationen bereit damit die Anwendung (in diesem Fall Icingaweb2) anzeigen kann dass der User eingeloggt ist und welche Rechte dieser besitzt.


    Wenn dies aktuell nicht möglich ist: kann man hierfür ein Modul oder ähnliches schreiben? Wo könnte man diesbezüglich ansetzen?


    Was ich bisher gefunden hätte als Ansatzpunkt: https://github.com/Icinga/icin…a/Authentication/Auth.php
    Hier könnte man das sicher reinfriemeln.. Würde das Icingaweb2 Projekt das als Patch akzeptieren? (sofern es nicht schon möglich ist).


    [Edit] oder ist das External Backend das richtige hierfür? Laut dem Source (https://github.com/Icinga/icin…r/ExternalBackend.php#L62) wird hier auf das _SERVER Array zugegriffen in dem auch die HTTP Header drinnen sind. Nur wird die Methode getRemoteUser ohne Parameter aufgerufen wodurch immer nur die Variable REMOTE_USER abgefragt wird.


    [Edit2]: das ExternalBackend.php dürfte der richtige Ansatzpunkt sein. Wenn ich dort die REMOTE_USER auf HTTP_USER umbaue und den entsprechenden Header mitschicke bin ich direkt eingeloggt :)
    Damit fehlt mir nur die Möglichkeit diesen Parameter über die Oberfläche zu konfigurieren wenn das Backend External Auth ist.


    Danke im Voraus & LG
    Bernhard

    Hallo,


    wir sind aktuell dabei unsere Nagios Installation auf Icinga2 zu migrieren und stehen dabei vor der Herausforderung eine möglichst übersichtliche Konfiguration aufzubauen.


    Wir haben in etwa folgenden Aufbau und damit Anforderung an die Überwachung:

    • OS: Linux/Solaris (je nachdem zum Teil unterschiedliche Checks)

      • gelöst über vars.os
    • mehrere Apache httpd Instanzen pro Server

      • Überprüfung ob der Prozess noch läuft
      • mehrere VHosts pro httpd
      • Überprüfung mittels check_http welcher Status Code zurück kommt
    • mehrere Tomcats pro Server

      • Überprüfung ob der Prozess noch läuft
      • mehrere Connectors pro Tomcat
      • Überprüfung mittels check_http/check_ajp welcher Status Code zurück kommt

    Unsere Überlegung war, dass das "Host" Objekt den Server möglichst vollständig in seinem Aufbau widerspiegeln sollte und die Services dann nur mehr auf einzelne Variablen applied werden.
    Siehe [1].


    Gibt es hierzu best practices? Können Dictionieries geschachtelt werden, sodass wir darüber iterieren können?
    Wir würden uns etwas in dieser Art vorstellen: [2]. Bzw. eigentlich zwei apply for ineinander verschachtelt da wir den httpd Namen auch noch benötigen würden für die Description.


    Vielen Dank :)


    LG
    Bernhard


    [1]:


    [2]:

    Code
    1. apply Service "http-" for (vhost => vhost_config in host.vars.apache.httpds.vars.vhosts) {
    2. import "generic-service"
    3. check_command = "http"
    4. vars += vhost_config
    5. notes = "HTTP checks for " + vhost
    6. assign where host.vars.vhosts
    7. }

    das von findmypast ist älter, das von Icinga neuer. Vorteile von dem von Icinga:


    • du musst Graphite-Web nicht public zugänglich machen, alle Requests laufen authentifiziert durch das Modul
    • es unterstützt Templates, du hast bei 10 datasources zum selben Check also nicht 10 hässliche einzelne Linien
    • Datasources der Templates lassen sich per Mausklick in der Legende ein- und ausschalten (siehe MySQL-Beispiel auf den Screenshots)
    • es ist nicht von Icinga abhängig, lässt sich also auch wunderbar nutzen um parallel z.B. Bilder für von Collectd o.ä. gesammelte Daten darzustellen

    Nachteil vorerst: kein Template, kein Bild


    Noch offen sind grob folgende Punkte:

    • Möglichkeit zum Zoom und zur bequemen Navigation in der Zeit. Geht schon vieles per URL, hilft halt wenig wenn man's nicht weiß :D
    • Mehr Templates, Tipps/Doku zum Erstellen derselben (ist ziemlich simpel, einfach die Beispiele anschauen)
    • Separate Berechtigungen für den Zugang zu allen Graphen, die sind aktuell aus dem Menü für jeden erreichbar, der das Modul nutzen darf

    Hallo Tom,


    wäre super wenn du diese Infos in irgendeiner Form direkt beim offiziellen Repository unterbringen könntest. Wir haben vor etwa einem Monat versucht mit dem offiziellen graphite Module die Graphen direkt beim Service angezeigt zu bekommen und haben uns dabei fast die Haare ausgerissen weil wir alles nach Anleitung gemacht haben, aber nichts funktioniert hat wie auf den Screenshots - wo es Graphen gab - die Screenshots waren nur offenbar alle von findmypast.


    Kannst du einen ungefähren Zeithorizont nennen wann die Graphen auch inline beim Service dargestellt werden können (ohne weiteren Klick auf einen Link) und wann das zoomen (ohne fixe Zeitraumvorgaben) möglich sein wird?


    Das wären die 2 Features die wir als bisherige Nagios User mit pnp4nagios schmerzlich vermissen.


    Vielen Dank! :)