Send Spring Boot logs directly to Logstash

A Spring Boot application using Logback can send JSON events directly to a Logstash TCP input with logstash-logback-encoder. This path needs no application log file, but its in-memory buffering is not durable storage.

1. Add a compatible encoder dependency

The following retains version 7.4 as an explicit example:

<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>7.4</version>
</dependency>

Version 7.4 requires Logback 1.3 or later and is not a drop-in match for a Spring Boot application still using Logback 1.2. Check the encoder release's requirements against Spring Boot's managed Logback, Jackson, and Java versions. Select a supported compatible release rather than treating this version as a current-version recommendation.

2. Configure logback-spring.xml

<configuration>
    <appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>logstash-host:5000</destination>
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <customFields>{"app":"my-service"}</customFields>
        </encoder>
    </appender>
    <root level="INFO">
        <appender-ref ref="LOGSTASH"/>
    </root>
</configuration>

Place the file on the application's classpath. This example attaches only the network appender; add a console or file appender explicitly if you want another destination.

3. Configure the Logstash input

input {
  tcp {
    port => 5000
    codec => json_lines
  }
}

Add the rest of your Logstash pipeline, including the intended output. Verify connectivity, matching framing, and access controls. The example uses plain TCP; configure TLS on both sides when the transport requires encryption.

Understand buffering and outages

LogstashTcpSocketAppender is already asynchronous. A writer thread performs encoding and network I/O, so wrapping it in another AsyncAppender is unnecessary. By default, a full ring buffer drops events rather than waiting indefinitely in the application thread. The appender can be configured to wait for space instead, which changes application-latency behavior.

Size the queue and choose that policy deliberately. writeBufferSize controls a byte buffer used for output; it is not a durable event queue. Multiple destinations provide connection failover, not delivery of each event to every destination. Shutdown must allow the logging system time to drain, and a process crash can still lose pending events.

Keeping a separate file or console appender during a migration provides another diagnostic path, but does not itself prove that every event has reached Logstash.

LogstashEncoder includes fields such as timestamp, level, logger, and MDC. Parse the JSON directly; use grok only for text embedded inside a field when it actually needs further extraction.

Frequently asked questions

Should I use UDP or TCP?

TCP provides an ordered byte stream and transport retransmission. UDP can lose datagrams without sender notification. Neither choice alone guarantees that Logstash has durably stored or indexed an event.

Will Logstash downtime block the application?

This appender is asynchronous, with a default drop-on-full policy. Changing the append timeout to wait for capacity can block callers. Test queue saturation and reconnect behavior rather than assuming a generic “synchronous appender” rule.

Can I customize the JSON?

Yes. Options include customFields, MDC inclusion, and caller-data settings. For asynchronous caller data, check the appender's capture setting as well as the encoder setting; collecting caller locations has a cost.

See the encoder's release documentation.