You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A customer wrote in, they are using Spring Boot 3.4.x with logging.structured.format.console=ecs enabled. Their application logs are all emitted in ECS/JSON format, except for the Sentry SDK’s internal diagnostic logs. Despite having:
and being on versions 7.20.0 or 8.0.0, the Sentry logs appear in plain text and include extra line breaks. For example:
INFO: Initializing SDK with DSN: 'https://xxxx'
INFO: No outbox dir path is defined in options.
DEBUG: Serializing object: {
"timestamp": "2025-01-24T08:43:43.574Z",
"exception": {
...
This disrupts the JSON formatting in their log files, making them inconsistent and harder to parse.
Is there a way to make Sentry’s internal diagnostic logs conform to the ECS/JSON format that Spring Boot 3.4 applies to all other logs?
Solution Brainstorm
No response
The text was updated successfully, but these errors were encountered:
Hey @dalnoki they should be able to achieve this using options.setLogger. This allows them to provide their own implementation that can then log Sentry debug logs in whatever format they need.
Problem Statement
A customer wrote in, they are using Spring Boot 3.4.x with
logging.structured.format.console=ecs
enabled. Their application logs are all emitted in ECS/JSON format, except for the Sentry SDK’s internal diagnostic logs. Despite having:and being on versions 7.20.0 or 8.0.0, the Sentry logs appear in plain text and include extra line breaks. For example:
INFO: Initializing SDK with DSN: 'https://xxxx'
INFO: No outbox dir path is defined in options.
DEBUG: Serializing object: {
"timestamp": "2025-01-24T08:43:43.574Z",
"exception": {
...
This disrupts the JSON formatting in their log files, making them inconsistent and harder to parse.
Is there a way to make Sentry’s internal diagnostic logs conform to the ECS/JSON format that Spring Boot 3.4 applies to all other logs?
Solution Brainstorm
No response
The text was updated successfully, but these errors were encountered: