A common issue when collecting logs and sending them to an observability backend is that single log messages are split into multiple log records. This usually happens when logs are collected from the file system, for example via the filelog receiver, and an application prints multiple lines for a single log entry. The most prominent examples are exception stack traces.
Here is how that looks might look in the log file on disk:

text

application.log123456789101112131415161718192021
2026-02-26T18:51:41.639Z  INFO 1 --- [dash0-app-under-test-spring-boot] [nio-1307-exec-2] c.d.app_under_test.RequestLoggingFilter  : GET /dash0-k8s-operator-test - 200
2026-02-26T18:51:41.642Z ERROR 1 --- [dash0-app-under-test-spring-boot] [nio-1307-exec-2] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: an error occured] with root cause

java.lang.RuntimeException: an error occured
        at com.dash0.app_under_test.Controller.test(Controller.java:50) ~[!/:1.0.0-SNAPSHOT]
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[na:na]
        at java.base/java.lang.reflect.Method.invoke(Method.java:565) ~[na:na]
        at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:252) ~[spring-web-7.0.5.jar!/:7.0.5]
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:184) ~[spring-web-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:934) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:853) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:86) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:866) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1000) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:892) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:622) ~[tomcat-embed-core-11.0.18.jar!/:na]
        at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:874) ~[spring-webmvc-7.0.5.jar!/:7.0.5]
        at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:710) ~[tomcat-embed-core-11.0.18.jar!/:na]
        ...

When this log file is picked up by the filelog receiver, each line in the stack trace becomes its own log record. In Dash0, this would look as follows:

A screenshot of the Dash0 log view, with a list of log messages representing a Java exception stack trace — A list of log records representing a Java exception stack trace

The solution is to configure stuctured logging in the application. This results in each log message being printed to exactly one line, usually as JSON. Additional metadata will be included as attributes. In particular, the exception stack trace (if present) will be represented as an attribute and included in the log line.

This enables the filelog receiver to pick this up as a single log record.
The details on how to configure structured logging depend on the logging framework in question, but almost all logging frameworks support structured logging.
There are other approaches to solve this issue, namely the multiline setting of the filelog receiver or the recombine operator. Both are far less favorable in comparsion to

solving the issue at the source with properly configured structured logging. The bigget downside is that both multiline as well as recombine work heuristical at best. In addition, they need to be configured in the OpenTelemetry collector, which usually is responsible for monitoring multiple applications, each potentially with their own logging framework and log message patterns. This makes configuring the multiline setting or the recombine operator quite messy, and not scalable.

info

A note for users of the Dash0 operator: The operator does not support multiline or recombine for the reasons outlined above. There is no combination of regular expressions that would ever work for all possible logging frameworks.

Multiline Log Messages