Icinga default duplicated host

Hi guys, im new to icinga, so i apologize if I am posting in wrong section.

  1. After first two days of using it to monitor hosts and intermediate devices in our network, its absolutely great!

  2. But as you expect i have small (beginner?) problem. Since i started icinga up, i have two hosts in our default Linux server group, which are the same server called Ares (or ares.ourdomain.com). Ares is the server icinga is running on, based on Debian GNU/Linux Stretch.

What i see in icinga web interface are two identical hosts for Ares, one on localhost, one on active interface.

The one on interface is defined in hosts.conf and is documented as “This is an example host based on your * local host’s FQDN.” I can edit this however i want, works great. But when i remove this hosts, icinga still shows Ares on localhost. I cant find where this host is defined, and i cant edit the checks and also i cant remove it.

What i found under the same name (ares.ourdomain.com) is zone and endpoint in zones.conf, but there is no way to edit the host (checks or whatsoever), and when i rename the Node icinga wont reload.

When i comment out all host from hosts.conf, the implicit Ares host on localhost is still present, but object list shows nothing

root@ares:/etc/icinga2# icinga2 object list --type Host
root@ares:/etc/icinga2#

Is this some basic principle I dont see useful or is there a way to remove this “implicit” host? Thank you.

Are you indicating that you have 2 different Host objects defined for that, one you’ve tried removing? Can we see your config for each?

Also, are you ultimately planning to have satellite zones, or is this a single master setup? You might want to consider building your config in zones.d and disabling the conf.d folder if you’re going to scale out that way, otherwise conf.d is fine for a single master.

1 Like

It is and it is gonna be a single master environment. At this moment there is nothing defined. And that is the problem. I did not defined that host, i cant edit it, i cant remove it. Thats my problem.

Host on the screen was in icinga from the first start and i cant remove it.

I meant from yours hosts.conf. Were you trying to do this with director or something?

1 Like

This is almost fresh install of icinga2, hosts.conf is empty (everything is commented out) while im trying to figure this out. Im not using director nor trying to set it up, all i want is to remove this one “implicit” host.

So you’ve commented out object Host NodeName as well? NodeName is described in /etc/icinga2/constants.conf as the FQDN. You could also modify that to have the public IP instead of 127.0.0.1 in the address line. I’m not sure what the benefit would be.

Can you make whatever edits you tried (or will try at this point), and paste the output of icinga2 daemon -C ? That’ll show what its complaining about.

1 Like

I commented out everything in hosts.conf, so its “empty” now. in constants.conf i tried comennt out NodeName, but icinag daemon wouldnt reload, so its in default state now.

const NodeName = "ares.ourdomain.com"
const ZoneName = "ares.ourdomain.com"

root@ares:/etc/icinga2# icinga2 daemon -C
[2019-06-10 19:37:13 +0200] information/cli: Icinga application loader (version: r2.10.5-1)
[2019-06-10 19:37:13 +0200] information/cli: Loading configuration file(s).
[2019-06-10 19:37:13 +0200] information/ConfigItem: Committing config item(s).
[2019-06-10 19:37:13 +0200] information/ApiListener: My API identity: ares.ourdomain.com
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'mail-icingaadmin' (in /etc/icinga2/conf.d/notifications.conf: 11:1-11:45) for type 'Notification' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'mail-icingaadmin' (in /etc/icinga2/conf.d/notifications.conf: 23:1-23:48) for type 'Notification' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'backup-downtime' (in /etc/icinga2/conf.d/downtimes.conf: 5:1-5:52) for type 'ScheduledDowntime' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'apt' (in /etc/icinga2/conf.d/apt.conf: 1:0-1:18) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'ping6' (in /etc/icinga2/conf.d/services.conf: 34:1-34:21) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule '' (in /etc/icinga2/conf.d/services.conf: 57:1-57:65) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule '' (in /etc/icinga2/conf.d/services.conf: 65:1-65:53) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'icinga' (in /etc/icinga2/conf.d/services.conf: 73:1-73:22) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'load' (in /etc/icinga2/conf.d/services.conf: 81:1-81:20) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'procs' (in /etc/icinga2/conf.d/services.conf: 92:1-92:21) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'swap' (in /etc/icinga2/conf.d/services.conf: 100:1-100:20) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] warning/ApplyRule: Apply rule 'users' (in /etc/icinga2/conf.d/services.conf: 108:1-108:21) for type 'Service' does not match anywhere!
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 47 Services.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 IcingaApplication.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 46 Hosts.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 FileLogger.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 2 NotificationCommands.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 NotificationComponent.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 8 HostGroups.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 ApiListener.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 3 Downtimes.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 CheckerComponent.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 3 Zones.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 ExternalCommandListener.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 Endpoint.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 2 ApiUsers.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 User.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 215 CheckCommands.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 IdoPgsqlConnection.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 1 UserGroup.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 3 ServiceGroups.
[2019-06-10 19:37:13 +0200] information/ConfigItem: Instantiated 3 TimePeriods.
[2019-06-10 19:37:13 +0200] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
[2019-06-10 19:37:13 +0200] information/cli: Finished validating the configuration file(s).

