Transactional Monitoring for Loosely Coupled Service Architectures
•Download as PPTX, PDF•
2 likes•984 views
Todays architectures are loosely coupled, autoscaling and technology agnostic. Monitoring such deployments is a challenge and finding the rootcause for a user impacting service degradation even more. Who do you call when ‘the website is slow’? Maybe the Node.js team that provides the service broker or does the problem originate from somewhere deeper down the stack. In this talk we cover the challenges of transactional tracing and how we apply artificial intelligence to condense heaps of anomalies to one single root cause.
Recommended
More Related Content
Viewers also liked
More from Daniel Khan
More from Daniel Khan (10)
Recently uploaded
Recently uploaded (20)
Transactional Monitoring for Loosely Coupled Service Architectures
- 1. @dkhan Transactional monitoring for loosely coupled service architectures Daniel Khan Node.js Technology Lead
- 2. Some Background Who I am and what I do • Daniel Khan • @dkhan • daniel.khan@dynatrace.com • Technology lead @Dynatrace • Performance Monitoring
- 4. @dkhan 2000
- 5. @dkhan 2005
- 6. @dkhan 2016
- 7. @dkhan The new world of Microservices Teams choose their technologies freely Independent deployment Elastic scaling Service brokers Circuit breakers Unknown or obscure dependencies Randomly interwoven third party dependencies The monoliths are still somewhere
- 9. @dkhan Find the Faulty Part
- 10. @dkhan
- 11. @dkhan Find out before the User does
- 12. @dkhan So we have to Monitor
- 14. Complete Transaction Coverage Browser / Native Mobile Java/ .NET Performance Warehouse PurePath Collector Dynatrace Server Dynatrace Client Sessions Store Exported Session Offline Session Analysis Web Server/ PHP C++, VB, ADK CICS Mainframe z/OS MQ/ESB Database
- 15. @dkhan
- 16. @dkhan
- 17. @dkhan 2016
- 18. @dkhan 3MetricsperService 5MetricsperHost 5MetricsperRuntime 40Services= 120Metrics 20Hosts = 100Metrics 40Runtimes=200Metrics 420Metrics
- 19. @dkhan We cannot watch 400+ metrics So we need to find ways to automate finding anomalies
- 21. @dkhan Response Times Error Rates Load Anomaly Detection
- 23. @dkhan Distinguish Impact from Cause
- 24. Automated Analysis of Problems Service slowdown
- 25. Automated Analysis of Problems Service slowdown Dependent services slow down
- 26. Automated Analysis of Problems Service slow down Dependent service slow down Users are affected
- 27. Automated Analysis of Problems Service slow down Dependent service slow down Users are affected Analyze Dependencies
- 28. Automated Analysis of Problems Service slow down Dependent service slow down Users are affected Analyze Dependencies Exclude non-relevant services
- 29. Automated Analysis of Problems Service slow down Dependent service slow down Users are affected Analyze Dependencies Exclude non-relevant services Follow causality chain
- 30. Automated Analysis of Problems Service slow down Dependent service slow down Users are affected Analyze Dependencies Exclude non-relevant services Follow causality chain
- 32. @dkhan
- 34. @dkhan
- 35. @dkhan
- 36. @dkhan
- 37. @dkhan Thank You! | Daniel Khan | @dkhan | daniel.khan@dynatrace.com
Editor's Notes
- This is the API consumers viewpoint and that is also legit. This how APIs should work. I don’t want to care about the bigger picture. I don’t want to know the internals of the API I’m calling.
- In 2000 behind an API there was most probably some kind of monolith
- If something goes red we’ll maybe will find out. Nagios, logging, local monitoring.
- If something goes red we’ll maybe will find out. Nagios, logging, local monitoring.
- If something goes red we’ll maybe will find out. Nagios, logging, local monitoring.
- Automatic Browser Injection for UEM Eliminate guesswork across the lifecycle No averages 100% all Transactions Low maintenance Private and Public cloud environments