# Servicegroup definition (?)

**URL:** <https://community.icinga.com/t/servicegroup-definition/1355>\
**Category:** Icinga 2\
**Created:** [May 29, 2019, 1:33pm UTC](https://community.icinga.com/t/servicegroup-definition/1355 "2019-05-29T13:33:21Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Fischeertrinken](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/f07891/32.png) [@Fischeertrinken](https://community.icinga.com/u/Fischeertrinken)\
**Post date:** [May 29, 2019, 1:33pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/1 "2019-05-29T13:33:21Z")

</div>

Dear community,

i have a little issue, with the migration from Icinga 1.8.4 to Icinga 2, with the servicegroups.  
Our old definition looks like :  
define servicegroup{  
servicegroup\_name Test  
members  
SER-TEST-VM-1,CPU-Load,  
SER-TEST-VM-1,MEM,  
.  
.  
}

So we got our Host with the Service-check.

But how i can migrate it to the new Icinga 2, with the “assign where” rule in the groups.conf file  
The documentation dont gives any information about it.

Best regards,  
Fischeertrinken

---

<div class="post-metadata">

**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\
**Post date:** [May 29, 2019, 2:37pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/2 "2019-05-29T14:37:58Z")

</div>

Hi,

how do your service objects/apply rules and hosts look like? That would help to get a better idea what you’re trying to achieve here. Is it about all services with a specific name being put into such a group, or do you follow a different pattern here? (Hint: Group assign is explained in the docs).

Cheers,  
Michael

---

<div class="post-metadata">

**Author:** ![bernd](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/977dab/32.png) [@bernd](https://community.icinga.com/u/bernd)\
**Post date:** [May 29, 2019, 7:36pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/3 "2019-05-29T19:36:05Z")

</div>

I think the most efficient way is to set some vars in your service objects. Based on these vars, you can create servicegroup apply rules. You don’t have to use vars - you can also apply based on the check\_command (see my example below).

Having this, newly added service objects are automatically (if you set the vars accordingly) added to the servicegroup.

For example, I have different disk check commands. I’ve created one servicegroup object for all of them:

```
object ServiceGroup "disk" {
  display_name = "Disk Checks"

  assign where match("disk*", service.check_command) || match("check_disk*", service.check_command) || match("*/check_disk", service.vars.by_ssh_command)
}

```

Maybe it’s a bit clearer having an example for hosts:

```
object HostGroup "proxmox-vms" {
  display_name = "Proxmox-VMs"

  assign where host.vars.vm == "proxmox"
}

object HostGroup "proxmox-lxcs" {
  display_name = "Proxmox-LXCs"

  assign where host.vars.lxc == "proxmox"
}

```

The hosts get included to the hostgroups if defined like the following:

```
object Host "ansible.lan" {
  import "generic-host"

  address = "192.168.2.170"

  vars.os = "Linux"
  vars.lxc = "proxmox"
}

object Host "docker1.lan" {
  import "generic-host"

  address = "192.168.2.34"

  vars.os = "Linux"
  vars.vm = "proxmox"
}

```

So when I create another lxc container it is sufficient to set the vars.lxc variable to “proxmox” to get that new host assigned to the “proxmox-lxcs” hostgroup.

---

<div class="post-metadata">

**Author:** ![Fischeertrinken](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/f07891/32.png) [@Fischeertrinken](https://community.icinga.com/u/Fischeertrinken)\
**Post date:** [June 3, 2019, 7:24am UTC](https://community.icinga.com/t/servicegroup-definition/1355/4 "2019-06-03T07:24:06Z")

</div>

Dear Michael and Bernd,  
i don’t want to configure the checks automatically. Our old Configuration looks like this:

```auto
define servicegroup{
	servicegroup_name	Test_servicegroup
	alias Test_servicegroup
	members SERVER1,PING,\\
SERVER1,CPU-Load,\\
SERVER1,FTP,\\
SERVER1,JWALK,\\
SERVER1,DISK,\\
SERVER2,PING,\\
SERVER2,CPU-Load,\\
SERVER2,FTP,\\
SERVER2,JWALK,\\
SERVER2,DISK
}

```

Can i migrate it like this: (?)

```auto
object ServiceGroup "Test_servicegroup" {
  display_name = "Test_servicegroup"

  assign where host.name == "SERVER1" || assign where match("PING",service_name]
  assign where host.name == "SERVER1" || assign where match("CPU-Load",service_name]
  assign where host.name == "SERVER1" || assign where match("JWALK",service_name]
  assign where host.name == "SERVER1" ||assign where match("DISK",service_name]
  assign where host.name == "SERVER1" || assign where match("FTP",service_name]

  assign where host.name == "SERVER2" || assign where match("PING",service_name]
  assign where host.name == "SERVER2" || assign where match("CPU-Load",service_name]
  assign where host.name == "SERVER2" || assign where match("JWALK",service_name]
  assign where host.name == "SERVER2" || assign where match("DISK",service_name]
  assign where host.name == "SERVER2" || assign where match("FTP",service_name]

}

```

Best regards

---

<div class="post-metadata">

**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\
**Post date:** [June 3, 2019, 7:33am UTC](https://community.icinga.com/t/servicegroup-definition/1355/5 "2019-06-03T07:33:43Z")

</div>

Hi,

the more `assign where` expressions are chained together, the slower the overall configuration validation becomes. Avoid that at all cost, and consider a more simple solution.

Is there a specific reason to only match this on `SERVER1` and `SERVER2`? I’d rather recommend building something like this for service names - all hosts being added later, with their services, will become part of this automatically.

Longer version for better understanding:

```auto
assign where service.name == "PING"
          || service.name == "CPU-Load"
          || service.name == "JWALK"
          || service.name == "DISK"
          || service.name == "FTP"

```

This always uses `service.name` in a duplicated fashion. The algorithm can be optimized by using a list of service names and let Icinga just evaluate whether the name is in there or not.

Simplified logic with a list and the `in` operator:

```auto
assign where service.name in ["PING", "CPU-Load", "JWALK", "DISK", "FTP"]

```

References:

- Array: [https://icinga.com/docs/icinga2/latest/doc/17-language-reference/#array](https://icinga.com/docs/icinga2/latest/doc/17-language-reference/#array)
- in operator: [https://icinga.com/docs/icinga2/latest/doc/17-language-reference/#operators](https://icinga.com/docs/icinga2/latest/doc/17-language-reference/#operators)

Cheers,  
Michael

---

<div class="post-metadata">

**Author:** ![Fischeertrinken](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/f07891/32.png) [@Fischeertrinken](https://community.icinga.com/u/Fischeertrinken)\
**Post date:** [June 3, 2019, 7:52am UTC](https://community.icinga.com/t/servicegroup-definition/1355/6 "2019-06-03T07:52:11Z")

</div>

Hi,

my example wasn’t the best i think, the main problem is that, there are a lot of checks for a special software from us. And there are some hosts, with complete different checks, they have to be together to monitor the backend of the software.  
So it is important for me, that i can connect one host, with one service\_check\_command, with another host and one service\_check\_command.  
I can’t post the complete orignal configuration, cause it would be against our data privacy.

The question is, is there an easy way, like in Icinga 1.8. just to add the services from one host to a servicegroup, without any assign-rules?

Best regards

---

<div class="post-metadata">

**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\
**Post date:** [June 3, 2019, 9:37am UTC](https://community.icinga.com/t/servicegroup-definition/1355/7 "2019-06-03T09:37:29Z")

</div>

Hi,

wondering why you need so many service groups in general then … is it for better visualization in your frontend? Modern best practices involve custom variables and host groups.

If the service groups are for instrumenting a different combined cluster check, I would truly recommend to define a custom variable (or more) and rely on that.

Icinga 2 doesn’t support direct group members via a long list of names and name tuples. Either use the assign rules, or specify the service group membership via the `groups` attribute directly on the [service object](https://icinga.com/docs/icinga2/latest/doc/09-object-types/#service).

Cheers,  
Michael

---

<div class="post-metadata">

**Author:** ![Fischeertrinken](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/f07891/32.png) [@Fischeertrinken](https://community.icinga.com/u/Fischeertrinken)\
**Post date:** [June 3, 2019, 1:35pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/8 "2019-06-03T13:35:22Z")

</div>

I found a better solution, and this would is Icinga Buisness Process Modelling, that is what we needed. But thanks for your help!

Best regards

---

<div class="post-metadata">

**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\
**Post date:** [June 3, 2019, 1:40pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/9 "2019-06-03T13:40:44Z")

</div>

Ah ok. I would have come to that after getting towards the check direction. Next time, please mention that intention sooner 🙂

Cheers,  
Michael

---

<div class="post-metadata">

**Author:** ![bernd](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/977dab/32.png) [@bernd](https://community.icinga.com/u/bernd)\
**Post date:** [June 4, 2019, 4:13pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/10 "2019-06-04T16:13:04Z")

</div>

Hi,  
Michael already covered the performance issues about your assign rules. I just like to add some notes about the syntax if someone likes to copy some parts of your snippet.

You can replace `match("PING",service_name]` with `service.name == "PING"` if you don’t need [wildcard pattern matching](https://icinga.com/docs/icinga2/latest/doc/18-library-reference/#global-functions-match) (you don’t use `*` or `?`).

`||` in assign rules means _or_. So when you specify `assign where host.name == "SERVER1" || service.name == "PING"` the service group is assigned if the host name matches or the service name (or both). I think what you originally meant was `assign where host.name == "SERVER1" && service.name == "PING"` (only assign if both conditions evaluate to true using the `&&` operator).

Kind regards,  
Bernd

---

<div class="post-metadata">

**Author:** ![vbits](https://community.icinga.com/letter_avatar_proxy/v4/letter/v/90db22/32.png) [@vbits](https://community.icinga.com/u/vbits)\
**Post date:** [August 12, 2021, 12:02pm UTC](https://community.icinga.com/t/servicegroup-definition/1355/11 "2021-08-12T12:02:49Z")

</div>

Is there any way to create a group where there are hosts and services at the same time?  
Every time we deploy I have to downtime the host and http services, specifically looking for strings in a few specific pages.

```auto
object HostGroup "FS-Deploy-PROD" {
display_name = "FS Deploy PROD"
assign where match ("*prodfs.*", host.name) || match ("*HAProxy*", host.name) || match ("*fs5*", host.vars.website_name)

```

---

<div class="post-metadata">

**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\
**Post date:** [August 16, 2021, 11:42am UTC](https://community.icinga.com/t/servicegroup-definition/1355/12 "2021-08-16T11:42:37Z")

</div>

Hi @vbits  
I would like to ask you to open a new topic for your question instead of replying to an old one like this. That way you inrease the chance of people seeing (and replying) to your question and it is a lot less likely to be overlooked.  
Thank you!
