2. What to expect from the session
Overview
Use Cases
Concepts
How AWS X-Ray works
Getting Started
Demo
Pricing
Docs and Resources
Q&A
5. Debugging Applications
A development environment
Search through logs for clues to reproduce the issue
Set breakpoints in code to stop execution, and inspect variables and call stack
Add additional log statements as necessary and redeploy application
Repeat until the issue is fixed
Traditional debugging involves:
Traditional process of debugging doesn’t scale well to production
applications or those built using a service-oriented, microservice, or
serverless architecture
It’s tedious, repetitive, and time consuming
6. Simple to develop
Simple to test and debug
Simple to deploy
Simple to scale
Hard to iterate fast
Hard to scale efficiently
CI/CD time consuming and difficult
Reliability challenges — a problem
with a single component can take
down the whole app
Monolithic vs. service-oriented applications
Applications traditionally developed using a
monolithic architecture
Benefits: Drawbacks:
Move to service oriented (microservices) architecture to overcome the
drawbacks of a monolithic application architecture
But microservices come with their own set of challenges
7. Challenges
Services such as AWS Lambda, Amazon EC2 Container Service, AWS Elastic
Beanstalk, AWS CloudFormation, etc. make it easier to deploy and manage
applications consisting of hundreds of services
Deploying and managing service-oriented applications can
be more work compared to monolithic applications
Still hard to debug application issues in production applications due to:
Cross-service interactions
Varying log formats across services
Collecting, aggregating, and collating logs from services
8. Identify performance bottlenecks and errors
Pinpoint issues to specific service(s) in your application
Identify impact of issues on users of the application
Visualize the service call graph of your application
Solution
AWS X-Ray makes it easy to:
20. X-Ray Concepts
Trace End-to-end data related a single request across services
Segments Portions of the trace that correspond to a single service
Sub-segments Remote call or local compute sections within a service
Annotations Business data that can be used to filter traces
Metadata Business data that can be added to the trace but not used for filtering traces
Errors Normalized error message and stack trace
Sampling Percentage of requests to your application to capture as traces
22. X-Ray SDK
Enables you to get started quickly without having to manually instrument your
application code to log metadata about requests
Available for Java, .NET, and Node.js
Adds filters to automatically captures metadata for calls to:
AWS services using the AWS SDK
Non-AWS services over HTTP and HTTPS
Databases (MySQL, PostgreSQL, and Amazon DynamoDB)
Queues (Amazon SQS)
23. X-Ray Daemon
Receives data from the SDK over UDP and acts as a local buffer. Data
is flushed to the backend every second or when the local buffer fills.
Available for Amazon Linux AMI, RHEL, Ubuntu, OS X, and Windows.
Can be run anywhere as long as AWS credentials are provided (e.g.: EC2,
ECS, on premise, developer machine, etc.)
24. X-Ray API
X-Ray provides a set of APIs to enable you to send, filter, and
retrieve trace data
You can send trace data directly to the service without having to
use our SDKs (i.e.: you can write your own SDKs for languages
not currently supported)
Raw trace data is available using batch get APIs
You can build your own data analysis applications on top of the
data collected by X-Ray
26. Sampling Configuration
{
"rules": {
"move": {
"id": 1,
"service_name": "*",
"http_method": "*",
"url_path": "/api/move/*",
"fixed_target": 0,
"rate": 0.05
},
"base": {
"id": 2,
"service_name": "*",
"http_method": "*",
"url_path": "*",
"fixed_target": 1,
"rate": 0.1
}
}
}
This example defines two rules.
The first rule applies a five-percent sampling rate
with no minimum number of requests to trace to
requests with paths under /api/move
The second overrides the default sampling rule
with a rule that traces the first request each
second and 10 percent of additional requests.
33. X-Ray pricing
Free during the preview. After that:
Free tier
The first 100,000 traces recorded per month are free
The first 1,000,000 traces retrieved or scanned per month are free
Additional charges
Beyond the free tier, traces recorded cost $5.00 per million per month
Beyond the free tier, traces retrieved or scanned cost $0.50 per million per month
35. Available in preview
Go to https://aws.amazon.com/xray to sign up for the preview.
Documentation: http://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html
.NET Sample: https://github.com/awslabs/aws-xray-dotnet-webapp
Java Sample: https://github.com/awslabs/eb-java-scorekeep/tree/xray
Node.js Sample: https://github.com/awslabs/eb-node-express-sample/tree/xray
The AWS X-Ray service is available in preview today.
Debugging - X-Ray helps you locate the sources of bugs by aggregating errors, faults, and exceptions. Powerful search capabilities help you pinpoint issues.
Tracing - X-Ray collects timing and response data needed to identify high-latency services, bottlenecks, and throttling in a microservices architecture.
Service Map - X-Ray creates a map of services used by your application to provide you with a view of connections among clients, front-end service, and downstream services.
not really an APM tool, developer tool. distributed tracing. no monitoring or alarms. apm provides that. for us it is cloudwatch. apm just need agents installed. for us sdk needs to be use to instrument code to collect trace data.
We built X-Ray because customers said using opensource tools like zipkin difficult to maintain backend. besides ec2 where agents can be installed they want more access to performance info and impact by managed services like lambda, elb, dynamodb, sns etc. new relic agents can't be installed there. we plan to add x-ray support for all services in coming months.
cost effective for customers and partners to use. we expose all collected data. plan to add for php, ruby, go and python before end of the year. using apis they can use any frameworks right now.
sampling optional. control cost, better signal to noise ratio. if front end has billion request and backend 10, then overwhelmed frontend. you can choose 10% front end and 100% backend.
Red: server side errors
Yellow: client side errors
Purple: throttling in play (we can get that info about services)