Okay, so can you try redefining that host object again? You’ll want your master running some basic checks against itself. Also, was I supposed to be seeing a duplicate in that screenshot earlier, or was that just to show that you have a host with no hosts defined?

1 Like

Yes i can redefine it (and at first start it was), but that would create the duplicate i do not want. Screen i posted was to show there is a host in Linux Servers group which i didnt define and didnt add to LinuxServer Group.

That group is a default it ships with, and since the default host object lists Linux as its OS, it puts it in there. conf.d is kind of a starter kit for you to play with while you start throwing more of your test environment in.

object HostGroup "linux-servers" {
  display_name = "Linux Servers"

  assign where host.vars.os == "Linux"
}

You shouldn’t be seeing a duplicate though. Can you reproduce the problem and take a screenshot of them both in there? Also, regarding the IP address, do the ones on the host and endpoint objects match?

1 Like

Im aware of hosts and groups principles, I even tried to change host.vars.os to “LinServer”, still implicit host is still in the group.

object Host "ares.ourdomain.com" {
  // Import the default host template defined in `templates.conf`.
  import "generic-host"
  // Specify the address attributes for checks e.g. `ssh` or `http`.
 address = "10.0.0.151"
 // Set custom attribute `os` for hostgroup assignment in `groups.conf`.
  vars.os = "LinServer"
  // Define http vhost attributes for service apply rules in `services.conf`.
  vars.http_vhosts["apt mirror"] = {
    http_uri = "/"
  }
  vars.http_vhosts["cloud"] = {
    http_uri = "http://cloud.ourdomain.com/"
  }
  // Uncomment if you've sucessfully installed Icinga Web 2.
  vars.http_vhosts["Icinga Web 2"] = {
    http_uri = "/icingaweb2"
  }
  // Define disks and attributes for service apply rules in `services.conf`.
  vars.disks["disk"] = {
    // No parameters.
  }
  vars.disks["disk /"] = {
    disk_partitions = "/"
  }
  // Define notification mail attributes for notification apply rules in `notifications.conf`.
  vars.notification["mail"] = {
    // The UserGroup `icingaadmins` is defined in `users.conf`.
    groups = [ "icingaadmins" ]
  }
}



That is odd. I didn’t even realize you could have two host objects with the same name, unless there’s something I’m missing here.

So what exactly is in zones.conf, and is anything in zones.d? At this point I’d be grepping all over this thing. If this is your master, is the master zone defined and are the other nodes children of it?

1 Like

Zones.conf is in default state viz pastebin .

zones.d contains only README file:

This directory contains configuration files for cluster zones. If you're not
running a cluster you can safely ignore this directory.

Did you define a zone/endpoint for that elsewhere? Be aware of this in icinga2.conf:

/**
 * The zones.conf defines zones for a cluster setup.
 * Not required for single instance setups.
 */
include "zones.conf"

As it is, if it’s including that file then you have an endpoint and zone each using the hostname defined in constants.conf.

Try getting more explicit about this so it matches your host object:

object Endpoint "ares.ourdomain.com" {
  host = "10.0.0.151"
}
 
object Zone "master" {
  endpoints = [ "ares.ourdomain.com" ]
}

In this case, “master” would be the standard zone name for your icinga-master, and any other clients running the daemon would list it as the parent. The starter-kit Icinga config is really just getting you ready to ping and curl a bunch of stuff.

I might expect having different IP addresses on your host and endpoint objects could confuse Icingaweb. I’ll have to pick on my test box later and see if I can reproduce this.

1 Like

