Datadog
Connect Datadog logs to TraceX with an API key and an application key with logs_read_data, so investigations can search logs around an incident.
Search Datadog logs by customer, order or request id, and around the time an incident started.
Why connect Datadog
Section titled “Why connect Datadog”Logs are where a failure leaves its trail: the timeouts, the retries, the request that returned a 500. Without them, TraceX can tell you what the data looks like but not always what happened. With Datadog connected it can see the failure itself, how often it happened and exactly when it started, which is often the strongest evidence in a report.
Before you start
Section titled “Before you start”In Datadog, open Organization settings:
- API keys → create or copy an API key.
- Application keys → create an application key with the
logs_read_datascope. A scoped key can only read logs.
Connect
Section titled “Connect”Open Integrations → Datadog and fill in:
| Field | Value |
|---|---|
| API key | from Organization settings |
| Application key | needs logs_read_data |
| Site | datadoghq.com, datadoghq.eu, us5.datadoghq.com, … |
The site is the domain in your Datadog address bar. TraceX checks the credentials with a real read, then stores them encrypted.
How TraceX uses it
Section titled “How TraceX uses it”While investigating, and in Conversations, TraceX searches your logs in two ways:
- around the time the problem started, to see what changed in the log stream;
- for the identifiers in the issue: a customer, an order, a request id, an error message.
Thousands of log lines are hard to read, so TraceX groups them into patterns with
counts, errors first. A burst of the same failure, such as 1,240 ×
PaymentGatewayTimeout since 09:02, stands out immediately, and the report links to
example lines.
Example
Section titled “Example”Customers in the EU can’t upload files since 14:30.
TraceX searches for errors from the upload service after 14:00, groups them, and
finds 3,812 × AccessDenied: s3:PutObject starting at 14:27, right after a deploy that
changed the bucket policy. The report cites example log lines and the change.
Troubleshooting
Section titled “Troubleshooting”| Problem | What to check |
|---|---|
| The credential check fails | The key or token needs read access to logs; check the scope or role listed above and that it hasn’t expired. |
| Searches return nothing | Check the region or site, and that the log groups, index or filter you entered contain the service’s logs. |
| Logs are found but not the right ones | Narrow the filter (log groups, index pattern, stream selector) to production services. |
Remove access
Section titled “Remove access”Disconnect Datadog in Integrations, then revoke the key or credentials on the Datadog side.