How to configure a Logstash Beats input

A Logstash beats input gives Filebeat, Metricbeat, and other Beats a single ingestion endpoint, which keeps parsing and routing centralized instead of duplicating that logic on every shipper.

On packaged Linux installs, Logstash normally builds the default main pipeline by merging every .conf file under /etc/logstash/conf.d in lexical order. The beats input listens on a TCP host and port, and setting a stable plugin id makes the pipeline stats API show exactly which listener is accepting connections and how many events it has handled.

Current beats input releases still accept plaintext traffic unless ssl_enabled is set, and they reject several legacy TLS keys from older examples such as ssl and ssl_verify_mode. Keep the listener on a trusted network or enable TLS before exposing it more broadly, and remember that the Logstash HTTP API is enabled by default on the local loopback address in the 9600-9700 range unless /etc/logstash/logstash.yml overrides it.

Steps to configure a Logstash Beats input:

Create a dedicated pipeline file such as /etc/logstash/conf.d/20-beats-input.conf.
```
input {
  beats {
    id => "beats_5044"
    host => "0.0.0.0"
    port => 5044
  }
}

output {
  stdout {
    codec => rubydebug
  }
}
```
The explicit id makes the listener easy to identify in the pipeline stats API. Replace the temporary stdout output with elasticsearch or another production output after the input itself is confirmed.

Binding to 0.0.0.0 exposes the listener on every interface. If only one network or local host should reach it, set host to that specific address instead. Current beats input releases also fail to start if old examples still use keys such as ssl or ssl_verify_mode; use ssl_enabled and ssl_client_authentication instead.

Related: How to configure a Logstash stdout output
Related: How to configure Logstash output to Elasticsearch

Test the pipeline configuration before restarting the service.

$ sudo /usr/share/logstash/bin/logstash --path.settings /etc/logstash --config.test_and_exit
Using bundled JDK: /usr/share/logstash/jdk
Sending Logstash logs to /var/log/logstash which is now configured via log4j2.properties
[2026-04-07T08:03:35,758][INFO ][logstash.runner          ] Starting Logstash {"logstash.version"=>"9.3.2", "jruby.version"=>"jruby 9.4.13.0 (3.1.4) 2025-06-10 9938a3461f OpenJDK 64-Bit Server VM 21.0.10+7-LTS on 21.0.10+7-LTS +indy +jit [aarch64-linux]"}
##### snipped #####
[2026-04-07T08:03:36,459][INFO ][logstash.javapipeline    ][main] Pipeline `main` is configured with `pipeline.ecs_compatibility: v8` setting. All plugins in this pipeline will default to `ecs_compatibility => v8` unless explicitly configured otherwise.
Configuration OK
[2026-04-07T08:03:36,471][INFO ][logstash.runner          ] Using config.test_and_exit mode. Config Validation Result: OK. Exiting Logstash

Config validation confirms the pipeline syntax and plugin settings, but runtime connectivity and permissions are only proven after the service starts.

Restart the Logstash service so it loads the new input.
```
$ sudo systemctl restart logstash
```
A restart briefly stops active pipelines, so upstream Beats may buffer or back off until the listener returns.

Related: How to manage the Logstash service with systemctl in Linux

Confirm the Logstash service returned to the running state.

$ sudo systemctl status logstash --no-pager --lines=20
● logstash.service - logstash
     Loaded: loaded (/usr/lib/systemd/system/logstash.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-04-07 08:03:36 UTC; 8s ago
   Main PID: 21844 (java)
      Tasks: 95 (limit: 28486)
     Memory: 958.3M
        CPU: 14.612s
##### snipped #####
Apr 07 08:03:36 logstash-01 logstash[21844]: [2026-04-07T08:03:36,792][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}

If the unit does not stay active (running), inspect /var/log/logstash/logstash-plain.log or the journal before retrying the restart.

Confirm the beats listener is bound to TCP port 5044.
```
$ sudo ss -lntp | grep -F ':5044'
LISTEN 0      4096         0.0.0.0:5044       0.0.0.0:*    users:(("java",pid=21844,fd=239))
```
If host is set to a specific address, ss should show that address instead of 0.0.0.0.
From a Filebeat host, test the configured Logstash output endpoint.
```
$ sudo filebeat test output -c /etc/filebeat/filebeat.yml
logstash: logstash-1.example.net:5044...
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.0.2.25
    dial up... OK
  TLS... WARN secure connection disabled
  talk to server... OK
```
The shipper-side test confirms host resolution, TCP reachability, and the current TLS settings before any real events are sent. When TLS is enabled, this output includes certificate and handshake details instead of the secure connection disabled warning.

Related: How to configure Filebeat output to Logstash

Query the Logstash pipeline stats API and confirm the beats input ID is active.

$ curl -s http://localhost:9600/_node/stats/pipelines/main?pretty
{
  "pipelines" : {
    "main" : {
      "events" : {
        "out" : 3,
        "in" : 3,
        "filtered" : 3
      },
      "plugins" : {
        "inputs" : [ {
          "id" : "beats_5044",
          "current_connections" : 1,
          "name" : "beats",
          "events" : {
            "out" : 3
          }
        } ]
      }
    }
  }
}

This response proves more than syntax: the configured input ID is loaded, a Beat is currently connected, and events are moving through the running pipeline. Current Logstash builds enable the HTTP API by default and bind it to the local loopback address unless /etc/logstash/logstash.yml changes api.enabled, api.http.host, or api.http.port.

Review recent Logstash journal lines for listener startup and a shipped event.

$ sudo journalctl --unit=logstash --since "5 min ago" --no-pager --lines=40
Apr 07 08:03:36 logstash-01 logstash[21844]: [2026-04-07T08:03:36,779][INFO ][logstash.inputs.beats    ][main] Starting input listener {:address=>"0.0.0.0:5044"}
Apr 07 08:03:36 logstash-01 logstash[21844]: [2026-04-07T08:03:36,826][INFO ][org.logstash.beats.Server][main][beats_5044] Starting server on port: 5044
Apr 07 08:07:15 logstash-01 logstash[21844]:        "message" => "2026-04-07T16:06:30Z beat input live append article003"

With the temporary stdout output shown earlier, the journal captures the event payload. After replacing stdout with a production output, use that destination’s own confirmation path instead of expecting full events in the journal.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.