Send Kubernetes application errors to Google Cloud Error Reporting

Use structured container logs or the Error Reporting API, and verify collection, stack-trace formatting, resource type, and workload credentials.

Best practices
Send Kubernetes application errors to Google Cloud Error Reporting

On GKE, an application can write error records to stdout or stderr and let enabled workload logging send them to Cloud Logging. Error Reporting can then group supported stack traces. This relies on the cluster's logging configuration and eligible log entries; emitting JSON alone does not guarantee that an error will appear.

Option 1: write structured error logs

Emit each JSON object as one physical line. A readable representation is shown below; serialize the object so the stack trace's newlines remain escaped inside the JSON string:

{
  "severity": "ERROR",
  "message": "Payment callback failed",
  "stack_trace": "java.lang.NullPointerException: payment was null\n\tat com.shop.PayService.handle(PayService.java:42)",
  "context": {"httpRequest": {"url": "/callback/pay", "responseStatusCode": 500}}
}

Use a real stack trace in a supported language format. stack_trace, exception, and message are recognized fields; a supported stack trace can also arrive in a multiline textPayload. A plain error message without a stack trace can instead be explicitly identified as a ReportedErrorEvent with its documented @type.

Set an appropriate severity, check the entry's monitored resource, and inspect the received Cloud Logging record before troubleshooting grouping. For GKE workloads, k8s_container is a supported resource type. Confirm that logging exclusions or routing choices are not removing the records you expect Error Reporting to process.

Option 2: use a client library

Error Reporting has client libraries for languages including Java, Node.js, Python, and Go. Their APIs differ: some accept exceptions through a language-specific helper, while the underlying API reports an error event. Follow the library's example for your runtime rather than assuming every SDK provides the same report(exception) call.

On GKE, use Workload Identity Federation and grant the workload the required reporting permissions. Avoid distributing service-account key files. For another Kubernetes environment, configure an appropriate Google Cloud identity and credentials separately.

Collection details to verify

  • One-line JSON is convenient for container collectors. If an application emits a stack trace across physical lines, configure and test multiline collection so it arrives as one log entry. JSON is not the only supported Error Reporting format.
  • A non-GKE cluster needs a collection path to Cloud Logging, authentication, and a supported monitored-resource mapping; installing a collector alone is insufficient.
  • Grouping uses error and stack-trace information. A changing message or identifier does not necessarily create a new group, and Error Reporting applies normalization. Inspect the resulting group instead of inferring grouping solely from the displayed text.

Frequently asked questions

Can a stack trace printed with println be recognized?

Yes, if collection preserves a supported stack trace in one eligible entry, including a multiline textPayload. Separate container log entries containing individual frames are not equivalent to one complete stack trace.

Can I define arbitrary grouping rules?

Error Reporting uses its own grouping algorithm rather than a user-supplied grouping-rule language. Preserve useful exception locations and consistent reporting metadata; do not alter exception sites merely to force an expected group.

See Google's error log formatting requirements and GKE logging overview.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting