Monitoring¶

Below you will find some common NetEye questions, problems and solutions.

If you have a service contract, and you cannot find your problem listed below, please don’t hesitate to contact Service & Support by phone at +39 0471 56 41 01 or by email at net.support@wuerth-phoenix.com.

How to access standard logs¶

The standard Icinga2 log can be found here:

/neteye/shared/icinga2/data/log/icinga2/icinga2.log

How to enable/disable debug logging¶

To find out more information about a particular problem, you can follow the procedure below to enable debugging, then re-enact the problem in the NetEye GUI, disable logging, and finally view the log file. Take care when you do this as debug log files can quickly become very large.

icinga2-master feature enable debuglog
systemctl restart icinga2-master
< - - Debug your system here - - >
icinga2-master feature disable debuglog
systemctl restart icinga2-master

You can find the resulting log here:

/neteye/shared/icinga2/data/log/icinga2/debug.log</code>

Modules/Services do not start¶

If you encounter a module or service that does not start, the first thing to try is always to restart NetEye’s underlying services:

neteye stop
neteye start

If all services are up and the problem persists, then proceed to try the solutions below.

Icinga2 no longer starts (icinga2-master service)¶

The Icinga2 API port is busy

There may be another service that is using the Icinga2 API port (the default is the 5665). By running the following command you check if this is the case. If icinga2-master is stopped, then the following command should return 0 rows, otherwise the port is busy and thus icinga2-master cannot start:

netstat -tulpn | grep 5665

Deleting the Director configuration

You can remove the entire current Director configuration with these commands:

rm -rf /neteye/shared/icinga2/data/lib/icinga2/api/packages/director
systemctl restart icinga2-master

The next step should be to use the Director GUI to solve any problems you have in Director. Afterwards, you must remember to redeploy the Director configuration.

Sync Rule fails when trying to recreate Icinga object¶

When creating a sync rule for object import, the key column name from the parent Import Source is used as the ID during the matching phase. The key column name cannot be directly modified by adding a custom expression. Should this occur, you will see the following error:

This Sync Rule failed when last checked at 2019-01-15 09:35:08: Exception while syncing Icinga\Module\Director\Objects\IcingaHost linuxhost7.location: Trying to recreate icinga_host

To restore operation, you can either:

Remove the modification to the sync property so the index is not customized
Change the key column name to identify imported objects with a different unique key
Use instead a new field created by an import source property modifier such as Combine multiple properties

Director does not deploy when services assigned to a host have the same name¶

After adding a new service to a host, whether via an added or applied Service Set, Director does not deploy the new configuration, displaying the following error in the Deployments panel:

Error: An object with type 'Service' and name 'host.example.com!Service Name' already exists in servicesets.conf

The root cause is that Icinga requires that the names of all services included in any service set on a given host be distinct (the services themselves can be duplicated as long as they are given unique names). You can check this by going to the host indicated in the error message, clicking on the Services tab, and looking for identical names of services in the listed Service Sets.

This problem typically arises when you select the “Add Service” action on the Services tab of a particular Service Set, or use an “Assign where” rule, and then choose a service template from the Imports dropdown. Director automatically prefills the Name field with the name of the template you selected in the Imports field. You can avoid this problem by giving a unique name to the service in the Name field.