5. SO HOW DOES IT WORK?
One thing: exported resources.
6. WHAT CAN YOU DO WITH IT?
From the type reference: command, contact, contact group, host,
host dependency, host escalation, host group, service, service
dependency, service escalation, service group, and time period.
7. OKAY... SO WHAT DOES THAT MEAN?
It means you can call nagios_service from within a puppet
module, export that resource and then have it be collected on
your monitoring master.
9. TLDR
Define "Nagios_service <<| |>>" on your monitoring master.
Define "@@nagios_service { "check_name_${::fqdn}": }" in your
puppet code where you want checks.
10. PROS
Quick and easy.
Set it and forget it (mostly)
Never look at nagios configs again.
Easy to standup incase DR.
11. CONS
Sometimes can get out of hand.
Need to deactive and purge nodes from puppetdb.
Needs cleaning and purge from time to time.
Collecting resources can become slow.
Checks might have a window of one puppet runs to showup.
12. A SOLUTION TO SOME ISSUES.
Puppetdb-external-naginator queries puppetdb for resources
matching nagios_ and uses a jinja template to generate a new set
of nagios configs. Can be used on cron.
github/favoretti/puppetdb-external-naginator
13. QUESTIONS?
Any questions?
Feel free to contact me Ac-town@Freenode or
derrick@puppetlabs.com (0x6E3FDE15A425D256)