For larger organizations microservice architectures have become de facto standard. Admittedly, such architectures usually come with a set of trade offs. One of these trade offs is a level of complexity that such systems introduce. A single http request may trigger a web of services working together to satisfy it. As you can imagine, this can result in a significant operational complexity.

对于大型组织而言，微服务架构已成为事实上的标准。 诚然，这样的体系结构通常需要权衡取舍。 这些折衷之一是这种系统引入的复杂度。 单个http请求可能会触发一个服务网络以共同满足该请求。 可以想象，这会导致很大的操作复杂性。

Observability tools like distributed tracing have become a critical component in observability. They allow us to trace a lifecycle of the request through the entire system. AWS X-Ray is one such tool. In this post, I will show you how you can set up X-Ray distributed tracing for your services that run in ECS. Here is what the result should look like:

诸如分布式跟踪之类的可观察性工具已成为可观察性的关键组成部分。 它们使我们能够跟踪整个系统中请求的生命周期。 AWS X-Ray就是这样一种工具。 在本文中，我将向您展示如何为在ECS中运行的服务设置X-Ray分布式跟踪。 结果如下所示：

ECS的X射线跟踪如何工作？ (How does X-Ray tracing for ECS work?)

AWS documentation does a good job explaining how tracing with X-Ray works, but let’s summarize some of the concepts here. Our goal is to assemble a big picture of what request lifecycle looks like. In order to accomplish this goal, we just need every request through the system to carry some context that would group them as the part of the same lifecycle. This is done through a tracing header id. With that in place, each time the request comes in, we can parse the context from the header and add our own context to the header for downstream requests.

AWS文档在解释X-Ray跟踪的工作原理方面做得很好，但是让我们在这里总结一些概念。 我们的目标是汇总请求生命周期的概况。 为了实现此目标，我们只需要通过系统的每个请求都携带一些上下文，这些上下文会将它们分组为同一生命周期的一部分。 这是通过跟踪标头id来完成的。 有了适当的位置，每次请求进入时，我们都可以从标头中解析上下文，并将自己的上下文添加到下游请求的标头中。

Having tracing header id to support context passing is only one part of the puzzle. The other thing that is necessary is for us to collect all the traces within the same lifecycle and put them together. This part is known as reporting. Each component needs to report its own trace info to a single entity that would build the big picture for us. The reporting within AWS X-Ray is done using X-Ray API.

具有跟踪标头ID以支持上下文传递只是难题的一部分。 另一件事是我们需要收集同一生命周期内的所有痕迹并将它们放在一起。 这部分称为报告 。 每个组件都需要向一个实体报告其自己的跟踪信息，这将为我们构建全局。 AWS X-Ray中的报告是使用X-Ray API完成的 。

This implies that we must send traces to X-Ray API every time there is a request in the system, having a potential of adding an unnecessary overhead. The way that AWS solves this problem is by introducing a notion of an X-Ray Daemon. X-Ray Daemon is a process that runs along side your service. The job of X-Ray Daemon is to collect the traces and send them to the API in a performant manner. Instead of sending an http request to an X-Ray API in a service, the instrumentation will report tracing info to the daemon using a lighter protocol (UDP) and that daemon in turn handles reporting to X-Ray API in an optimal manner.

这意味着，每次系统中有请求时，我们都必须向X-Ray API发送跟踪，这可能会增加不必要的开销。 AWS解决此问题的方法是引入X-Ray Daemon的概念。 X-Ray守护程序是一个与您的服务一起运行的过程。 X-Ray守护程序的工作是收集跟踪并将其以高性能的方式发送到API。 该工具不会向服务中的X-Ray API发送http请求，而是使用更轻量的协议(UDP)将跟踪信息报告给守护程序，然后该守护程序又以最佳方式处理向X-Ray API的报告。

Interestingly, this is how AWS handles reporting internally for other AWS resources. For example, if we turn tracing on for a lambda function, then lambda function will report traces to an X-Ray Daemon that AWS runs internally for that service.

有趣的是，这是AWS内部处理其他AWS资源报告的方式。 例如，如果打开对lambda函数的跟踪，则lambda函数会将跟踪报告到AWS在内部为该服务运行的X-Ray守护程序 。

This is what all of this looks like in practice:

在实践中，这就是所有这些：

1. Instrument our code to collect metrics. Instrumentation simply means that we parse incoming requests for external context and wrap outgoing requests with our own context. This is done using a AWS X-Ray SDK. The SDK would automatically emit data on UDP port 2000.

   检测我们的代码以收集指标。 检测只是意味着我们解析外部上下文的传入请求，并使用自己的上下文包装传出的请求。 这是使用AWS X-Ray SDK完成的 。 SDK会自动在UDP端口2000上发出数据。

2. Set up X-Ray Daemon as a side car to our service. It will listen to UDP port 2000, collect the traces and pass them to AWS X-Ray API.

   将X射线守护程序设置为我们服务的辅助工具。 它将监听UDP端口2000，收集跟踪并将其传递给AWS X-Ray API。

3. Make sure that role executing the tasks has permission to write to AWS X-Ray API.

   确保执行任务的角色具有写入AWS X-Ray API的权限。

