Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added an example that uses exported resources to create a master-agent set-up using exported resources. #32

Merged
merged 1 commit into from
Dec 30, 2016

Conversation

kwisatz
Copy link
Contributor

@kwisatz kwisatz commented Dec 28, 2016

Finally found the time to create the example featuring exported zones and endpoints, as promised.

## Example 3 – Using virtual resources and collection in a master-agent set-up.


This is an (almost) complete example for a master-agent set-up using virtual resources in Puppet.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be worth making a note here that services are in this module are not be expected to be exported, only the host here. Just as a measure to avoid confused users, or poorly performing monitoring nodes.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xaque208 could you elaborate a little more on that? are you talking about icinga2::object::service in general, suggesting it should never be used as an exported resource, or are you talking about something more specific to this example3 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I can add 1-2 more sentences on services and probably also on where to define apply rules.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically I'm referring to icinga2::object::service as an exported resource, as this is the resource type that has the most room for growth in monitoring infrastructure. Essentially, you just want to get data from a node in your infrastructure to the monitoring server so that icinga knows what to monitor. If you are already exporting a host object which has a pile of vars that you care about, then you should be able to use that data to avoid exporting resources for the bulk of the service checks. The problem specifically is that the number of exports compounds as you add more nodes to the infrastructure for base system checks, and can lead to performance issues and cause people shy away from exported resources entirely.

From my use of icinga2 thus far, the apply rules here are really a saving grace, since icinga2 has a language built in to apply service checks to a host using only data that icinga2 knows about.

That said, I do have service checks that are exported, but I try to keep them relatively low. Also, I've been using Puppet for a long time, and so perhaps the issues that I've seen many moons ago are less present than they are today.

Another option is to use the puppetdbquery module to ask puppetdb direclty for information about which nodes have which classes and then use the data to determine which checks to apply to which nodes.

I only mention this because I'd like to avoid recommendations that can lead to catalog compile times increasing without remorse. And further, I'd like to give recommendations to folks, as has been done here, for how to be successful in icing2 and Puppet. That was really the only reason for my initial comment.

I've only rolled icinga2 with puppet in two infrastructures, and on the old module with hopes to migrate them to the new module. I'm happy to provide opinionated code snippets if thats helpful. I plan to be using puppet and icinga2 for quite a while, though I still need to migrate to this module.

If anyone has more modern data on this subject, I'd love to hear about it.

@zachfi
Copy link
Contributor

zachfi commented Dec 29, 2016

Oh yay! This looks great to me. +1

@kwisatz
Copy link
Contributor Author

kwisatz commented Dec 29, 2016

The update should have made the README fairly complete. I also added a few examples for service profiles (nginx, backuppc).

@kwisatz
Copy link
Contributor Author

kwisatz commented Dec 29, 2016

OK, now I messed up the PR… fixed

@bobapple
Copy link
Contributor

Merged, thank you 👍

@icingaadmin icingaadmin merged commit b156c22 into voxpupuli:master Dec 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants