Google Cloud Logging
Connect Google Cloud Logging to TraceX with a Logs Viewer service account and an optional filter.
Search Google Cloud Logging with a service account.
Why connect Google Cloud Logging
Section titled “Why connect Google Cloud Logging”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 Google Cloud Logging 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 Google Cloud, create a service account with the Logs Viewer role
(roles/logging.viewer) on the project, then add a JSON key.
Connect
Section titled “Connect”Open Integrations → Google Cloud Logging and fill in:
| Field | Value |
|---|---|
| Service account key (JSON) | the key file’s contents |
| Project id | optional, read from the key |
| Extra filter | optional, e.g. resource.type="k8s_container" |
The extra filter is added to every search, which is useful to stay on production workloads. 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 Google Cloud Logging in Integrations, then revoke the key or credentials on the Google Cloud Logging side.