Pros and Cons of Director

Icinga Web Modules Icinga Director
1

Hi !

I don’t know if it has been done but I couldn’t find anything.

Beside a user interface, what is the difference of using config files vs the Director (in a technical way)?
Having a DB is concerning for me. It’s something else that can brake. I feel config files are more reliable somehow? I don’t know if that makes sense…

We are not concerned about people making mistake and having to track them down. Only 2 persons would be allowed to play with it.

We currently have 1100 hosts and about 8500 services.

Thank you very much :slight_smile:

2

For me it is not that much about things that can break…
If I would have a CM solution generating my configs I wouldnt care about Director, especially because of the DSL limitations of Director.
If I have to generate/ write configs for hundreds of services I would love the ease of clicking it together…

3

Sorry can you explain CM and DSL?

4

CM = configuration management
DSL = domain specific language

Icinga2 configuration syntax is a DSL with many advanced features like “if” ,“For” and other pseudo programming logic.

The director benefits are in the visibility and ease of use without the need to learn the new language, a new person can be trained in the basic principals of the tool and be sent on their merry way to provision and maintain the Icinga2 configuration, which can not be said on the test files.
But the more advanced DSL features of the language are missing in the Director and as such the files allow stronger flexibility with what you want to get, and that requires a longer learning curve.

Each has it’s benefits, and each has it’s pitfalls, so it comes down to how much delegation you want to give your users in maintaining the monitoring to their needs instead of taking it all on yourself.

p.s i hope your text files are in a source control repository and not just on the masters.

1 Like
5

Hi,

Director

You can also abstract the GUI and only let given import sources sync the required data, e.g. the typical Excel list of hosts with some custom variables for further configuration (service sets/applies, notifications, etc.). This works very well in customer setups to my knowledge.

Config Management: Puppet, etc.

On the other hand, if you’re going the config management route and having Puppet or Ansible already, it totally makes sense to directly manage the monitoring configuration during the deployment cycle of a new host, and leave away the Director.

Both?

If you need both, a user interface and automated imports, the Director also has an import source for PuppetDB.

Icinga 2 DSL

Within the Icinga 2 DSL on its own, you can heavily use programming language techniques to achieve certain tasks. This can become complicated, especially with knowledge transfer or lacking documentation. If you’re not a programmer, keep it simple stupid imho.

Thoughts

The Director needs the best strategy for deployments, should you use service sets, what about those templates being required all the time, why the need for data fields as command parameters, and so on. Once you master this, and have understood the agents and cluster parts, it is a breeze to work with. Next to the documentation, there’s trainings and workshops available to improve here.

If you can automate the rollout of new hosts and subscribe to these events or do that in a defined interval, use that power and also automate your monitoring - with or without the Director as interface to Icinga 2 Core.

If maintenance of Puppet or the Director adds a burden, and you’re feeling safe with the static configuration, go for it. Only deploying host objects with a script and very good fine granular static apply rules defined just once also work for common middle sized environments. The larger the setup gets, and the more people required to work with it, the more I recommend using the Director and CM.

Cheers,
Michael

6

+1100 Hosts, +9200 Services and it’s growing and growing, all just with the DSL.
#ICINGA2DSLLOVE

7

The Director DB breaking is not as harmful as it sounds. Without Director and its DB you can’t change your configuration until you have it restored. The rest of Icinga keeps working.

The Director is brillant for two things:

  • Delegating tasks to people who don’t know about Icinga (The monitoring admins work on the templates, services etc. Other admins add the hosts they are responsible for into director and just use what the monitoring admins created)
  • Syncing configuration from external sources (e.g. SQL databases, CMDBs, CSV files, vSphere)

It’s not so much a replacement for the DSL with all it’s power. Directors focus is to make Icinaga easy for the people who just add hosts. So it hides or simply doesn’t implement some of the more powerful things the DSL can do. That’s no flaw that’s on purpose to not confuse people.

1 Like