Hi,
I’m new to monitoring and Icinga. So forgive my beginners asking. If I want to monitor 4 servers in a VPN from my computer (Ubuntu desktop), I have to install Icinga-Core, Icingaweb/director on each of the servers and can then simply monitor the servers via icingaweb2 from my computer via a browser. Would I have to install the plug-ins additionally on the servers? I read the documentation on the Icinga page, but I’m not sure now.
Kind Regards
Hi,
I’m new to monitoring and Icinga.
Welcome 
So forgive my beginners asking. If I want to monitor 4 servers in a VPN from
my computer (Ubuntu desktop), I have to install Icinga-Core
Yes.
Icingaweb/director
No.
on each of the servers
Icingaweb (and Director if that’s how you want to configure things) only go/es
onto “the monitoring server” (not the ones being monitored).
and can then simply monitor the servers via icingaweb2 from my computer via
a browser.
Correct.
Would I have to install the plug-ins additionally on the servers?
Yes.
I read the documentation on the Icinga page, but I’m not sure now.
Keep doing that, and let us know if you get stuck / puzzled about anything
else
Antony.
Hi,
start simple with installing the master instance first. This follows along with the installation instructions including Icinga Web and the Director. Learn about the components and ensure that everything is up and running.
I strongly recommend to use a VM to install the master, and not run that on your Ubuntu desktop.
Then start with adding the first agent host, after having read the distributed monitoring docs to first understand the hiearchy and also gather the instructions for setting up an agent. An agent doesn’t need much - the icinga2 package + plugins.
The Director lends you a hand with adding a new host (add a host template first), and mark this as agent including setup scripts/instructions.
Then add a disk check for this agent host, deploy it and check whether everything works. Once you’re done with that, dig deeper and learn about service sets and more. Then you have one host with a template, add more hosts in the same manner.
Cheers,
Michael
Out of interest, why do you recommend installing the Icinga Master on a VM?
Antony.
Resource management, and also maintenance. A desktop environment is used differently than a running monitoring server. And monitoring should run all the time, not being switched off when shutting down a desktop system.
So, I’ll follow the advice and keep it simple. One master (server1) and one to be monitored (server2).
Main target is: monitor server2 with onboard check plug ins. Servers 1 and 2 are each created as VM (Ubuntu server) on two different machines in a VPN.
I’ve installed Icinga2 and Icingaweb2+Director Module on server1. When browsing from my Laptop via Icingaweb it looks now like this.
What “Endpoint” is the director looking for? server2?
So now I need to install what on server2 everything I’ve installed on server1 except Icingaweb/director?!
Are there any tutorials out there how to configure in director to get the check information from server2 displayed in Icingaweb2 (server1).
kind regards and have mercy on my inability
Hi and welcome!
Please read this: https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/ at least up to and including “Master Setup”
It has a lot of useful information’s about how Icinga works. As the Director is based on best practices it expect some default configuration that are in place if you follow this guide and used the node wizard like shown in the example under “Master Setup”. Even if you don’t want to user master/satellite setup, this basic configuration is a good start to build your setup and using the Director.
edit: after You have done that, as conf.d is excluded, you will not find any host in icingaweb2. What you can do is to move the conf files from the conf.d folder that you want to use to /etc/icinga2/zones.d/master/. An even better way would be, to recreate the host in the Director. Keep on going, after a while you will start loving Icinga2, but the start can be a little tough from time to time 
Hmm, I did all the steps from the docs correctly. What could I have done wrong here?
After what kind of doings do you get these messages?
Can you quickly list what you have done so far?
One thing about the messages that is obvious: You used the IP address as the common name of the host/endpoint object. You should always use the hostname/fqdn there, like the node wizard suggests.
- Installed Icinga2 Core, Web2 & Director on master host?
Yes
on Master-host: Icinga2 Core, Web2 & Director
on Agent-host: Icinga2 Core and plug ins
- ran the node wizard?
Yes
- ran the kickstart wizard of the Director?
“Unable to authenticate, please check your API credentials (RestApiClient.php:149)”
Looks like the API user you used for the Director kickstart is not known (or misses permissions) to the core.
Could you use icinga2 object list --type ApiUser to verify that Icinga 2 actually knows about that user? If you have the user listed, please restart Icinga 2 to make sure the config is actually used by the core. (icinga2 object list parses the configuration on the filesystem not the one that’s actually loaded into the core. So if you change something but forget to reload Icinga 2, you’ll see the change in icinga2 object list but the core doesn’t know about it)
After running icinga2 api setup :
Object ‘root’ of type ‘ApiUser’:
% declared in ‘/etc/icinga2/conf.d/api-users.conf’, lines 4:1-4:21
- __name = “root”
- client_cn = “”
- name = “root”
- package = “_etc”
- password_hash = “”
- permissions = [ “*” ]
% = modified in ‘/etc/icinga2/conf.d/api-users.conf’, lines 8:3-8:23- source_location
- first_column = 1
- first_line = 4
- last_column = 21
- last_line = 4
- path = “/etc/icinga2/conf.d/api-users.conf”
- templates = [ “root” ]
% = modified in ‘/etc/icinga2/conf.d/api-users.conf’, lines 4:1-4:21- type = “ApiUser”
- zone = “”
and in the api-users.conf:
root@icingamaster:/etc/icinga2/conf.d# cat api-users.conf
/**
- The ApiUser objects are used for authentication against the API.
*/
object ApiUser “root” {
password = “3939…”
// client_cn = “”permissions = [ “*” ]
}
leads to this when running the Kickstart Assistent:
CURL ERROR: Failed to connect to 10.0.0.103 port 5665: Connection refused (RestApiClient.php:143)
Hi,
whenever the Director encounters a connection error, ensure that Icinga 2 is running and listening on port 5665.
netstat -an | grep 5665
https://icinga.com/docs/icinga2/latest/doc/12-icinga2-api/#authentication-test
Cheers,
Michael
And make sure that that api is enabled:
icinga2 feature list
I had a typo in the name of the endpoint. *facepalm
Do I need the node wizard at all when having the director?
Yes. The node wizard configures your Icinga 2 to allow connections via API. WIthout node wizard you have to use configuration files for your monitoring and can’t connect to other Icinga instances, too.
I’ve tested a bit and moved the conf.d to a master zone. Now I moved it back like it was before. But now the Kickstart-Assistent in director got this problem:
SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (“director”.“icinga_host”, CONSTRAINT “icinga_host_zone” FOREIGN KEY (“zone_id”) REFERENCES “icinga_zone” (“id”) ON UPDATE CASCADE), query was: DELETE FROM icinga_zone WHERE (id = ‘3’) (Pdo.php:225)
Restating Icinga2, daemon, status is ok. Do I have to install everything again or is there a solution to this problem?
You don’t need to install everything again. The worst would need to drop the director database and recreate it. But I’d assume you’ve got mixed up zone and endpoint configuration between conf files and director database.
Thanks, now it is like it was before.
Back to the node wizard (client/agent):
Please specify the request ticket generated on your Icinga 2 master (optional).
(Hint: # icinga2 pki ticket --cn ‘icingaagent’):
So what excatly am I supposed to fill in here? I’m not sure with the needed syntax here.