I was just thinking that if you are looking for a fact that changes, then you just write a script for nagios (or whatever your monitoring system is) that can check for fact changes. You'll have to have some sort of baseline that it is checking against and then the script would run facter and check against that baseline. I was thinking that it would be more robust to keep the monitoring system asynchronous from puppet.
Rather than patching puppet or PuppetDB, I think you should just periodically query (look at the files or query PuppetDB or run facter) and compare against a baseline value. You'll need to keep track of what the baseline value is, but that shouldn't be a problem. If you are going to use PuppetDB, then you can query for the nodes (http://docs.puppetlabs.com/puppetdb/0.9/spec_q_node.html) and then the facts that you want (http://docs.puppetlabs.com/puppetdb/0.9/spec_q_facts.html) On Fri, Aug 24, 2012 at 1:53 PM, Kent Shultz <kentmshu...@gmail.com> wrote: > I'd rather have the monitoring solution collect incoming facts that are > already coming to a central location rather than reaching out to the nodes. > I suppose a cronjob on the nodes could run facter, but still it seems > redundant since Facter gets executed along with each Puppet run. Also, I > plan on deploying the monitoring server on my Puppetmaster, so it's nicer to > compare new fact values to old fact values on the same server, instead of > having nodes constantly query PuppetDB to compare new fact values against > old ones. > > But yeah, if my proposed solutions involve patching the Puppet or PuppetDB > codebase, I could see how your suggestion might be simpler. It just seems > like better practice to leverage the facts that *are already coming in*. > > Can you give me an idea of what you're talking about with running facter > node-side and comparing against values in PuppetDB? > > Thanks, > Kent > > On Friday, August 24, 2012 10:29:28 AM UTC-7, Andy Parker wrote: >> >> Wouldn't having your monitoring tool watch the output of `facter >> <factname>` on the nodes that are being monitored achieve what you are >> looking for? That seems like it would be a pretty straightforward and >> uncomplicated way of doing this. >> >> On Thu, Aug 23, 2012 at 7:09 PM, Kent Shultz <kentm...@gmail.com> wrote: >> > EDIT: >> > >> > ”Id like to know the best way to collect new/incoming Fact values for a >> > node and compare it to old/previous values (i.e. from a node making a >> > puppet >> > run)” >> > >> > I meant the last parenthetical bit to come after ”new/incoming fact >> > values” >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Puppet Developers" group. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msg/puppet-dev/-/JOZlrJsa0RIJ. >> > To post to this group, send email to puppe...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-dev+...@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-dev?hl=en. >> > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-dev/-/9xfAi0KIQCMJ. > > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
