Sensu 2.0

A story of how Sensu will evolve in its next iteration. It includes exploring a long history of loving Sensu, how it can and will evolve with the industry, why the Go programming language is a natural fit for our next version and about the human side of software design.

Transcript

1. Sensu 2.0 Greg Poirier - VP of Engineering
2. What is happening?
3. Things are happening.
4. We’re rewriting Sensu.
6. Who am I? • Sensu user since 2012 • Specialized in monitoring and observability • Introduced metrics to Sensu • Superfan of Sensu
8. I <3 Sensu
10. What about my checks?
11. You do not have to rewrite plugins.
13. WHYYYYY?
14. Mechanical Sympathy
15. Human-Centered Design
16. Make things easier.
17. Easier • Reduce operational burden and complexity • API focused • Multitenancy
18. Why Go?
19. Why Go • Performance • Safety • Packaging • Developer Experience
20. Why Go: Performance • Concurrency primitives • Natively utilize multiple cores • Compiled language (Go) vs interpreted language (Ruby) • No more VM (Ruby or JVM)
21. Why Go: Developer Experience • Mechanical sympathy • Easily learned by new engineers • Uniformity
22. Why Go: Safety • Static types • Explicit error handling • Race detection
23. Why Go: Packaging • Statically linked binaries • Easy to ship in a container • Easy to package for any OS • Cross-compilation
24. gopherize.me IT ME!
25. OK. I get it.
27. MAKE EVERYTHIN G
28. Reducing Operational Burden
29. Operational Burden • Easier for current orgs to use Sensu • Easier for new orgs to use Sensu • More cost-effective monitoring solution
30. No more RabbitMQ
32. Operational Burden: Transport • Don’t have to operationalize RabbitMQ • AMQP inspired the new Sensu transport • WebSockets for the transport protocol • JSON message bodies
33. No more Redis
35. Operational Burden: Data • Redis replaced by distributed datastore: Etcd • Configuration stored within Etcd • DR and HA facilitated entirely by Sensu+Etcd
36. No more CM
37. Just kidding
39. Operational Burden: CM What does CM do? • Deploys Sensu, RabbitMQ, Redis • Configure Sensu, RabbitMQ, Redis • Deploys and configures checks
40. Operational Burden: CM • Configuration management no longer required • Read/write REST API • Assets delivered to client systems by Sensu
41. Operational Burden: CM Sensu 2.0 has the ability to deliver “assets” • Assets are specially-formed zip files • Assets are versioned • No more CM needed to deliver checks • Does not interfere with OS packages
42. Hidden costs of CM.
43. API Focused
45. API-Driven: Empowerment • All configuration • Faster time-to-change • Empower organizations
47. API-Driven: Multiple UIs - Dashboard - CLI - Choose your own adventure
50. Monitoring is Alive and Well
51. Easier Integrations: monitoring.yaml .monitoring.yaml: metrics: - name: nsq.queue_length.results assertions: - comparison: > 0 time: 5m http_check: - method: get path: /health assertions: - status: 200
52. API-Driven: Platforms • Higher order applications can be built with Sensu • Stronger integrations with IaaS/PaaS • Metrics as first-class citizens
53. Time-Series Data
54. API-Driven: Time Series Data - Still focused on being a “router” - Metrics as first-class citizen - Deep integrations with time-series databases - Metrics as a core part of monitoring with Sensu
55. RBAC & Multitenancy
56. Multitenancy • Larger orgs yield more complex setups • Organizations and Environments • RBAC allows for cross-functional cross-team information sharing
58. How do we get there?
60. • ✔ Functioning Sensu 2.0 • ✔ Multitenancy • ✔ API • ✔ Check execution • ✔ Alerting • ✔ Asset management Sensu 2.0: Alpha
61. Sensu 2.0: Future • Sensu 1.0 Feature Complete • Growing the Sensu engineering team • Metrics integrations
62. Thanks!