Observing and Understanding Behavior in Complex Systems

Transcript

1. Observing and Understanding Behavior in Complex Systems
2. THE MANY FACES OF THEO FUN WITH BEARDS AND HAIR FUCK IT ALL VENDETTA SCARY DETERMINED CAREFREE NO-FLY
 ZONE
3. Complex Systems surprisingly ubiquitous. often not complex at first thought. will dominate your entire life going forward.
4. Complex? Classic Complex Chaotic damped, driven system whose total energy exceeds the thresholds according to classical mechanics but does not meet the thresholds for chaotic systems. Operator Happiness 100
5. Chaotic Systems are sensitive to initial conditions, must be topologically mixing, its periodic orbits must be dense. ! to apply this directly
 … we must have an evolution function
 … we do not ✓ ✓ analogously ✓ with bugs
6. Where from here? Our systems are complex. Bugs make them chaotic at times. Decoupling makes them very hard to observe
 … let alone understand. ! because determining causality by observation
 is not possible.
7. Data over logs The transaction is “lost” in an asynchronous system Determination of causal effects cross-txn is impossible The best we can do is: Observe Analyze Correlate
8. Some Tenets Most people suck at monitoring. They monitor all the wrong things (somewhat bad) The don’t monitor the important things (awful)
9. Do not collect rates of things Rates are like trees making sounds falling in the forest. Direct measurement of rates leads to data loss
 and ultimately ignorance.
10. Prefer high level telemetry 1. Business drivers via KPIs, 2. Team KPIs, 3. Staff KPIs, 4. ... then telemetry from everything else.
11. Implementation Herein it gets tricky.
12. Methodology I’m going to focus on methodology
 that can be applied across whatever toolset you have.
13. Pull vs. Push Anyone who says one is better than the other is...
 WRONG. They both have their uses.
14. Reasons for pull 1. Synthesized observation is desirable. 2. Observable activity is infrequent. 3. Alterations in observation frequency are useful.
15. Reasons for push Direct observation is desirable. Discrete observed actions are useful. Discrete observed actions are frequent.
16. False reasons. Polling doesn’t scale.
17. Protocol Soup The great thing about standards is...
 there are so many to choose from.
18. Protocol Soup SNMP(v1,v2,v3) both push(trap) and pull(query) collectd(v4,v5) push only statsd push only JMX, JDBC, ICMP, DHCP, NTP, SSH, TCP, UDP, barf.
19. Color me RESTy Use JSON. HTTP(s) PUT/POST somewhere for push HTTP(s) GET something for pull
20. High-volume Data Occasionally, data velocity is beyond what’s reasonable for individual HTTP PUT/POST for each observation. 1. You can fall back to UDP (try statsd) 2. I prefer to batch them and continue to use REST
21. The real question is: “what?” What should I be monitoring? This is the best question you can ask yourself. Before you start. While you’re implementing. After you’re done.
22. The industry answer: MONITOR ALL THE THINGS! I’ll tell you this too, in fact. But we have put the cart ahead of the horse.
23. Question? If I could monitor one thing, what would it be?
 
 hint: CPU utilization on your web server ain’t it.
24. Answer: It depends on your business. If you don’t know the answer to this,
 I suggest you stop worrying about monitoring
 and start worrying about WTF your company does.
25. Here, we can’t continue. Unless I make stuff up... So, here I go makin’ stuff up.
26. Let us assume we run a web site where customers buy products
27. Monitoring purchases. So, we should monitor how many purchases were made and ensure it is within acceptable levels. ! Not so fast.
28. Actually. We want to make sure customers
 can purchase from the site and
 are purchasing from the site. This semantic different is critically important. And choosing which comes down to velocity.
29. What is this velocity thing? Displacement / time
 (i.e. purchases/second or $/second) BUT WAIT! You said:
 “Do not collect rates of things.” Correct...
 collect the displacement,
 visualize and alert on the rate.
30. So which? High velocity w/ predictably smooth trends:
 velocity is more important Low velocity or uneven arrival rates:
 measuring capability is more important
