Some Client Services Not Communicating with Icinga Instance

I have had a little training in Icinga2 but I’m having a couple of issues.
First I have 2 (Virtual Lab) servers (osticket and graphite) that show “UP” and connected. Even some of the services on both show “OK” such as: http, ssh, ping4, etc. Both show basically the same services are okay.
The remainder of the services on osticket show “UNKNOWN” with the message “Remote icinga instance ‘osticket’ is not connected to Icinga”
The “graphite” server services show “PENDING” and never show anything different.
I am using the “conf.d” setting in icinga2.conf and have host configuration files located in /etc/icinga2/conf.d/hosts.d/
I have attached a screenshot of my errors.
Thanks for any help you can give!

Hi, could you share your from your icinga hosts? Maybe there is a Problem why “ostticket” don’t find “icinga”.

1 Like

In my experience, this is most often one of 2 things:

  1. Icinga daemon just isn’t running on that node, or;
  2. Certificate wasn’t signed.

Firewall rules would also need to be checked if you’re using one to make sure 5665 is open. If the service is up, the port is open, and you don’t see anything unsigned when you type icinga2 ca list on the master, we’ll want to skim the logs for anything about why it’s not connecting.

Wondering about the training VMs used here, where does that graphite and osticket originate from? Also, the Icinga Web 2 screenshot shows a fairly dated version before 2.5. I could imagine that Icinga 2 itself also is outdated, please add icinga2 --version from both VMs.

I ran the node wizard for all with the ticket created on Icinga Master but it doesn’t look like a ca as created. How does that get remedied?

These are VMs I created using a Vagrant init file from my training instructor. All three VMs (icinga, osticket, graphite) are the same init file source which is downloaded and installed in different respective directories. Then they are modified to have their own host name and ip address so they are treated as separate servers. The version of icinga comes from the yum / epel repository and is version 1.14.0.

Those screenshots show a mix of node list which was removed in 2.8, an ca list which has been introduced with 2.8. Seems your trainer did not do a good job in explaining this, since you’ve been receiving an Icinga 2 training, not Icinga 1. May I ask where you are located and which company did provide that training? (PM if you prefer).


icinga2 is a different package, you’ll want to check that, or use the official repos for the newest version. If you did the node wizard, then icinga2 ca list is expected to be empty (you set it up another way).

Can you check the icinga logs on both the master and osticket and see if either of them are announcing why they can’t connect to each other?

Also, hi other KDE user :smiley:

Sorry but how do I PM you? I don’t see that option…

Hi fellow KDE user, I’m still getting used to it but I’m liking it. :wink:
Anyway, from my screen shot doesn’t the icinga ca list look empty with nothing but lines in it or is it supposed to look like something else?:thinking:

Also how do I check the logs? What are all of the logs that are beneficial to look at?

After checking the downloads available for CentOS7 on the Icinga downloads page I am supposed to use what the EPEL repository has available. Am I correct?

It’s normal for the ca list to be empty if you did the thing where it said to paste the ticket command on the master and copy and paste what you get there. So that’s likely not the issue.

The logs would be /var/log/icinga2/icinga2.log and /var/log/icinga2/error.log typically, unless you’re using syslog or something else.

epel has dependencies that Icinga requires. You’ll still want to install the official Icinga repo as well.

Okay, so I added the yum install centos-release-scl repository from the download page. went back and updated all three VMs. Rebooted them. Then checked my web page. It told me I needed to follow the PHP-FPM instructions. I followed those instructions and then the page came up and revealed “Monitoring backend ‘icinga’ isn’t running”. How do I start and stop the monitoring backend?

Navigate into your message inbox and start creating one.


Apart from that, we have no idea about the current state of these VMs. I strongly suggest to start with a fresh setup of VMs, and also give them proper names, like described in the documentation. I don’t know who provided you with a training, but this doesn’t look like it was complete or helpful at all. Or did the trainer just send you here?


Hi Michael,
Unfortunately I don’t have an option to create a PM. I must be missing something. Will you please PM me and I will reply back to you and give you more information about the training. Also what is the best way to create or format host configuration files that are stored in /etc/icinga2/conf.d/hosts.d?