fact-based monitoring
DESCRIPTION
Your configuration management is fact-based. Your orchestration is fact-based. Is your monitoring fact-based? What does that even mean? Monitoring is very similar to configuration, at least in its expression. Configuration cares about files, services, and hosts being present and in a certain state (""nginx should be running with the following configuration""). Monitoring cares about services being present, running, and in a certain state. Both describe your infrastructure as it should be (""nginx should be running and respond in less than 200ms""). Fact-based monitoring is about being able to control monitoring with the same facts that Puppet uses (""monitor nginx latency wherever Puppet says it should run""). This is in contrast with imperative monitoring (""monitor nginx on host a, b and c"") that gets out of sync and leads to mailbox meltdowns from spurious alerts. Using open source and commercial examples, this talk will help you express your monitoring in a way that will feel very natural to your Puppet configuration.TRANSCRIPT
Fact-based Monitoringpuppetconf 2014
Alexis Lê-Quôc @alq
Alexis Lê-Quôc, @alqCTO at Datadog
Poll: Monitoring makes me…
happy proud
cry want to hide
Puppet brings Automation to Systems Management
Improve Monitoring
the way Puppet has improved
Systems Management
“The good old days”
• Your “CMDB” was Excel
• SSH in and hack away
• Little time for anything else
Then Puppet came…
• Expressive rules that capture expected result
• Using facts and classifiers, a.k.a. metadata to figure out where to apply changes
• That freed up a lot of our time*
* on a per-machine basis
–Me (just now)
“Puppet brings immunity of configuration to change in infrastructure”
I have seen this before…
–C.J. Date (1977)
“[SQL brings] immunity of application to change in storage structure and access strategy”
http://www.cs.berkeley.edu/~brewer/cs262/SystemR.pdf
SQL
• 1974 IBM introduces System R and its Structured Query Language
• Expressive rules that capture expected result
• Using facts and predicates, a.k.a. metadata to figure out what data to get
• That freed up a lot of development time
SQL
• From a time-consuming, imperative mess (“how”)
• … to expressive data queries (“what”)
SQL query
SELECT (desired facts) FROM (existing facts) WHERE (matching criteria)
Puppet
• From a time-consuming, imperative mess (“how”)
• … to expressive configuration queries (“what”)
puppet apply
CHANGE (desired facts) FROM (existing puppet facts) WHERE (matching puppet classes)
Is there a pattern?
–MCollective overview
“Break free from ever more complex naming conventions for hostnames as a means of identity. Use a very rich set of meta
data provided by each machine to address them.”
MCollective
• From a time-consuming, imperative mess (“how”)
• … to expressive orchestration queries (“what”)
mco rpc service restart service=nginx\ -F webpool=A
EXEC (desired actions) FROM (existing puppet facts) WHERE (matching puppet classes)
Back to monitoring
• Monitoring is to behavior what Puppet is to configuration
• Monitoring is to behavior what MCollective is to orchestration
Monitoring
• From a time-consuming, imperative mess (“how”)
• … to expressive monitoring queries (“what”)
Monitoring query
MONITOR (desired behavior) FROM (existing heartbeats/metrics) WHERE (matching puppet facts)
Examples• “All provisioned web servers in the production environment,
datacenter ABC must respond to queries within 200ms”
• “All PostgreSQL servers must have a postgres: bgwriter process running”
• “At least one ActiveMQ server is up to support mcollective"
• Never mention a hostname
Hosts are not the center of the monitoring universe.
Facts are!
Hosts are just places where facts occur.
The proof is in the pudding…
Hosts at the center of the universea.k.a. the Wrong Way
–Nagios Core 4 manual on monitoring clusters
“Its fairly straightforward, so hopefully you find things easy to understand…”
Host-centric: Monitor a DNS cluster
check_commandcheck_service_cluster!"DNS Cluster"!0!1!$SERVICESTATEID:host1:DNS Service$,$SERVICESTATEID:host2:DNS Service$,$SERVICESTATEID:host3:DNS Service$
Where do host1, host2, host3 come from?
Host-centric: can’t use facts directly• “Host groups solve this problem”. No, they don’t.
• Combinatorial explosion, e.g. trivially
• 4 data centers (us-1, us-2, eu, apac)
• 5 classes (web, db, cache, appserver, hadoop)
• 3 environments (test, staging, prod)
• => up to 119 materialized host groups
Nagios-bashing?
• No!
• Same fatal flaw with all host-centric monitoring tools
• Host-centric monitoring forces an extra, expensive step:
• replicate fact-based conditionals in host-centric templates
–puppet-nagios author
“Please note that this module is not for the faint of heart. Even I (the author) have my head hurt each time I have to make
modifications to it…”
Facts at the center of the universea.k.a. the Right Way
"De Revolutionibus manuscript p9b" by Nicolas Copernicus - www.bj.uj.edu.pl. Licensed under Public domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:De_Revolutionibus_manuscript_p9b.jpg#mediaviewer/File:De_Revolutionibus_manuscript_p9b.jpga
Earlier Examples
• “All provisioned web servers in the production environment, datacenter ABC must respond to queries within 200ms”
• “All PostgreSQL servers must have a postgres: bgwriter process running”
• “At least one ActiveMQ server is up to support mcollective"
In Sensu (heartbeats)• “All PostgreSQL servers must have a postgres: bgwriter process
running”
class postgres::monitoring::sensu { sensu::subscription { 'postgres': }}
• Monitoring using a fact-based query
• Is node of class “postgres” and subscribed to “postgres” or not?
• If so, it will execute the postgres check
In Datadog (metrics)• “All provisioned web servers in the production environment,
datacenter ABC must respond to queries within 200ms”$ puppet module install datadog-datadog_agent
class { ‘datadog_agent’:
api_key => …,tags => [$environment],fact_to_tags => [“datacenter”]
}include datadog_agent::integrations::nginx
In Datadog (metrics)• Monitoring using a fact-based query
• Puppet facts directly reused
max(nginx.request.latency{production,datacenter:ABC}) < 200
What to take away
Fact-based monitoring
1. Hosts are not at the center of the monitoring universe
2. Expressive monitoring uses queries
3. Monitoring queries should use Puppet facts
Thank you!