31. To rephrase If you have sufficient real data,
 observing that data works best; otherwise, you must
 synthesize data and monitor that.
32. As a tenet. Always synthesize. additionally observe real data when possible
33. More demonstrable
    (in a short session) I’ve got a web site that my customers need to visit. The business understands that we need to serve customers with at least a basic level of QoS:
 no page loads over 4s
34. Active checks.
35. A first attempt curl http://surge.omniti.com/ extract the HTTP response code if 200, we’re super good! ! Admittedly not so good.
36. A wealth of data. Synthesizing an HTTPS GET could provide: SSL Subject, validity, expiration HTTP code, Headers and Content Timings on TCP connection, first byte, full payload
37. Still, this is highly imperfect. Don’t get me wrong, they are useful.
 We use them all over the place... they are cheap. But, ideally, you want to load the page closer to the way a user does (all assets, javascript, etc.) Enter phantomjs
38. var page = require('webpage').create(); page.viewportSize = { width: 1024, height: 768 }; ! page.onError = function(err) { stats.errors++; }; page.onInitialized = function() { start = new Date(); }; page.onLoadStarted = function() { stats.load_started = new Date() - start; }; page.onLoadFinished = function() { stats.load_finished = new Date() - start; }; page.onResourceRequested = function() { stats.res++; }; page.onResourceError = function(err) { stats.res_errors++; }; page.onUrlChanged = function() { stats.url_redirects++; }; ! page.open('http://surge.omniti.com/', function(status) { stats.status = status; stats.duration = new Date() - start; console.log(JSON.stringify(stats)); phantom.exit(); });
39. var start, stats = { status: null , errors: 0 , load_started: null , load_finished: null , resources: 0 , resource_errors: 0 , url_redirects: 0 };
40. Passive checks.
41. Now for the passive stuff Some examples are Google Analytics, Omniture, etc. Statsd (out-of-the-box) and Metrics
 are mediocre approach. If we have a lot of observable data N,
 N̅ isn’t so useful,
 , |N|, q(0.5), q(0.95), q(0.99), q(0), q(1), add a lot.
42. Still... we can do better. N̅, , |N|, q(0,0.5,0.95,0.99,1) is 8 statistical aggregates Let’s look at API latencies...
 say we do 1000/s,
 that’s 60k/minute. Over a minute of time, 60k points to 8 represents...
 a lot of information loss.
43. First 60k/minute, how? statsd http puts logs etc.
44. Histograms
45. Histograms 101 This. This is a histogram. It shows the frequency of
 values within a population. Height represents frequency
46. Histograms 101 This. This is a histogram. It shows the frequency of
 values within a population. Now, height and color
 represents frequency
47. This. This is a histogram. It shows the frequency of
 values within a population. Now, only color
 represents frequency Histograms 101
48. This. This is a histogram. It shows the frequency of
 values within a population. Now, only color
 represents frequency Histograms ➠ time series at a single time interval
49. A line graph of data.
50. A heatmap of data.
51. Zoomed in on a heatmap.
52. Unfolding to a histogram.
53. Observability I don’t want to launch into a tutorial on DTrace
 despite the fact that you can simple spin up an OmniOS AMI in Amazon and have it now. Instead let’s talk about what shouldn’t happen.
54. The production questions: I wonder if that queue is backed up... Performance like that should only happen if our binary tree is badly imbalanced (replace with countless other pathologically bad precipitates of failure); I wonder if it is... It’s almost like some requests are super slow; I wonder if they are. STOP WONDERING.
55. Instrument your software Instrument your software and systems 
 and stop the wonder Do it for the kids This is simple with DTrace & a bit more work otherwise Avoiding work is not an excuse for ignorance
56. A tour through our Sauna We have this software that stores data...
 happens to store all data visualized in Circonus. We have to get data into the system. We have to get data out of the system. I don’t wonder... here’s why.
59. Data tenet. Do not collect data twice. That which you collect for visualization
 should be the same data on which you alert.
60. Thank you!