Hi, thanks for the answer and sorry for the delay.
I did not define any zones or endpoint on my own, everything is as it was after installation.

I edited zones.conf as you recommended but result is still the same. I wouldnt mind seeing an EndPoint in my server group, but if it has to be there, why cant i edit its checks? It doesnt make sense to me.

If i comment out the Endpoint and zone, icinga wont reload.

ÄŤen 12 07:58:00 ares safe-reload[31871]: /etc/icinga2/features-enabled/api.conf(4):
ÄŤen 12 07:58:00 ares safe-reload[31871]: /etc/icinga2/features-enabled/api.conf(5): object ApiListener "api" {
ÄŤen 12 07:58:00 ares safe-reload[31871]:                                            ^^^^^^^^^^^^^^^^^^^^^^^^
ÄŤen 12 07:58:00 ares safe-reload[31871]: /etc/icinga2/features-enabled/api.conf(6):   //accept_config = false
ÄŤen 12 07:58:00 ares safe-reload[31871]: /etc/icinga2/features-enabled/api.conf(7):   //accept_commands = false
ÄŤen 12 07:58:00 ares safe-reload[31871]: [2019-06-12 07:58:00 +0200] critical/config: 1 error
ÄŤen 12 07:58:00 ares systemd[1]: icinga2.service: Control process exited, code=exited status=1
ÄŤen 12 07:58:00 ares systemd[1]: Reload failed for Icinga host/service/network monitoring system.

And the file contains this:

root@ares:/etc/icinga2# cat /etc/icinga2/features-enabled/api.conf
/**
 * The API listener is used for distributed monitoring setups.
 */

object ApiListener "api" {
  //accept_config = false
  //accept_commands = false

  ticket_salt = TicketSalt
}

And disabling the api feature will make icingaweb useless (no acks, no scheduled downtimes…). And even if i comment out the EndPoint and the Zone, then disable the api feature, i still can see the “implicit” host in my server host group … so I would guess it is not a Endpoint? What can it be then?

I looked into underlaying database and this implicit host is the only one with
instance_id equal to 2 (other hosts have 1) and
check_command_object_id equal to 58 (other hosts have 47).

Endpoints don’t show up as objects in Icinga web. It’s like this,

A Host is the actual thing you want see details about, this is in Icinga,
An Endpoint is just an object that says “here is a place we can execute commands”, this has to be running the Icinga daemon,
A Zone is basically a way to organize your endpoints into a hierarchy.

If your master suddenly lacks an Endpoint and Zone object, you have nothing capable of checking anything. You can have other hosts without endpoints or zones if they’re not running the Icinga daemon, basically things just receiving ping or http checks.

Was the IDO database ever manually written to? It’s supposed to be informational only on the user side; changing things in it wont actually change things in Icinga and will confuse Icingaweb outright. If you don’t have a lot of historical data because you’re still setting up and you’re seeing things out of whack (and we have a ghost who we can’t find in the real world), maybe empty it out, reimport the schema and see what happens? Or you could delete those two host records and see if they repopulate. mysql/psql dump first, obviously.

I would one last time around (I think you did this already but for safety’s sake) run icinga2 object list --type Host and make sure you don’t see a second one before messing with IDO.

1 Like

I already did object list for types and there were no hosts which were not defined in hosts.conf.

Since installation i did not manually edit the database … until now.

I turned of the icinga deamon, created copy of the icinga_hosts table, inserted row with the “implicit” host and deleted it from original hosts table. After the dump, of course.

After that icinga started successfully, there is no indication of any problem, except that Linux servers group now counts three hosts, while it shows only two (both defined in hosts.conf). Service count is allright.

So i would mark this as “kind of solved” i guess.
Thank you for your time and help, its very appreciated.

1 Like

Haha, glad to help. But yeah it probably has another object referencing it and we’ve potentially made a mess. If this isn’t fully in production and you’re not worried about your state/notification history, I’d clean house and reimport the schema, because this was clearly a bad insertion into your database at some point (not by you, but by some confused process somewhere).

Fwiw this is so not typical behavior and hopefully it didn’t leave a bad first impression.

If Im in position to have bad first impression, then I wasnt aware of it. I like icingas design, webinterface, config syntax and after this i like its community. So I maybe like it now even more than before.

If I ever get into states and in Boston, I owe you a beer kind man, thank you once again. :wink:

1 Like