Application Monitoring in a Post-Server World: Why Data Context is Critical
Download as PPTX, PDF1 like316 views
The document discusses the evolution of server computing, highlighting the rise of containerization technologies like Docker and AWS Lambda, which allow for short-lived computing containers that are created and deleted based on demand. It emphasizes the need for enhanced monitoring tools that can scale with the dynamic nature of resources in the cloud, as well as the importance of context and analytics in understanding performance and resource utilization. The document also touches on best practices for managing AWS resources and monitoring tools to optimize customer experience and cost-efficiency.
Application Monitoring in a Post-Server World: Why Data Context is Critical
- 2. 2Confidential ©2008-15 New Relic, Inc. All rights reserved.
- 3. The Decline of the Server Containerization Docker Amazon ECS Zero config infrastructure-less compute AWS Lambda ©2008-15 New Relic, Inc. All rights reserved.
- 4. Lessons learned from Docker ©2008-15 New Relic, Inc. All rights reserved.
- 5. Docker is the app’s lightweight VM Long livedShort lived VM Amazon EC2 ©2008-15 New Relic, Inc. All rights reserved.
- 6. 6 Well, that was surprising Confidential ©2008-15 New Relic, Inc. All rights reserved. 49 ACCOUNTS USING DOCKER IN LAST 24 HOURS 9,974 CONTAINERS REPORTING IN IN LAST 24 HOURS ©2008-15 New Relic, Inc. All rights reserved.
- 7. 7 Apparent usage Confidential ©2008-15 New Relic, Inc. All rights reserved. Long livedShort lived Amazon EC2 VM ©2008-15 New Relic, Inc. All rights reserved.
- 8. 8 Along came New Relic Synthetics… Confidential ©2008-15 New Relic, Inc. All rights reserved. Test external availability and performance User authored selenium scripts run in our data center Each run in its own container for security isolation Most run for under a minute ©2008-15 New Relic, Inc. All rights reserved.
- 9. 9 Disposable compute container Confidential ©2008-15 New Relic, Inc. All rights reserved. Long livedShort lived VM Amazon EC2 AWS Lambda ©2008-15 New Relic, Inc. All rights reserved.
- 10. What the heck’s going on? Confidential ©2008-15 New Relic, Inc. All rights reserved. Long livedShort lived ? ? ? VM Amazon EC2 AWS Lambda ©2008-15 New Relic, Inc. All rights reserved.
- 11. We’re Data Nerds! Confidential ©2008-15 New Relic, Inc. All rights reserved.©2008-15 New Relic, Inc. All rights reserved.
- 12. Docker container age, count vs. hours 100 10K 1M 3.7 M 83 days 333 days ©2008-15 New Relic, Inc. All rights reserved.
- 13. Docker container age, count vs. hours 100 10K 1M 3.7 M VM’ish ©2008-15 New Relic, Inc. All rights reserved.
- 14. Docker container age, count vs. hours Confidential ©2008-15 New Relic, Inc. All rights reserved. 100 10K 1M 3.7 M EC2’ish ©2008-15 New Relic, Inc. All rights reserved.
- 15. Docker container age, count vs. hours Confidential ©2008-15 New Relic, Inc. All rights reserved. 100 10K 1M 3.7 M Lambda’ish ©2008-15 New Relic, Inc. All rights reserved.
- 16. Container age, by hour under 24 hours Confidential ©2008-15 New Relic, Inc. All rights reserved. 3,741,000 46% under one hour ©2008-15 New Relic, Inc. All rights reserved.
- 17. Container age, by minute under an hour Confidential ©2008-15 New Relic, Inc. All rights reserved. 950,000 11% under one minute ©2008-15 New Relic, Inc. All rights reserved.
- 18. Container age, by minute under an hour Confidential ©2008-15 New Relic, Inc. All rights reserved. 27% under 5 minutes (versus a VM?) ©2008-15 New Relic, Inc. All rights reserved.
- 19. A surprising result Confidential ©2008-15 New Relic, Inc. All rights reserved. Long livedShort lived VMVM Amazon EC2 AWS Lambda ©2008-15 New Relic, Inc. All rights reserved.
- 20. June versus now: 5x data, same shape Confidential ©2008-15 New Relic, Inc. All rights reserved.©2008-15 New Relic, Inc. All rights reserved.
- 21. The evolution of computation as a service Short startup time (orders mag.) allows very short lived computing Containers only exist, and only for as long, as they provide value. Full stop. Containers are created Do their work Go away ©2008-15 New Relic, Inc. All rights reserved.
- 22. Elements of monitoring computation as a service A mere list of instances doesn’t scale, nor help De-provisioned containers still contribute to knowledge Raw metrics just table stakes Context matters to identify computational intent ©2008-15 New Relic, Inc. All rights reserved.
- 23. Monitoring servers ©2008-15 New Relic, Inc. All rights reserved.
- 24. Monitoring computation ©2008-15 New Relic, Inc. All rights reserved.
- 25. Low friction install New Relic AWS EC2 Beta addresses Confidential ©2008-15 New Relic, Inc. All rights reserved. Managing the dynamic nature of AWS Managing the scale of AWS ©2008-15 New Relic, Inc. All rights reserved.
- 26. Increased visibility Application Monitoring Server Monitoring EC2 AWS Metadata ©2008-15 New Relic, Inc. All rights reserved.
- 27. SaaS to SaaS monitoring, under one minute ©2008-15 New Relic, Inc. All rights reserved.
- 28. Dynamic management Provides AWS status Maintains accurate EC2 list Detects blind spots Shows instance state ©2008-15 New Relic, Inc. All rights reserved.
- 29. Context via tags and metadata as labels AWS metadata AWS custom tags ©2008-15 New Relic, Inc. All rights reserved.
- 30. EC2 instance name AWS metadata Custom label Customer example ©2008-15 New Relic, Inc. All rights reserved.
- 31. New Relic by instance type Selected label Instance count Health status ©2008-15 New Relic, Inc. All rights reserved.
- 32. New Relic by availability zone ©2008-15 New Relic, Inc. All rights reserved.
- 33. New Relic by instance type in us-east-1 ©2008-15 New Relic, Inc. All rights reserved.
- 34. Confidential ©2008-15 New Relic, Inc. All rights reserved. Future requirements for monitoring tools The obvious ones Should handle scale Should handle dynamic lifecycle of resources The less obvious ones It’s a big data problem Ops needs ways of quickly pivoting and drilling in Deeper understanding requires analytics (raw metrics not enough) ©2008-15 New Relic, Inc. All rights reserved.
- 35. We all love… … and yet Common AWS scenarios No large infrastructure build out Quickly provision Scale out to meet demand Am I under-provisioned? Am I over-provisioned? How well am I responding to demand? ©2008-15 New Relic, Inc. All rights reserved.
- 36. Prototype examples of Analytics Application and Server metrics Enriched with context from AWS As New Relic Insights events ©2008-15 New Relic, Inc. All rights reserved.
- 37. Detecting under-provisioned Hmm, that’s bad The smoking gun Aha! ©2008-15 New Relic, Inc. All rights reserved.
- 38. Detecting over-provisioned Hmm, that’s too good Aha!That’s a waste ©2008-15 New Relic, Inc. All rights reserved.
- 39. Evaluating availability elasticity Through scale out But never de-provisioned Response time settles back Increased load ©2008-15 New Relic, Inc. All rights reserved.
- 40. The Ultimate AWS control panel Confidential ©2008-15 New Relic, Inc. All rights reserved. RESOURCES CUSTOMER EXPERIENCE COST ©2008-15 New Relic, Inc. All rights reserved.
- 41. newrelic.com/aws Sign up for Beta notification AWS Monitoring resources Demo videos Come by the booth!
Editor's Notes
- #2: Welcome!
- #7: A single account spun up 20K containers yesterday but has only 600 today. An example of how the lifecycle of provisioned/dynamic resources differs from servers and applications
- #26: Managing the dynamic nature of AWS Accurate Server Monitor lists differentiate failed from deprovisioned (Grey server management) Auto-discovery of non-instrumented instances Managing the scale of AWS Grouping and filtering by AWS metadata, AWS tags SaaS to SaaS monitoring
- #27: + Browser + Synthetics == the more views the better
- #28: This is a standard way of AWS accounts to share out select data to third party tools.
- #35: Implications for monitoring tools
- #36: No large infrastructure build out Quickly provision to reduce time to market Scale out to meet demand
- #38: Jane learns that some customers are seeing poor performance from her group's application. The reports suggest it's geography specific. Jane decides to view application response time by Availability Zone. She discovers that the average response time for the application in us-west-2 is poor compared to the other AZs. She knows from previous monitoring of the application that it's compute intensive so she decides to also view CPU by AZ in order to correlate the behavior. Sure enough, she sees an elevated CPU usage in that app in us-west-2, suggesting that the poor response time is a result of insufficient resources. She next produces a chart comparing EC2 instance type for the application, by AZ. She observes that the application in us-west-2 has more t2.small's deployed as compared to the other zones, and less c4.xlarge's. Since this is a compute intensive application, she can quickly spot that the difference in response time can be traced to an incorrect use of instance types.
- #39: While investigating response time, Jane observes that the response time for us-east-1 is very short, much below the range of the other zones and shorter than SLA requires. She again looks at CPU usage by zone for that application and notes that CPU usage is quite low. Looking again at the instances deployed, she notices that us-east-1 is using c4.4xlarge's. The others are using c4.xlarge's. This appears to be a fat fingered deployment of a much more powerful (and much more expensive) instance type.
- #42: Welcome!