Comparing new Fact values to previous ones

[Kent Shultz]

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”

[Andy Parker]

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.

> --
> 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.
>

[Kent Shultz]

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

[Michael Stahnke]

On Fri, Aug 24, 2012 at 1:53 PM, Kent Shultz <kentm...@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?

I had a hair-brained idea for a while to expose fact values via SNMP,
but I never went anywhere with it.

(I realize this is tangental, but it reminded me of it)

Mike

> https://groups.google.com/d/msg/puppet-dev/-/9xfAi0KIQCMJ.

[Andy Parker]

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)

> https://groups.google.com/d/msg/puppet-dev/-/9xfAi0KIQCMJ.

[James Turnbull]

Michael Stahnke wrote:
> I had a hair-brained idea for a while to expose fact values via SNMP,
> but I never went anywhere with it.
>
> (I realize this is tangental, but it reminded me of it)
>

I wrote some code to do that - a little "fact server" that outputted
facts as JSON and allowed SNMP queries - it was pre-GH so buggered if I
can find the code now but it'd be pretty easy to recreate.

Regards

James Turnbull


--
James Turnbull
Puppet Labs
1-503-734-8571
To schedule a meeting with me: http://tungle.me/jamtur01