Welcome to the lesson on distributed tracing with AWS X-Ray. So far in this course, you have learned how to keep your AWS credentials secure, protect your APIs, and monitor your applications with CloudWatch. Now, we will focus on understanding how requests move through your application, especially when it uses multiple AWS services.

Distributed tracing helps you see the path a request takes as it travels through different parts of your system. This is important because modern cloud applications often use many services, and it can be hard to know where problems or slowdowns happen. AWS X-Ray is a tool that helps you trace these requests, find bottlenecks, and understand how your services work together.

Here's how the tracing flow works:

By the end of this lesson, you will know how to add AWS X-Ray tracing to a Python application that uses AWS services, so you can see detailed information about what happens when your code runs.

Before we dive into tracing, let's quickly remind ourselves how we use AWS SDKs in Python. In previous lessons, you used the boto3 library to interact with AWS services like DynamoDB and CloudWatch.

For example, to connect to a DynamoDB table, you might write:

This code creates a DynamoDB resource and gets a reference to the Orders table. You can then use this table object to read or write data.

In this lesson, we will build on this by adding tracing to these operations.

To use AWS X-Ray in your Python application, you need to install and configure the AWS X-Ray SDK. On CodeSignal, the SDK is already installed for you, but it's good to know how to do this on your own machine.

You would normally install the SDK with:

Next, you need to import and configure the X-Ray recorder in your Python code. Here's how you start:

• xray_recorder is the main object you use to record traces.
• The configure method sets the name of your service. This helps you identify traces from this part of your application.

To make tracing work with AWS services like DynamoDB, you also need to patch the libraries you use. This is done with:

• patch_all() automatically adds tracing to supported libraries, such as boto3 and requests.

On CodeSignal, the X-Ray daemon (a background process that collects trace data) is already running for you. On your own machine, you would need to download and start the X-Ray daemon as well.

Now, let's see how to add tracing to your code step by step. We will use a simple example in which we write an item to a DynamoDB table and trace this operation.

First, import the necessary modules and configure X-Ray:

• This sets up X-Ray and ensures that all supported libraries are traced.

Next, create a DynamoDB resource as you did before:

Now, let's write a function that puts an item into the Orders table. When you patched libraries with patch_all(), X-Ray already started tracing DynamoDB calls automatically. However, you can create custom subsegments to make specific operations easier to find and analyze.

A subsegment is a part of a trace that shows what happens during a specific step. You should create custom subsegments when you want to:

• Label important operations so they're easy to spot in traces (like "process-payment" or "send-notification")
• Measure specific code blocks to see exactly how long they take
• Group related operations together, even if they involve multiple service calls

The automatic tracing from patch_all() will capture the low-level AWS SDK calls, but custom subsegments let you organize traces in a way that matches your business logic. This makes it much easier to understand what's happening when you review traces later.

Let's create a custom subsegment for our DynamoDB write:

• with xray_recorder.in_subsegment('dynamo-put'): creates a subsegment named dynamo-put. Even though patch_all() will automatically trace the put_item call, this custom subsegment gives you a clear, labeled view of this specific operation in your traces.
• table.put_item(...) writes a new order to the table.

Finally, call the function and print a message when done:

When you run this code, you should see:

The trace data is sent to the X-Ray daemon, which collects and sends it to AWS X-Ray. Now let's see how to view this data.

Accessing the X-Ray Console:

1. Open the AWS Management Console and navigate to the X-Ray service
2. In the left sidebar, click on Traces to see individual requests
3. Click on Service map to see how your services connect to each other

Understanding Trace Data:

When you view traces, you'll see:

• Service Map: A visual diagram showing your application (OrdersWorker) connected to DynamoDB. Each service is shown as a node, and connections show the requests between them.
• Trace List: A table showing individual requests with their duration and status. Each trace represents one execution of your code.
• Trace Details: Click on a specific trace to see a timeline breakdown. You'll see:
  • The main segment (your OrdersWorker service)
  • Your custom dynamo-put subsegment
  • The automatic DynamoDB call captured by patch_all()
  • Timing information showing how long each part took

Important Timing Note:

Traces may take 30-60 seconds to appear in the X-Ray console after your code runs. If you don't see your traces immediately:

In this lesson, you learned how to:

• Set up AWS X-Ray in a Python application.
• Patch libraries like boto3 to automatically trace AWS service calls.
• Use subsegments to trace specific operations, such as writing to DynamoDB.

You saw how to build up the code step by step, and how each part helps you trace what your application is doing. In the practice exercises, you will get hands-on experience adding tracing to your own code and exploring the trace data.

Congratulations on reaching the end of this course! You now have a strong foundation in developer security and observability on AWS. Keep practicing and applying these skills to build secure, reliable, and observable cloud applications.