From Zero To Visibility


Published on

Monitorama Portland 2014
Portland, OR
2014-05-05 to 2014-05-07

When I joined a startup already in progress as their first ops hire, what monitoring existed was a twisty maze of half-measures. The devteam dreaded oncall, and our Mean Time To Lost Sleep was way too low. Improving visibility into our infrastructure and application performance required trying new tools and changing how we thought about what we were measuring. Join me for a tragicomic journey from the vale of blissful ignorance through the straits of Nagios and into the mountains of Graphite. Thrill! to the victories. Cringe! at the rewards of hubris. Share! your own insights, because this tale never really ends.

Published in: Technology, Design

From Zero To Visibility

  1. 1. From Zero To Visibility Bridget Kromhout
  2. 2. small social commerce startup acquired in the last month by Fluid, Inc. small devteam I am the ops team
  3. 3. twisty maze of little shell scripts
  4. 4. time-consuming to understand difficult to modify doesn’t scale artisanal monitoring?!
  5. 5. New Relic pros: nice graphs application-level view good error analysis cons: slow to update many false-positive alerts high prices (better now)
  6. 6. motivating change http://99designs. com/illustrations/contests/illustration- pagerduty-161025/entries
  7. 7. as hideous as you remember
  8. 8. “Horrendous interface” “Well, it’s more “old” than anything else. At least everything is in the same place as you left it because it’s been the same since 1912.” not alone!
  9. 9. “Sensu has so many moving parts that I wouldn’t be able to sleep at night unless I set up a Nagios instance to make sure they were all running.” who watches the RabbitMQ? -- @murphy_slaw (via @lozzd)
  10. 10. hating on nagios: the middle years
  11. 11. “hadoop does not suffer from a paucity of configuration options” monitor all the ports?! best way to monitor HBase: hbck: the HBase consistency checker nagios -> bash script -> parsing output of hbck
  12. 12.
  13. 13. “Cyber” monday: 1988 called; wants its word back.
  14. 14. wow. such nosql. very webscale. “a single write operation holds the lock exclusively, and no other read or write operations may share the lock.”
  15. 15. “If it moves, we track it. Sometimes we’ll draw a graph of something that isn’t moving yet, just in case it decides to make a run for it.” Ian Malpass, Etsy
  16. 16. the (former) state of our graphite & statsd ● Graphite 0.9.9 ○ hand-rolled ○ over 2 years old ○ missing new features (Consolidate by!) ● StatsD was newish, but… ○ hand-rolled ○ running in a screen session ○ on a special snowflake box
  17. 17. this is wrong tool. never use this.
  18. 18. Community cookbooks? ● StatsD ○ ● Graphite ones good, but… ○ focus on Apache (we use nginx) ○ we haven’t moved to Chef 11 (gasp!)
  19. 19. when in doubt: tcpdump is your friend
  20. 20. carbon-aggravator (between 0.9.10 & 0.9.12) # If set true, metric received will be forwarded to # DESTINATIONS in addition to # the output of the aggregation rules. If set false # the carbon-aggregator will # only ever send the output of aggregation. FORWARD_ALL = True
  21. 21. carbonate: A+++ would clone again backfill datapoints between whisper files
  22. 22. life as a third wheel party thresholds: because not every outage is abrupt normal traffic decision to turn off decision to turn back on accidental removal
  23. 23. open-source error reporting
  24. 24. all the things StatsD Application-level error analysis Alarms for autoscaling Timers & counters Log & host-level Hadoop & HBase visualization MongoDB Graphs Time-series data graphing client-side plugins Threshold-based alarmsDashboard external checks
  25. 25. What’s next?
  26. 26. what even is ideal monitoring solution ❏ finds real problems ❏ actionable alerting ❏ usable by all ❏ …?
  27. 27. questions; comments; whatnot Twitter: @bridgetkromhout Email: In person: DevOps Days Minneapolis (