Logs and errors

Elasticsearch

Connect Elasticsearch or OpenSearch log indices to TraceX with a read-only API key and an index pattern.

Search an index pattern in Elasticsearch or OpenSearch, including Elastic Cloud.

Why connect Elasticsearch

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 Elasticsearch 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 API key (or a user) with read access to the log indices, for example:

POST /_security/api_key
{
  "name": "tracex",
  "role_descriptors": {
    "tracex_read": { "indices": [{ "names": ["logs-*"], "privileges": ["read"] }] }
  }
}

Connect

Open Integrations → Elasticsearch and fill in:

Field	Value
Address	`https://acme.es.us-east-1.aws.found.io`
API key or password	read access to the index
Username	only when using a password
Index pattern	`logs-*`
Message field	optional, default `message`

Set the message field if your log text lives elsewhere, such as log or event.original. 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 Elasticsearch in Integrations, then revoke the key or credentials on the Elasticsearch side.