让我们看一下代码 (Let’s see the code)

Just a reminder that this article primary concerns itself with how to do this in CDK + Typescript. How ECS works and how to set it up is out of scope. For a full example, however, refer to the repo here. But please remember that it is just an example and needs refinement to be used in production.

提醒一下，本文主要涉及如何在CDK + Typescript中执行此操作。 ECS的工作方式和设置方式超出了范围。 有关完整示例，请参阅此处的回购 。 但是请记住，这只是一个示例，需要改进才能用于生产中。

步骤1：检测我们的代码 (Step 1: Instrument our code)

The process of instrumentation depends on language of your service. In this article I will show you how to instrument a node service. Look through the docs to see if instrumentation is available for your language.

检测过程取决于您的服务语言。 在本文中，我将向您展示如何检测节点服务。 查看文档，以了解您的语言是否可用。

Node application is really easy to instrument. We just need aws-xray-sdk to do the heavy lifting. More info on it here. The code below is a very simplistic example of how a node express service can be set up.

节点应用程序确实很容易检测。 我们只需要aws-xray-sdk即可完成繁重的工作。 更多信息在这里 。 下面的代码是如何设置节点快递服务的非常简单的示例。

import * as express from 'express';
import * as AWSXRay from 'aws-xray-sdk';
import * as AWS from 'aws-sdk';const AWSSdk = AWSXRay.captureAWS(AWS);
AWSXRay.captureHTTPsGlobal(require('http'), true);
AWSXRay.captureHTTPsGlobal(require('https'), true);import axios from 'axios';const PORT = process.env.PORT || 80;
const HOST = process.env.HOST || 'localhost';const app = express();
const sns = new AWSSdk.SNS();app.get('/', (req, res) => {console.log('Healthy!');res.status(200);res.send({ status: 'Ok' });
});app.use(AWSXRay.express.openSegment('MyApp'));app.get('/pokemon', async (req, res) => {console.log('Received request...processing');try {const response = await axios.get('https://pokeapi.co/api/v2/pokemon/');console.log('Finished processing. Response: ', response.data);await sns.publish({Message: JSON.stringify(response.data),TopicArn: 'arn:aws:sns:us-east-2:<ACCOUNT>:x-ray-example-topic',}).promise();res.send(response.data);} catch (err) {res.send(err.message);}
});app.use(AWSXRay.express.closeSegment());app.listen(PORT);
console.log(`Running on http://${HOST}:${PORT}`);

From the above, line 5, sets up X-Ray SDK to trace every call to an AWS SDK. We therefore see that on line 15, we create an SNS client using our wrapper. Line 6 and 7, wrap http and https globally to handle tracing of any outgoing requests for axios.

从上面的line 5 ，设置X-Ray SDK来跟踪对AWS SDK的每次调用。 因此，我们在line 15看到，我们使用包装器创建了一个SNS客户端。 Line 6和7 ，全局包装http和https以处理对axios的所有传出请求的跟踪。

步骤2：设置X射线守护程序 (Step 2: Set up an X-Ray Daemon)

Setting up a side car with X-Ray Daemon is super simple. Assuming we run in ECS and have our node app define a task. then all we need to do is to add a container that would run X-Ray Daemon to the same task. Here is an example:

使用X射线守护程序设置边车非常简单。 假设我们在ECS中运行，并让我们的节点应用定义了任务。 那么我们要做的就是添加一个容器，该容器将在同一任务中运行X-Ray Daemon 。 这是一个例子：

const xray = taskDefinition.addContainer('xray', {image: ecs.ContainerImage.fromRegistry('amazon/aws-xray-daemon'),cpu: 32,memoryReservationMiB: 256,essential: false,
});
xray.addPortMappings({containerPort: 2000,protocol: ecs.Protocol.UDP,
});

第3步：添加权限以向X-Ray API报告跟踪 (Step 3: Add Permission to report traces to X-Ray API)

Last, but not least, the task role must have permission to do the reporting to X-Ray API. It is as simple as doing this in cdk:

最后但并非最不重要的是，任务角色必须具有向X-Ray API报告的权限。 就像在cdk中一样简单：

const taskRole = new iam.Role(this, 'TaskRole', {assumedBy: new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
});
taskRole.addManagedPolicy({managedPolicyArn: 'arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy',
});
taskRole.addManagedPolicy({managedPolicyArn: 'arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess',
});

结论：好，坏和丑 (Conclusion: The Good, the Bad and the Ugly)

That’s it! X-Ray is easy to set up and adds a ton of utility by enabling distributed tracing. However, it is not without its own downsides. For example, right now instrumenting an architecture for SNS → SQS → Lambda might not produce the desired results. The service is evolving and with time we expect the these gaps to be filled. In the meantime keep an eye on AWS announcements to stay updated!

而已！ X-Ray易于设置，并且通过启用分布式跟踪可以增加大量实用程序。 但是，它并非没有缺点。 例如，现在为SNS→SQS→Lambda检测架构可能无法产生预期的结果 。 服务在不断发展，随着时间的流逝，我们期望这些空白将得到弥补。 同时，请注意AWS公告以保持更新！