Posts by mcktr

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

  • Dependency Darstellung/verhalten

    MaBau_MeBad wrote:

    Location A hat den Master mit Icingaweb 2 etc. Location B hat einen Satellite mit seinen Childs. Nun geht der S2S VPN Tunnel zwischen den beiden Locations down (wieso auch immer) und im Monitoring wird "nur" der Satellite als down gemeldet. Letztenendes hat dies aber viel größere Auswirkungen, was jedoch nicht direkt sichtbar ist. Und genau dafür suche ich aktuell eine "schicke "Lösung, die auch noch sich im Rahmen hält.

    Aus Icinga Sicht geht kann in diesem Fall der Satellite die Check Results nicht mehr an den Master senden, der Satellite prüft aber fleißig weiter und sobald die Verbindung wieder steht, werden die Check Results dem Master mitgeteilt.


    Um die Verbindung von Master <-> Satellite zu prüfen gibt es verschiedene Icinga Checks die du nutzen kannst. Ist in der Doku gut beschrieben: https://www.icinga.com/docs/ic…monitoring/#health-checks


    Ich würde das mit dem Business Process Modul umsetzen, es ist denke ich eine elegante und schicke Lösung, um solche Fälle abzubilden.

  • Dependency Darstellung/verhalten

    Moin,


    schau dir mal das Business Process Modul an. https://github.com/Icinga/icingaweb2-module-businessprocess


    Damit kannst du nicht nur grafisch gut darstellen, wo es gerade an Geschäftsprozessen klemmt, sondern auch mit Hilfe der icingacli Checks bauen und die ins Monitoring einbinden, zwecks Benachrichtigungen.


    Was mir spontan auch noch in den Sinn kommt, wäre den Status des Host Checks mit Hilfe eines Dummy Checks und der Icinga 2 DSL basierend auf den Status des übergeordneten Hosts zu setzten. Es gibt einen Blog Beitrag, da wird zwar ein anderes Beispiel behandelt, aber ich denke man kann sich ganz gut etwas darunter vorstellen, was gemeint ist. https://www.icinga.com/2016/06…lation-from-all-services/


    Ich würde erstmal gucken, ob das mit dem Business Process Modul sich abbilden lässt. Den Host Status des Child Host basierend auf dem Parent Host zu setzten fühlt sich nicht richtig an - es suggeriert, dass beide Hosts gerade aus sind, was ja nicht unbedingt so sein muss. Mit dem Modul kannst du aber deutlich machen, wenn der Parent Host aus ist, hat das Auswirkungen auf den Child Host, ohne das bei diesem sich ein Service oder Host Status ändert.


    Das sind jetzt sicherlich nicht die goldenen Lösungen aber vielleicht ein paar Ansatzpunkte mit denen du arbeiten kannst. :)

  • Check_cluster mit Director

    Moin,


    für die Variable vars.check_cluster_objects gibt es keine entsprechende Zuordnung in deinem CheckCommand.


    Ich glaube auch nicht, dass das check_cluster Plugin aus den Monitoring Plugins mit Icinga 2 Host Objekten umgehen kann. Wirf einmal einen Blick in die Doku des Plugin, da ist ein Beispiel aufgezeigt, wie der Check funktioniert: https://www.monitoring-plugins…oc/man/check_cluster.html


    Ich habe noch nicht so ganz verstanden, was du monitoren willst. Willst du den Icinga 2 Cluster überwachen? Dafür gibt es die Checks "cluster" und "cluster-zone", mehr dazu in der Doku: https://www.icinga.com/docs/ic…monitoring/#health-checks

  • Icinga downtimes not synced

    The version 2.5.4 ist fairly old (from August 2016). I quickly skipped through the changelog of last versions and found the following "Fix cluster resync problem with API created objects (hosts, downtimes, etc.)", you might hit this. Please think about an upgrade to the latest version.


    Please share more details of your setup you can find a list about important details inside the FAQ.

  • check_http returns with Cannot make SSL connection.

    I'll guess that it has to do with SNI.


    When I set the parameter -servername <Hostname> for SNI, than I get the Let's Encrypt Certificate.


    The thing that I did not get is your check_http output, I used the exact same parameter as you and it works on my client.

    Code
    1. $ /usr/lib/nagios/plugins/check_http -S -H piwik.andrea.muellerpublic.de
    2. HTTP OK: HTTP/1.1 200 OK - 33043 bytes in 1,385 second response time |time=1,384958s;;;0,000000;10,000000 size=33043B;;;0

    The only different I can see, is that I run the check on my machine and not inside in a docker container, could you test it outside a docker container? Are you or your docker container using an art of a proxy to connect to the internet, maybe the issue is there?

  • master kriegt keine Host/Service Informationen von Satelliten

    artur wrote:

    War das dann ein Denkfehler von mir, dass es möglich ist sich alle Hosts/Services der Satelliten auf dem Master mit icingaweb2 anzeigen zu lassen?

    Nein. Genau so ist es auch gedacht, sich auf dem Master alle Hosts/Services der eigenen Zone und der untergeordneten Zonen anzeigen zu lassen. Was mit Top Down hier gemeint ist, ist dass die komplette Konfiguration auf dem Master gemacht wird. Wenn du einen neuen Host oder einen neuen Service in der Zone satellite überwachen willst konfigurierst du das nicht auf dem Satellite Node sondern auf dem Master. Durch die Config Synchronisation bekommt der Satellite Node vom Master mitgeteilt "Du hast jetzt einen neuen Host/Service, bitte überwach diese ebenfalls". Der Satellite überwacht dann die Hosts/Services und teilt dem Master über das Icinga Cluster Protokoll mit, wie die Check Results und Performance Daten aussehen. Der Master empfängt diese Daten und weiß nun somit, wie es in seinen untergeordneten Zonen aussieht. Die Daten schreibt der Master dann in seine IDO Datenbank, auf diese greift wiederum Icinga Web 2 zu und am Ende siehst du alle Hosts und Services aus der Master Zone und den untergeordneten Zonen im Icinga Web 2.


    Die Version 2.6.0, die du auf deinem Master und deinem Satelliten hast, ist von Ende letzten Jahres. Ich würde als ersten Schritt die Versionen hier gleichziehen, sprich alle auf die 2.7.1, die du bereits auf deinem Freiburg Satelliten hast.

  • iciniga director command

    I suspect that this error comes from an earlier configuration.


    Go to Icinga Web 2 -> Configuration -> Modules -> director -> Configuration and set your DB resource for the director here.


    You can configure the resources under Icinga Web 2 -> Configuration -> Application -> Resources. Make sure you use utf8 for the Director database.

  • iciniga director command

    gpconnect wrote:

    try some command but getting some errors so i deleted !

    What exactly did you tried to do? With "I tried something and getting some errors" it is hard to help. Please share the error you get and the steps you are made to get the error.


    Did you follow my suggestion to start over with a new and fresh database for the Director?


    Also which version of the Director you are using?

  • iciniga director command

    This is totally okay. The NodeName and ZoneName constants are defined in your constants.conf.


    Did you disable the conf.d inclusion in your icinga2.conf?

    Code: icinga2.conf
    1. [...]
    2. // include_recursive "conf.d"
    3. include "conf.d/api-users.conf"            


    Are you getting any warnings/errors when you run # icinga2 daemon --validate?


    Since you are getting an database error and you are at the very beginning of using the Director, meaning that you haven't configured much (I assume), I would create a new database, add a new resource to Icinga Web 2 and would re-run the Kickstart wizard from the Director.

  • How to add router in top down sync?

    Hi,


    it depends, if you install an Icinga 2 agent on your router then you can create a endpoint and a zone for it. The Icinga 2 agent on the router will then check the router and will report the check results and performance data to your Icinga 2 master node. If the connection between them drops, the Icinga 2 agent will continue checking and when the connection is re-established the agent will report the check results and performance data during the replay log to your master, so your master knows what was happening in the time when the connection was dropped. For this I recommend to read the Distributed Monitoring chapter in the docs https://www.icinga.com/docs/ic…6-distributed-monitoring/


    If you don't have the ability to install own packages on your router or you simply don't want it, you don't need a own endpoint and zone for it. Just create a HostObject for your router inside the specific zone and apply your services to your router HostObject. You can find examples inside the Monitoring Basic chapter https://www.icinga.com/docs/ic…asics/#hosts-and-services

  • Collect Error at Host Level for all Failing Servers and send Only one Email

    Hi,

    Rnux wrote:

    I could not figure out how to collect all the failing services and Sent just one Notification (from the Host where the services belong) listing all the failing services.

    AFIAK this is not possible with the build in notification scripts. For each service that changes it (hard) state Icinga 2 will execute the service notification script. Maybe it could be done with a other notification script, which collects the failed services between a certain time.

    Rnux wrote:

    Also, in case of a certain number of services are failing (like 10 of 30), how can the Host be marked as "Down"?

    The host is marked as Down when the configured host check returns a critical state e.g. the hostalive check. What you want can be done with the Business Process module. The module collects the states of services (also hosts) and with a given rule set it calculates the state of the process node.


    https://github.com/Icinga/icingaweb2-module-businessprocess