The Truth Is Out There... Monitoring Your Isomorphic Application

Going a full circle from web-masters to HTML developers and expert JavaScript engineers, more product teams are closing the loop by working towards full-stack JS teams capable of implementing whole (or a most of) features from scratch and even deploy it to customer facing servers. Stepping up the stack and doing more Node.js to power your back-ends, what could be more important than a good night sleep with proper monitoring set-up?

Robert will guide you through monitoring essentials to make sure your isomorphic JS application, or a set of microservices, are performing stable and power your business without hikups. Learn about tools, isomorphic logging solutions, performance and stability measurement approaches and stay confident in your uptimes.

Talk from http://css-minsk-js.by

Transcript

1. The Truth Is Out There... Robert Haritonov
 Tech Lead @ Monitoring Your Isomorphic Application
2. Zoover.nl is a travel website 3-4M Users a 
 month 10+ Years on the market
3. Rebuild everything from scratch
4. What is monitoring? • Measuring • Recording • Alerting • Visualising
5. Isomorphic == Fullstack
6. Full-stack culture
7. Monitoring: Why should you care? • Be confident in your product performance
8. "Our code generates business value when it runs, not when we write it" - Coda Hale, "Metrics, metrics, everywhere"
9. Monitoring: Why should you care? • Be confident in your product performance • Stay one step ahead, fix bugs before they affect UX • Good night sleep
10. What to monitor? • Business and tech performance • Error and Success • Throughput and availability metrics
11. Logging and Error Tracking
12. "Anything that can go wrong will go wrong" - Murphy's law
13. Error tracking services • Rollbar, Sentry, Bugsnag, New Relic... • Allow good discovery tools and alerting • Custom and auto-grouping • Source Maps, version tracking, and more...
14. Client-side logging • Propagate errors to tracking services (or own storage) • Log user actions for debugging and analytics • Provide useful context with errors (status code, description) • Keep the stack traces
15. "Undefined is not a function" - Your favourite browser
16. Bad
17. Good ✅
18. Server-side logging • Log in JSON with most context data you can get: • Code version, host, timestamp • Request parameters (logging middlewares) • Loggers like Bunyan support streams for log propagation
19. Streaming Logs
20. Isomorphic Logger
21. Isomorphic Logger
22. Isomorphic Logger
23. Isomorphic Logger
24. Isomorphic Logger
25. Notes from the field • International messages • Default Grouping could go wrong • Configure events throttling • Google bots from real devices will spawn uncommon errors
26. Configuration Tips
27. Configuration Tips
28. Configuration Tips
29. Throughput and Availability Metrics ⏱
30. "If it could affect your code’s 
 business value, add a metric." - Coda Hale, "Metrics, metrics, everywhere"
31. Tools We Use • Prometheus - metrics aggregator • Grafana - data visualizations • Pingdom - uptime monitoring
33. Prometheus • Exposes `/metrics` endpoint • Supports numerous clients, including Node.js • Exports default metrics - CPU, Memory, Event Loop Lag • And custom - Counter, Gauge, Histogram
34. Default metrics
36. Custom Metrics • Counter - for values only going up (req count, etc) • Gauge - instantaneous value of something (hardware metrics) • Histogram - the statistical distribution of values (req duration, etc)
37. Count Rendered Documents
38. Count Rendered Documents
39. Count Render Times
40. Count Render Times
41. More Prometheus Exporters • Redis, Memcached • Elasticsearch, PostgreSQL • Thumbor (image processing) • Google Analytics Reporting - infinityworks/gar-exporter
42. Alerting
43. Alerting • Pagerduty - alerts aggregations • Duty calendar
44. Duty Calendar
45. Alerting • Pagerduty - alerts aggregations • Duty calendar • Integration with Rollbar, Pingdom and other
46. Grafana Alerting
47. "Anything that can go wrong will go wrong" - Murphy's law
49. Thank you! Robert Haritonov
 Tech Lead @