# Create seperate service checks for additional disks on windows with director

**URL:** <https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792>\
**Category:** Icinga Director\
**Created:** [April 11, 2025, 10:07am UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792 "2025-04-11T10:07:02Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![teqqy](https://community.icinga.com/user_avatar/community.icinga.com/teqqy/32/7497_2.png) [@teqqy](https://community.icinga.com/u/teqqy)\
**Post date:** [April 11, 2025, 10:07am UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/1 "2025-04-11T10:07:03Z")

</div>

Hi,

i dont like to aggregate all disk checks in one single check becasue often i need different warning and critical settings.

So is it possible to create dynamic disk checks for windows server? A bit like this one explained here: [Director Service Sets: Add service checks based on host templates - Meta Icinga / Tutorials and Guides - Icinga Community](https://community.icinga.com/t/director-service-sets-add-service-checks-based-on-host-templates/267)  
But more dynamic, because as i understood that correctly, his also aggregates all additional disks in one check.

Thanks.

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [April 11, 2025, 3:17pm UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/2 "2025-04-11T15:17:44Z")

</div>

You could prepare a service per disk and add a disks field of type datalist.  
In your apply rule you can check if host.vars.disks contains disk x to attach the service checking disk x.

Attached services allow for overwrites to change the default thresholds for particular hosts.

---

<div class="post-metadata">

**Author:** ![teqqy](https://community.icinga.com/user_avatar/community.icinga.com/teqqy/32/7497_2.png) [@teqqy](https://community.icinga.com/u/teqqy)\
**Post date:** [April 14, 2025, 7:25am UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/3 "2025-04-14T07:25:49Z")

</div>

Hi,  
thanks for your reply.  
That seems a semi-automatic process. I guess it not possible to just check by the icinga agent on the windows system and let create the services by itself?

I will give your suggesstion a try. Its better then my solution i have now.  
Thanks again!

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [April 14, 2025, 8:28am UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/4 "2025-04-14T08:28:45Z")

</div>

I would advise against creating configuration loops inside Icinga itself.

We use Ansible or a first run script to deploy the Icinga2 Agent, and thus I would use Ansible facts and a role like [ansible-collection-icinga-director/roles/ansible\_icinga at main · telekom-mms/ansible-collection-icinga-director · GitHub](https://github.com/telekom-mms/ansible-collection-icinga-director/tree/main/roles/ansible_icinga) to set the `icinga_hosts` to set the disks in the `vars`.  
The first run script poses a problem to this workflow and would lead to duplication and more that could fail at server deployment time.

Thus, I’m working on migrating the configuration of detailed settings to director imports from the CMDB.  
But I haven’t seen a company with a clean and detailed enough CMDB yet to configure single disks.

So I would end up using Ansible to refine the monitoring by connecting to the host, gathering the facts and in the end setting the custom host vars in the director.

Sometimes it’s better to take the quick wins and work in stages.

You could write a “check”-plugin, that gathers the data on the hosts and reconfigures the Icinga host objects via the director API, but IMHO this is the job of configuration management tools like Ansible, Puppet, Salt, Chef, etc. Not sure if your SOC would be happy if every host has the credential to reconfigure the monitoring lying around, though.

---

<div class="post-metadata">

**Author:** ![teqqy](https://community.icinga.com/user_avatar/community.icinga.com/teqqy/32/7497_2.png) [@teqqy](https://community.icinga.com/u/teqqy)\
**Post date:** [April 16, 2025, 10:28am UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/5 "2025-04-16T10:28:23Z")

</div>

Thanks for your opinion.  
I tried your first comment and it works quite well thanks. For the automation part i will look into in the near future.

---

<div class="post-metadata">

**Author:** ![henning](https://community.icinga.com/letter_avatar_proxy/v4/letter/h/ecae2f/32.png) [@henning](https://community.icinga.com/u/henning)\
**Post date:** [April 16, 2025, 2:06pm UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/6 "2025-04-16T14:06:17Z")

</div>

Hi Christian,  
if you have a “trusted source” for all your volumes/filesystems on your servers (a CMDB would be perfect), you could import this data via director and create single-services for each volume. I get this information from our vSphere-DB via “Virtualization (VMware)”-module.

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [April 16, 2025, 3:03pm UTC](https://community.icinga.com/t/create-seperate-service-checks-for-additional-disks-on-windows-with-director/14792/7 "2025-04-16T15:03:10Z")

</div>

The vSphereDB, I haven’t thought about getting the disk information from there.  
I would still try to use `host.vars.disks` and apply rules in favor of single-services as one could manage thresholds more efficiently. Filling `host.vars.disks` via vSphereDB director import shouldn’t be to hard.
