Posts by watermelon

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

    Interesting, thanks!

    Before, I had it like:

    $hostdisplayname - $service

    I first tried it without the hyphen (to try to make it work with the host display name instead of the hostname), but that didn't work. When I changed it to the $hostname $service configuration, it worked.

    However, this raises a question; would people want to use the host display name like this ($hostdisplayname $service)? Personally, it would be nice, although not necessary. Perhaps I'll make a feature request.

    Update: here's my feature request on github:…module-grafana/issues/109

    Hi all,

    I recently started using @Mikesch's Icingaweb2 x Grafana module. Everything works fine, but I have a question about displaying services.

    First, some background. I have multiple switches, firewalls, NAS units, etc. and am monitoring all of their interfaces. I graphed them all in Grafana, and now I want to show individual graphs for each interface in Icingaweb. I'm very close, but came across one bump in the road. See the following example:

    So, here is an example of what I have so far. As you can see, I'm currently looking at one of the services for my Cisco Catalyst switch, but my graph displays for my Buffalo NAS Unit. This is because the Buffalo NAS Unit is at the top of the list in Grafana:

    However, you can see that the Service is dynamically assigned (Port 0/1), and part of what I want. Therefore, Mike's module dynamically assigns the Service, but not the Host. Is there a way around this so that it can display the Port 0/1 graph for my Cisco Catalyst switch, and overall, dynamically show graphs for individual services?

    Here's my current configs:

    Code: /etc/icingaweb2/modules/grafana/graphs.ini
    1. [Port]
    2. dashboard = "SwitchDashboard"
    3. panelId = "1"
    4. orgId = "1"
    5. repeatable = "no"

    Also, I'm using the v1.1.10 Grafana module. I could also show my Grafana templating configs for my "SwitchDashboard" but I think that is irrelevant.

    Thanks in advance!

    Hey all,

    So I've set up Grafana with InfluxDB (v1.4.2) and it all works fine. I wanted to integrate Grafana (v4.6.2) with Icingaweb2 (v2.5.0), but It seems I'm having trouble with the configuration of the module made by Mikesch (v1.1.10) however.

    Firstly, my error is as follows: The message First parameter must either be an object or the name of existing class , followed by a stacktrace, displays whenever I click on a host/service object in Icingaweb2. My configurations are as follows:

    Code: /etc/icingaweb2/modules/grafana/graphs.ini
    1. [hostalive]
    2. dashboard = "Icinga2 with InfluxDB"
    3. panelId = "1"
    4. orgId = "1"
    5. height = "250"
    6. width = "250"
    7. repeatable = "no"

    I also tried configuring a graph to display on a service instead of host just to get something displayed, but that didn't work either.

    Any pointers? Every host I've configured has the 'hostalive' check for up/down state.

    I have a feeling I'm missing something obvious.

    UPDATE: Using this module with a dashboard with spaces in between words doesn't work. To fix my issue, I simply named my previous dashboard from "Icinga2 with InfluxDB" to something without spaces.

    Unsure if this is intended, but I'm going to post this thread anyways for awareness since I didn't see anything else like it when searching.

    I think an easier way would be to define which partition to check on the Host object instead of the Service object.

    See my example:

    Then, use the default Service definition for checking a disk:

    1. apply Service for (disk => config in host.vars.disks) {
    2. import "generic-service"
    3. check_command = "disk"
    4. vars += config
    5. }

    Doing it this way will combine all of that information into one Service. Perhaps you'd like to separate them, in which case you would replace the Host object mentioned above to something like this:

    Hmm, I just edited the plugin so that whenever it comes up with the 'no answer from host' error, the state just stays at 'OK' (which achieves the goal of the wrapped plugin call). I think this is fine for now...

    However, is it possible for Icinga to log a state description change even if the overall state is 'OK'?

    For example:

    As it is currently, Icinga will only show the state description for which it first changed from one state to another and not do what is shown above. Does this make sense to you and others?

    Your zone configs look fine. Given that you ran icinga2 node wizard (as mcktr says) on each instance, the next possible problem would be that you haven't chosen a configuration mode. Do you want to use top-down command endpoint or top-down config sync?

    As mentioned in the docs I linked my initial response, these are the two ways to go about configuring your distributed monitoring setup. The pros and cons of each are described in those docs. Personally, I use the config sync mode. Therefore, I need to create a directory for my satellite in zones.d on the master node and specify each host object to have a zone variable. For example:

    Code: /etc/icinga2/zones.d/satellite1/hosts/hosts.conf
    1. object Host "test" {
    2. import "generic-host"
    3. zone = "satellite1"
    4. address = "..."
    5. ...
    6. }

    A note on the zone: it's up to you for whether or not you want to check that host using either the master instance or the satellite. I personally use the satellite to do the checking and just have the results sent back to the master, so I specify zone = "satellite1".

    The other way (command endpoint configuration) is very similar, but I'll leave it to you to read up about it but, given your described setup, I think the config sync mode would be sufficient.

    Thanks for the input guys.

    I forgot to mention that I did enable flapping on these services, but that didn't stop the alert from showing (as dnsmichi says also).

    I increased the timeout in the script significantly (from 5 seconds to 60 seconds) but am still coming up with the same 'unknown' error.


    wrap the plugin call with different state handling in a separate script

    Perhaps a silly question, but how would I do this? Is it possible to apply logic like this:

    1. ...
    2. if (state is 'UNKNOWN' AND timeElapsed < 120s)   //state is given from the initial check from the plugin
    3. send 'OK' to icinga                            //timeElapsed is the time it takes for the check to bounce back to 'OK'
    4. else
    5. send 'UNKNOWN' to icinga
    6. ...

    Hi Diraja ,

    Welcome to our community! Whenever you ask a question, it'd be helpful to show what configurations you currently have so that we can get you a solution quicker. Specifically, show us your zone configurations on both master and satellite (in zones.conf by default) and tell us what your goal is in doing so. If you haven't read through this part in the documentation yet, I suggest doing so.

    Also, it may be helpful to look in the logs (default /var/log/icinga2/icinga2.log) to see the error you're receiving for zone configs.


    hmm, no not that I know of. The latest commit was 11 days ago as of now, if that is an indicator. I think there is a lot of work to be done to it though, I think it is kind of a sideburner project for dnsmichi.

    It works for my purposes anyway, all I want is a simple dashboard view of up/down hosts & services. (which I'm guessing is what you want as well?)

    EDIT: see mcktr's answer below mine

    All you've got to do is what sru says and create a host variable like vars.wo_renotification = 1 on any host that you don't want renotifications for and use his Notification definitions in order to achieve your goal. Basically cut and paste!

    An example, if it's not clear enough already:

    Hello all,

    I'm having this issue with some of my host and service checks randomly switching from 'OK' to 'UNKNOWN' due to possible network issues. However, I don't want this to show in my web interface. For example, see my attached picture:

    You'll notice that at random intervals, the service will switch into the UNKNOWN state and almost immediately jump back to OK (within a minute, which is my check interval). This happens for a number of services (all interface checks). I have a feeling this is an issue with the plugin I use to check interfaces, I've been using this the whole time that I've used Icinga. If so, any recommendations for alternatives for this plugin? If not, how can I stop this from displaying in my web interface?

    Thanks all!

    Your quote from the docs:


    ... in a direct or indirect way

    Indirectly means syncing your config down to your satellites from the master. Directly means locally defining on every node.


    Define director-global zone on every node.

    Why do this if you already have it defined in /var/lib/icinga2/api/zones/director-global/director/zones.conf? This is the root of your problem. Since you already have the zone defined in the director-global zone, you are duplicating your configs locally which is where that error comes from. You're basically mixing the "direct" and "indirect" ways as mentioned above.

    As for your other question, which mode of top-down configuration would you like to use? You seem to be a little confused about this, I suggest fixing your first problem and then reading up on the distributed monitoring section in the docs for more information.

    lcorsini ,

    The `global-templates` zones is a global zone that you can use for storing configuration objects that you will need across your setup (hence the name).

    For instance, say I have a host template called "generic-host", which I use for all of my hosts. If I didn't have the global-templates zone, I would have to include that template definition in each individual zone directories for my satellites. Why do that if I could have it in one zone and have it deployed across the whole distributed monitoring setup? It's better to have a distributed config rather than having to manage local configs.

    I think of it kind of like this:

    The large red square represents the global-templates zone configs, and the three smaller squares represent individual zone configs for your satellites. Say satellite1 exists in the blue square. satellite1 would get the global zone configuration AND the individual zone config for satellite1.

    Make sure you have the following zone definition in every zones.conf for each satellite/master to use global-templates:

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

    Using my method of check_by_ssh (there are alternatives), you can execute something like the following from your master server (in your case, .100):

    1. [root@icingamaster ~]# /usr/lib64/nagios/plugins/check_by_ssh -H x.x.x.105 -C '/usr/lib64/nagios/plugins/check_disk -w 10 -c 5'

    so what does this do?

    The command /usr/lib64/nagios/plugins/check_by_ssh is included in the nagios plugins suite that you most likely installed when you configured Icinga. The /usr/lib64/nagios/plugins/ directory is default installation directory for nagios plugins in Cent OS. In this directory, you'll find a bunch of other check plugins that you may also find useful.

    check_by_ssh will open an ssh session into your host (specified by the -H parameter) and execute a command (specified by the -C parameter) on that host. As you can see, the command I chose was in that same directory I mentioned above and is the check_disk plugin. You can also specify different arguments, like the -w (warning threshold) and -c (critical threshold) that you see. Once the command is executed, the ssh session is closed.

    This makes it so the disk check is checked locally on the host via SSH. You can do the same for your load check, and both checks can be easily translated into Director.

    One thing you will need to do if you'd like to implement this is to set up SSH keys from your master to your remote hosts, otherwise it won't work because you'd have to enter in a password via ssh. There's a guide on DigitalOcean for this:…how-to-set-up-ssh-keys--2


    I can remove Icinga on all hosts?

    You should be able to remove Icinga completely, unless you want those hosts to be satellites for some type of distributed monitoring setup (which I don't think you need). All you need is that plugin directory that I told you about in the beginning.

    Let me know how it turns out!