Skip to content
Open
Binary file added dotcom-rendering/docs/img.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
167 changes: 167 additions & 0 deletions dotcom-rendering/docs/traces.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,167 @@
# Traces

AWS Cloudwatch Traces are added by `createRequestTracingMiddleware`. They can be viewed in the aws Cloudwatch console

If fetched using `aws xray batch-get-traces`, the trace document will contain a `Segment` field, which contains a
`Document` field. The `Document` field is a JSON string containing the trace data we want.

An example CLI request to view a single trace document as json is:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: Would the DX of using xray improve if we add it to Grafana?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes - but that should be a job for another ticket, and might be worth discussing for cost reasons. There's a lot of data.


# Set date range

```
start="$(date -u -d '5 hours ago' +%s)"
end="$(date -u +%s)"
```

# List all services (currently only "tag-page-rendering")

```
aws xray get-service-graph \
--start-time "$start" \
--end-time "$end" \
--query 'Services[].Name'
```

# List all traces for a specific service, time range, and path

```
aws xray get-trace-summaries \
--start-time "$start" \
--end-time "$end" \
--filter-expression 'service("tag-page-rendering") AND http.url CONTAINS "/Article"' \
--query 'TraceSummaries[].Id'
```

# Get full info from a single trace

```
aws xray batch-get-traces \
--trace-ids 1-e805ee5f-1df00290c3be6a6cee361060 \
| jq -r '.Traces[0].Segments[0].Document' \
| jq '.'
```

It can be useful to add `metadata` to the trace document for use in the AWS UI.

For example, we add `subsegments[0].metadata.http.route` to the trace document so it is visible onscreen:

![img.png](img.png)

An example of a complete segment document is below. We are likely to be interested in the following sections:

- start_time (convert on a mac with `date -r <s>`)
- end_time
- metadata.default.http.request_content_length_uncompressed
- http.request.url and http.request.method

```
{
"id": "7a193b1ebdceda4b",
"name": "tag-page-rendering",
"start_time": 1787914805.575,
"trace_id": "1-e805ee5f-1df00290c3be6a6cee361060",
"end_time": 1787914805.5822752,
"fault": false,
"error": false,
"throttle": false,
"http": {
"request": {
"url": "http://tag-page-rendering-jr.local.dev-gutools.co.uk/Article",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this domain correct?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not supposed to be prod or code data. It's representative.

"method": "POST",
"user_agent": "curl/8.7.1",
"client_ip": "10.0.20.50"
},
"response": {
"status": 200,
"content_length": 0
}
},
"aws": {
"xray": {
"auto_instrumentation": false,
"sdk_version": "2.8.0",
"sdk": "opentelemetry for nodejs"
}
},
"metadata": {
"default": {
"otel.resource.process.command": "/app/server.js",
"otel.resource.telemetry.sdk.name": "opentelemetry",
"http.request_content_length_uncompressed": 3466,
"net.transport": "ip_tcp",
"http.flavor": "1.1",
"otel.resource.process.command_args": [
"/usr/bin/node",
"--require",
"/app/instrumentation.js",
"/app/server.js"
],
"otel.resource.process.runtime.description": "Node.js",
"otel.resource.host.arch": "arm64",
"otel.resource.host.name": "ip-10-0-14-80.eu-west-1.compute.internal",
"otel.resource.process.runtime.version": "24.20.0",
"otel.resource.service.name": "tag-page-rendering",
"net.host.ip": "::ffff:10.0.14.80",
"otel.resource.process.executable.path": "/usr/bin/node",
"otel.resource.telemetry.sdk.version": "2.8.0",
"otel.resource.process.executable.name": "node",
"otel.resource.process.owner": "node",
"otel.resource.process.pid": 1,
"http.status_text": "OK",
"otel.resource.process.runtime.name": "nodejs",
"otel.resource.telemetry.sdk.language": "nodejs"
}
},
"subsegments": [
{
"id": "f6779849ceecde52",
"name": "request handler",
"start_time": 1787914805.576,
"end_time": 1787914805.582691,
"fault": false,
"error": false,
"throttle": false,
"http": {
"request": {
"method": "POST"
},
"response": {
"status": 200,
"content_length": 0
}
},
"aws": {
"xray": {
"auto_instrumentation": false,
"sdk_version": "2.8.0",
"sdk": "opentelemetry for nodejs"
}
},
"metadata": {
"default": {
"http.lifecycle.event": "finish",
"http.route": "/Article",
"http.aborted": false
}
}
},
{
"id": "c36bf9dd11b68a79",
"name": "express.json",
"start_time": 1787914805.575,
"end_time": 1787914805.57525,
"fault": false,
"error": false,
"throttle": false,
"aws": {
"xray": {
"auto_instrumentation": false,
"sdk_version": "2.8.0",
"sdk": "opentelemetry for nodejs"
}
}
}
]
}
```
32 changes: 26 additions & 6 deletions dotcom-rendering/src/server/instrumentation.ts
Original file line number Diff line number Diff line change
Expand Up @@ -44,11 +44,31 @@ const sdk = new NodeSDK({

sdk.start();

// Instrumentation is preloaded into the same process as the app server.
// It should react to process SIGTERM, but not own process/server lifecycle.
let shutdownPromise: Promise<void> | null = null;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why null over undefined here?

@aug24 aug24 Sep 1, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd consider null to be correct here. It's not that it's never been defined, it's that it is currently explicitly not (yet) set.

null is more like None.


const shutdownInstrumentation = (): Promise<void> => {
if (shutdownPromise !== null) {
logger.error(
'SIGTERM received; Instrumentation SDK is already shutting down',
);
return shutdownPromise;
}

logger.info('SIGTERM received; Instrumentation SDK shutting down');
shutdownPromise = sdk.shutdown().then(
() => {
logger.info('Instrumentation SDK shut down successfully');
},
(err) => {
logger.error('Error shutting down Instrumentation SDK', err);
},
);

return shutdownPromise;
};

process.on('SIGTERM', () => {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could use more context to be able to review this change. Can you share a bit more about the thinking behind it? Is it a response to #16595 (comment) ?

A bit a context from my side. Originally I didn't add this SIGTERM handling as it's not in these docs https://opentelemetry.io/docs/languages/js/getting-started/nodejs/. I ended up adding it because I found it in https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/opentelemetry-sdk-node/README.md . Truth be told I didn't think about it with much depth!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is in response to that comment. Then a bit of a discuss.

The instrumentation should take care of closing down the instrumentation. It would be a behavioural change for it to terminate the whole process. I'm not sure if anything in the server responds to sigterm at all, but whatever we currently do should not change here.

sdk.shutdown()
.then(
() => logger.info('SDK shut down successfully'),
(err) => logger.error('Error shutting down SDK', err),
)
.finally(() => process.exit(0));
void shutdownInstrumentation();
});
Loading