Logs and errors

Amazon CloudWatch

Connect Amazon CloudWatch log groups to TraceX with an IAM user limited to Logs Insights queries, so investigations can search AWS logs.

Search Amazon CloudWatch log groups with Logs Insights.

Why connect Amazon CloudWatch

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 Amazon CloudWatch 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

Create an IAM user (or role credentials) with a policy that only allows Logs Insights queries on the log groups TraceX should read:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["logs:StartQuery", "logs:GetQueryResults"],
    "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/ecs/web:*"
  }]
}

Create an access key for it.

Connect

Open Integrations → Amazon CloudWatch and fill in:

Field	Value
Access key id	the IAM user’s key
Secret access key	its secret
Region	`us-east-1`
Log groups	comma separated, e.g. `/aws/lambda/api, /ecs/web`

TraceX checks the credentials with a real read, then stores them encrypted.

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

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

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

Disconnect Amazon CloudWatch in Integrations, then revoke the key or credentials on the Amazon CloudWatch side.