Re: [icinga-users] EventCommand not getting executed(Updated)
Acutally, both icinga2 and your event handler script are telling you
exactly what's wrong:
[2016-03-16 09:58:51 +0530] notice/PluginEventTask: Event command for
object 'openstack-in.example.com [2]!cachet-notify' (PID: 1450,
arguments: '/usr/lib64/nagios/plugins/cachet_notify'
'cachet_component' 'newtest' 'service_name' 'cachet-notify'
'service_output' 'HTTP OK: HTTP/1.0 200 OK - 33401 bytes in 0.339
second response time ' 'service_state' 'OK' 'service_state_type'
'HARD') terminated with exit code 1, output: Usage: cachet_notify
cachet_component service_name service_state service_state_type
service_output
Currently, icinga2 is calling the eventhandler this way:
'/usr/lib64/nagios/plugins/cachet_notify' 'cachet_component' 'newtest'
'service_name' 'cachet-notify' 'service_output' 'HTTP OK: HTTP/1.0 200
OK - 33401 bytes in 0.339 second response time ' 'service_state' 'OK'
'service_state_type' 'HARD'
But your eventhandler script states that it expects the following usage:
cachet_notify cachet_component service_name service_state
service_state_type service_output
So my guess is that you need to get rid of your argument keys.
Also, your eventhandler script seems to rely on a specific order of
arguments, so you should define that as well.
Greetings,
Markus
On 2016-03-16 05:57, Ankush Grover wrote:
Hi Friends,
On enabling the debug code I found out that the Event Handler is
getting execute but it was failing with code 128. On further reading
it is suggested to use arguments instead. So now the EventCommand is
object EventCommand "cachet-notify" {
import "plugin-event-command"
command = [ PluginDir + "/cachet_notify" ]
arguments = {
cachet_component = "$cachet_component$"
service_name = "$service.name [1]$"
service_state = "$service.state$"
service_state_type = "$service.state_type$"
service_output = "$service.output$"
}
vars.service.name [5] = "$service.name [1]$"
vars.service.state = "$service.state$"
vars.service.state_type = "$service.state_type$"
vars.service.output = "$service.output$"
}
With the above EventCommand the plugin now showing in the logs
"terminated with exit code 1". The plugin expect output to be
"cachet_component service_name service_state service_state_type
service_output" and I have the updated to plugin to match its
arguments based on the result.
What is the best way to receive service_name service_state
service_state_type and service_output for an Event Handler and then
pass it onto the plugin..
The Plugin is ->
HTTPS://GITHUB.COM/MPELLEGRIN/NAGIOS-EVENTHANDLER-CACHETwhich is
presently compatible with Nagios/Icinga1 but I am running Icinga2 so
trying to make the things work for Icinga2
[2016-03-16 09:58:51 +0530] notice/Process: PID 1450
('/usr/lib64/nagios/plugins/cachet_notify' 'cachet_component'
'newtest' 'service_name' 'cachet-notify' 'service_output' 'HTTP OK:
HTTP/1.0 200 OK - 33401 bytes in 0.339 second response time '
'service_state' 'OK' 'service_state_type' 'HARD') terminated with exit
code 1
[2016-03-16 09:58:51 +0530] notice/PluginEventTask: Event command for
object 'openstack-in.example.com [2]!cachet-notify' (PID: 1450,
arguments: '/usr/lib64/nagios/plugins/cachet_notify'
'cachet_component' 'newtest' 'service_name' 'cachet-notify'
'service_output' 'HTTP OK: HTTP/1.0 200 OK - 33401 bytes in 0.339
second response time ' 'service_state' 'OK' 'service_state_type'
'HARD') terminated with exit code 1, output: Usage: cachet_notify
cachet_component service_name service_state service_state_type
service_output
128 ERROR CODE LOGS
notice/PluginEventTask: Event command for object
'openstack-in.example!cachet-notify' (PID: 32500, arguments:
'/usr/lib64/nagios/plugins/cachet_notify newtest cachet-notify
CRITICAL SOFT 'CRITICAL - Socket timeout after 10 seconds'')
terminated with exit code 128, output:
execvpe(/usr/lib64/nagios/plugins/cachet_notify newtest cachet-notify
CRITICAL SOFT 'CRITICAL - Socket timeout after 10 seconds') failed: No
such file or directory
Thanks & Regards
Ankush Grover
On Tue, Mar 15, 2016 at 3:40 PM, Ankush Grover
wrote:
Hi Friends,
I have setup IcingaMaster in HA mode along with 2 Satellite Servers
all on Centos 6/7 64-bit. On one of the Satellite server i am trying
execute an event_command but some how the command is not getting
executed.
Icinga Version on Satellite server is 2.3.8 and on the Icinga Master
is 2.3.6. Presently the EventCommand and Host Configuration is local
to Icinga Satellite server.
ICINGA FEATURE LIST ON THE SATELLITE SERVER:
Disabled features: compatlog debuglog gelf icingastatus livestatus
opentsdb perfdata statusdata syslog
Enabled features: api checker command graphite ido-mysql mainlog
notification
EVENT COMMAND
object EventCommand "cachet-notify" {
import "plugin-event-command"
command = [ PluginDir + "/cachet_notify $cachet_component$
$service.name [1]$ $service.state$ $service.state_type$
$service.output$" ]
}
HOST CONFIGURATION FILE
ob
Re: [icinga-users] Agentless check on icinga2 cluster setup
I'm not sure what your question is. There are several ways to perform agentless checks of Linux operating systems, via snmpd, sshd, etc. Of course you still would need an icinga2 endpoint in the respective zones you define your hosts in. Regards, Markus On 2016-03-22 03:59, Tejas Gadaria wrote: Hi, I have icinga2 cluster setup with multiple zones with "icinga-web" I not sure how I do agentless check on crusted setup and add host. All client I am trying to monitor are One or the other Linux type of Operating system. Your will be appreciated. Thanks, Tejas ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] nrpe doesn´t work (Could not resolve hostname : Name or service not known)
I would start by running icinga2 in debug mode in foreground and filter the output: icinga2 daemon -x notice | grep nrpe Reschedule your check (or wait until it is being executed) and extract the exact commandline which will be executed by icinga2. Once you have that, go from there to identify any error. Of course, don't forget to restart icinga2 as daemon. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Recovery is being sent even if times.begin for the notification was not reached
Hello, a few nights ago a host check of ours changed from UP to DOWN due to temporary name resolution problems from our ISP. This problem lasted only a few minutes, so that our on-duty staff was not notified about the issue, since times.begin (1 hour) for the corresponding notification was not reached. However, our on-duty staff DID receive a recovery message, which is not what we intended. Should this be considered as expected behaviour or a bug? Best regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Icingaweb2, .ini configuration files and comments
On 2016-04-25 14:01, Juan Luis Font wrote: Not sure if this behavior is a feature (I understand that most of the times these files will be generated by the Icingaweb2 wizard preventing the situation I describe above) or I'm just using the wrong symbol to include comments. Icingaweb2 is using PHP's parse_ini_file function (http://php.net/manual/en/function.parse-ini-file.php) for configuration parsing which uses ; for comments. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Icingaweb2 and "apply Service for/in" services: Unable to use any feature commands such as disable notification
On 2016-04-25 18:01, Quinton Phil P wrote:
In the icingaweb2 dashboard, the ProcessCheck instance details look
like this:
ProcessCheck{ args = "-bl -q15m" process = "/usr/lib/sendmail" }
But in the icinga2.log error above, they look like this:
ProcessCheck{\n args = "-bl -q15m"\nprocess =
"/usr/lib/sendmail"\n}
You can query the actual icinga2 object name using the "icinga2 object
list" command.
Currently, you are creating the service with a complete dictionary as
its name, which is definitely not useful (and probably is also the
reason for the behaviour you are experiencing).
If you have a look at the provided default disk check example, you can
find out on how to just use the dictionary's name as service name:
apply Service for (disk => config in host.vars.disks) {
import "generic-service"
check_command = "disk"
vars += config
}
Using the => operator the dynamic variable "disk" is being assigned the
current key of the dictionary, instead of the whole dictionary.
You can read more about apply for including => here:
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/language-reference#apply-for
Hope that helps!
Regards,
Markus
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] sample /var/run/icinga2/cmd/icinga2.cmd file is needed
On 2016-06-22 19:37, Meti, Shantala (NFV BU) wrote: My requirement is: SNMP traps generated through agent need to be viewed in icingaweb2 UI. My current /var/run/icinga2/cmd/icinga2.cmd file for test alarm looks as below: PROCESS_SERVICE_CHECK_RESULT;Controller2;snmp_test_trap;2;testing = But I am not able to see the alarm in UI. === = Please can anyone suggest here It seems to me you need to enable the icinga2 "command" feature. Also, icinga2.cmd is no ordinary file which needs to be created, since it is a pipe. This pipe gets created automatically after enabling the command feature and restarting icinga2. ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Graphite only shows crit thresholds, not warn
Hello there, i have just configured enable_send_thresholds = true within Icinga2's GraphiteWriter feature. For some reason though, i can only see the crit thresholds besides the actual value in Graphite. There is also no warn whisper file, only value.wsp and crit.wsp. Using tcpdump, i have confirmed, that icinga2 ships both thresholds alongside the actual values. Does anyone have any clue why this is happening? Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Graphite only shows crit thresholds, not warn
Thanks for your input, it seems that I had too little patience :) The warning thresholds appeared af few hours after, no idea why the delay though. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Is there a way to dump config files from a running Icinga2?
On 2016-06-29 01:32, Michael Martinez wrote: Hi, I'm running Icinga2. I was editing one of my config files (template/service definitions, etc) and something got messed up and I blew away the file by accident. And, of course, I don't have a backup because I'm stupid. But Icinga is still running with the old, good working copy of the file. is there a way I can recover the file from my running instance? Maybe it keeps a cache of the file somewhere on the filesystem? Or is there a command I can issue to icinga to make it dump it's configuration? You should be able to find all current configuration files under /var/lib/icinga2/api/zones//_etc Your actual paths may vary depending on the distribution you are using. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Is there a way to dump config files from a running Icinga2?
On 2016-06-30 06:25, Michael Martinez wrote: On Tue, Jun 28, 2016 at 10:12 PM, Klaus Muth wrote: On Wed, Jun 29, 2016 at 12:27 AM, Joosten, Markus wrote: You should be able to find all current configuration files under /var/lib/icinga2/api/zones//_etc I am unable to find any such zones folder. I see a var/lib/icinga2/api folder, but it contains only a "packages" subfolder. Do you have the icinga2 feature "api" enabled on your system? ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Packages for Icinga2 Director?
Hello list, can anyone tell me if there is a plan to release the director module as a system package (rpm/deb)? Any hints are greatly appreciated. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Packages for Icinga2 Director?
Thomas, thanks alot for your comprehensive and quick answer! I guess I'll figure something out in order to properly maintain Icingaweb2 modules within our installations until then :) On 2016-07-27 12:51, Thomas Gelf wrote: Yes, but probably not as a part of the Director module itself. We want to provide a generic mechanism for all Icinga Web 2 modules. That's basically pretty easy, as creating a SPEC or a debian/rules + .install file for a module is (given their unique structure) ridiculously easy. It basically consists of "copy everything to /usr/share/icingaweb2/modules/", that's it. Usually not a single line has to be modified, no configure/automake/whatever. Configuration is stored outside of the module tree, that way they never get polluted. And packages should neither enable nor configure modules anyways. We wanted to have this since a very long time, it's just a matter of priorities. Recently we rolled out a new build server, Icinga Exchange will get new features very soon, both have been dependencies for the "package all the modules" task. We are getting closer, but there is no scheduled date right now, sorry. It currently has low priority. However, in case you already have some basic experience with creating packages (or feel comfortable with googling such things) you should perfectly be able to create them on your own right now. ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Is notification based on % possible?
On 2016-09-12 19:23, Rob DeSanno wrote:
The challenge presented to me was to somehow configure notifications
to be sent only when a certain percentage of hosts experience critical
alerts.
For example, instead of sending out a notification when every host
fails a ping check, only send one out if 10%, or more, hosts fail.
We want something a little more complicated than that but the basic
theory should be the same, assuming its possible. Anyone have any
experience or thoughts on how to go about doing this?
I have implemented something like this using check_dummy and Icinga2's
runtime macros.
Behold the following template (the basic idea is borrowed somewhere
else, can't remember where):
template Host "dummy-cluster" {
import "generic-host"
check_command = "dummy"
vars.cluster_nodes = [ ]
vars.dummy_state = {{
var up_count = 0
var down_count = 0
var cluster_nodes = macro("$cluster_nodes$")
for (node in cluster_nodes) {
if (get_host(node).state > 0) {
down_count += 1
} else {
up_count += 1
}
}
if (up_count >= 1 ) {
return 0 //at least one host responded
} else {
return 2 //no host answered
}
}}
vars.dummy_text = {{
var output = "Cluster hosts:\n"
var cluster_nodes = macro("$cluster_nodes$")
for (node in cluster_nodes) {
output += node + ": " + get_host(node).last_check_result.output +
"\n"
}
return output
}}
}
As you can see, the vars.dummy_state is always evaluated at runtime and
takes the last state of all host objects stored in vars.cluster_nodes
into account.
My template always returns UP as long as one host in vars.cluster_nodes
is UP.
You could introduce an additional var where you can define which
percentage at which everything should be considered "UP".
I instantiate the template as follows:
object Host "ClusterA" {
import "dummy-cluster"
vars.cluster_nodes = [ "HostA", "HostB", "HostC", "HostD" ]
}
Kind regards,
Markus
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Dynamic object creation within a custom function
Hello list, icinga2's documentation states the following: "The other way around you can create objects dynamically using your own global functions." See: https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/advanced-topics#use-functions-object-config Can someone point me in the right direction, how i would create an object (e.g. a TimePeriod) within my own function? Thanks & regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Dynamic object creation within a custom function
Hi again, can someone please share some insight on this topic? Unfortunately the docs don't help very much on how to create objects within my own global functions. Regards, Markus On 2017-01-09 20:25, Joosten, Markus wrote: Hello list, icinga2's documentation states the following: "The other way around you can create objects dynamically using your own global functions." See: https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/advanced-topics#use-functions-object-config Can someone point me in the right direction, how i would create an object (e.g. a TimePeriod) within my own function? Thanks & regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] host alive check command and master/satellites
On 2017-01-19 13:49, Mathieu Arnold wrote: So, I am wondering, how do I get the host's check_command to be run not on the satellite but on the master ? I guess you want to implement an external check to see if your satellite hosts are up and reachable from the master? How I understood what you are trying to implement, this is not possible. You have a host which belongs to a zone which belongs to one or more endpoints. All commands for objects in that zone can only be executed by endpoints in that zone. I have solved this issue by also having my satellite hosts in my master zone (with a reduced amount of services of course). Also, I recommend you have a look at the "cluster" and "cluster-zone" commands, which check the icinga2 connectivity between master and satellites, I would use this as host alive check command instead of SSH, if you are interested in monitoring the availability of your satellites :-) Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] host alive check command and master/satellites
On 2017-01-20 11:33, Antony Stone wrote: On Friday 20 January 2017 at 10:00:28, Joosten, Markus wrote: I have solved this issue by also having my satellite hosts in my master zone (with a reduced amount of services of course). Would you care to expand on that? How do you get one host to be in more than one zone (since I assume your satellite hosts exist in their own satellite zone, hence your use of "also" there)? I was under the impression that one EndPoint existed in only one Zone, and (unless you have an HA setup) one Zone contains only one EndPoint; further, each Host belongs to one Zone (although obviously one Zone can contain multiple Hosts). Sorry if I wrote this easy to misunderstand, one host is only member of a single zone of course. Beside the host objects in the satellite zones (the satellites checking themselves) I also create similarly named hosts in my master zone (the master checks each satellite), e.g.: - host customer001-satellite in zone master - host customer001-satellite-local in zone customer001 Hope that helps clarifying what I meant :) ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] command_endpoint on a different zone
Hi Stephan,
I don't think this is possible (yet).
There might be a workaround I just thought of (totally untested, not
sure this will work):
- you have a "backup" service attached to your backup server in your
central zone
- create a dummy service "backup" attached to the switch in your
satellite zone (using check_dummy plugin)
- copy the state and output from the original "backup" service to the
dummy one (vars.dummy_state, vars.dummy_text) using
get_service(host_name, service_name)
- if this works, you can also hide the original backup service from
icingaweb2 and disable any notifications
Though I'm not sure if you can access objects in the parent zone from an
endpoint in a satellite zone.
I'll give this a shot myself on monday :)
Regards,
Markus
On 2017-02-03 21:46, Stephan Tesch wrote:
Hi guys,
I have a problem: I've got a distributed setup with a couple of zones
like emea, apac, nafta, ... which have a parent called master. The
monitored devices with the zones work just fine, mostly using snmp.
Now,
there's a few central services that I'd like to connect to my monitored
devices. Eg. I have a switch in zone emea called switch-1 that I take a
backup of. Now I'd like to check (as a service to) switch-1 if that
backup was successful. The backup server is central, thus attached only
once within the master zone as an I2 client. The service definition
might look like this:
apply Service "backup status" {
import "generic-service"
check_command = "backup"
command_endpoint = "backup-server"
assign where host.vars.backup
}
The error that I get looks more or less like this:
critical/config: Error: Validation failed for object 'switch-1!backup
status' of type 'Service'; Attribute 'command_endpoint': Command
endpoint must be in zone 'emea' or in a direct child zone thereof.
The problem that I see: I could move the backup server to zone emea,
but
all other devices in the other zones won't be able to get that service.
Any idea how to solve this?
(If it helps, I'm running on 2.6.0)
Thanks,
Stephan
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] command_endpoint on a different zone
I've just tried to implement my approach, and it turns out I was almost
correct ;)
It is indeed possible to abuse check_dummy to "mirror" hosts and
services from a child zone to the parent zone (because the master knows
about them), but not the other way round.
Regards,
Markus
On 2017-02-03 22:01, Joosten, Markus wrote:
Hi Stephan,
I don't think this is possible (yet).
There might be a workaround I just thought of (totally untested, not
sure this will work):
- you have a "backup" service attached to your backup server in your
central zone
- create a dummy service "backup" attached to the switch in your
satellite zone (using check_dummy plugin)
- copy the state and output from the original "backup" service to the
dummy one (vars.dummy_state, vars.dummy_text) using
get_service(host_name, service_name)
- if this works, you can also hide the original backup service from
icingaweb2 and disable any notifications
Though I'm not sure if you can access objects in the parent zone from
an endpoint in a satellite zone.
I'll give this a shot myself on monday :)
Regards,
Markus
On 2017-02-03 21:46, Stephan Tesch wrote:
Hi guys,
I have a problem: I've got a distributed setup with a couple of zones
like emea, apac, nafta, ... which have a parent called master. The
monitored devices with the zones work just fine, mostly using snmp.
Now,
there's a few central services that I'd like to connect to my
monitored
devices. Eg. I have a switch in zone emea called switch-1 that I take
a
backup of. Now I'd like to check (as a service to) switch-1 if that
backup was successful. The backup server is central, thus attached
only
once within the master zone as an I2 client. The service definition
might look like this:
apply Service "backup status" {
import "generic-service"
check_command = "backup"
command_endpoint = "backup-server"
assign where host.vars.backup
}
The error that I get looks more or less like this:
critical/config: Error: Validation failed for object 'switch-1!backup
status' of type 'Service'; Attribute 'command_endpoint': Command
endpoint must be in zone 'emea' or in a direct child zone thereof.
The problem that I see: I could move the backup server to zone emea,
but
all other devices in the other zones won't be able to get that
service.
Any idea how to solve this?
(If it helps, I'm running on 2.6.0)
Thanks,
Stephan
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] your database isn't able to keep up
On 2017-02-17 23:33, Michael Martinez wrote: On Fri, Feb 17, 2017 at 1:41 PM, Tobias von der Krone wrote: That means that your database is too slow and you're queue items will steadily increase. Actually, 86 queries per second is really slow. What database are you using and what specs does your database server have? mysql-5.5, running on the same server as Icinga and Icingaweb2 - an AWS m4.large instance: 2 core 2.3 GHz Xeon E5 v3; 8GB RAM; 8GB GP2 disk at 100 IOPS. My guess would be that the 100 IOPS are the bottleneck, which obviously is not much when you already have 86 database queries per second. I'd try analyzing the system performance using iotop, vmstat and so on. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Array of host objects
Am 2017-12-21 04:20, schrieb Jayapandian Ponraj: Thanks for the reply We do heavily use apply rules based on host variables and for hostgroup definitions, but once in a while we come across a service which is spread across 2 or 3 hosts which don't share anything in common. We can go ahead add separate service definition for each of them(not preferred) or write an apply rule with a reflex matching those specific hosts. Adding plain service definition for a single host and switching over to apply rules when 2 or 3 hosts are involved feels counter-intuitive. Since service definitions will be added by many teams would like to keep it simple.. So need a simple and elegant solution keeping in mind the common pitfalls. https://www.icinga.com/2016/04/28/avoiding-common-pitfalls-with-apply-rules/ So idea is to keep it simple and avoid the pitfalls and performance issues. Hi there, I'd say there are at least a few ways to keep it simple and achieve your solution. Probably my preferred solution would be to use an explicit assign statement within your apply rule for every host: assign where host.name == "host1" assign where host.name == "host2" assign where host.name == "host3" Another possibility is to use a host group for these hosts, but to me this seems counter-intuitive as it groups hosts together which just share a service. Regards, Markus ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
