How to configure a Logstash stdout output

A Logstash stdout output gives you the fastest way to see what a pipeline actually produced, which is useful when filters, conditionals, field names, or ECS mappings do not match what the downstream output expects.

The stdout output plugin writes each event to the standard output stream of the Logstash process. Current Elastic docs still list rubydebug as the default codec, so a plain stdout { } block prints a readable event dump without adding a separate codec unless you prefer compact json output.

Because stdout prints whole events, it can expose secrets and can grow logs quickly under load. Current Logstash 9.x releases also reject superuser runs unless allow_superuser is deliberately enabled, so dry runs and config tests are safest under the logstash service account with a throwaway --path.data directory. On package installs managed by systemd, service stdout is usually visible through journalctl; if not, run the same pipeline in the foreground to inspect the emitted event directly.

1. Dry-run a one-event pipeline before editing the service-managed configuration.

   $ sudo -u logstash /usr/share/logstash/bin/logstash \
     --path.settings /etc/logstash \
     --path.data /tmp/logstash-stdout-dryrun \
     -e 'input { generator { count => 1 message => "stdout output test" } }
   output { stdout { id => "stdout_debug_output" } }'
   Using bundled JDK: /usr/share/logstash/jdk
   ##### snipped #####
   [2026-04-08T00:03:07,987][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}
   {
             "host" => {
           "name" => "logstash-01"
       },
       "@timestamp" => 2026-04-08T00:03:08.008079840Z,
          "message" => "stdout output test",
         "@version" => "1",
            "event" => {
           "sequence" => 0,
           "original" => "stdout output test"
       }
   }
   [2026-04-08T00:03:08,529][INFO ][logstash.runner          ] Logstash shut down.

   The generator input emits one sample event and stops, which makes this a safe quick proof that stdout is rendering events. The explicit output id also gives the plugin a stable name in the pipeline stats API.

   Current Logstash 9.x releases fail the same command when run as root unless allow_superuser is explicitly enabled in /etc/logstash/logstash.yml.

2. Create a sample source file that the logstash service account can read.

   $ sudo install -d -o logstash -g logstash -m 0750 /var/lib/logstash/examples
   $ sudo install -o logstash -g logstash -m 0640 /dev/null /var/lib/logstash/examples/stdout-output.log

   The dedicated sample file keeps the first service-managed validation isolated from production inputs and makes it clear which events should reach stdout.

3. Add a dedicated pipeline fragment such as /etc/logstash/conf.d/50-stdout-output.conf.

   input {
     file {
       path => ["/var/lib/logstash/examples/stdout-output.log"]
       start_position => "end"
       sincedb_path => "/var/lib/logstash/stdout-output.sincedb"
       tags => ["stdout_debug"]
     }
   }
   
   output {
     if "stdout_debug" in [tags] {
       stdout {
         id => "stdout_debug_output"
       }
     }
   }

   Current plugin docs still list rubydebug as the default stdout codec, so the sample output remains readable without an explicit codec block. Add codec ⇒ json when you need one-line machine-readable output instead of the default structured dump.

   Tagging the sample input keeps the debug output scoped to the test file instead of duplicating every pipeline event to standard output.

   Leaving stdout in a busy production pipeline can expose full event payloads and can increase journal or console log volume very quickly.

4. Test the pipeline file with the packaged settings directory and a temporary data path.

   $ sudo -u logstash /usr/share/logstash/bin/logstash \
     --path.settings /etc/logstash \
     --path.data /tmp/logstash-stdout-configtest \
     --config.test_and_exit \
     -f /etc/logstash/conf.d/50-stdout-output.conf
   Using bundled JDK: /usr/share/logstash/jdk
   [WARN ][logstash.config.source.multilocal] Ignoring the 'pipelines.yml' file because command line options are specified
   Configuration OK
   [INFO ][logstash.runner          ] Using config.test_and_exit mode. Config Validation Result: OK. Exiting Logstash

   The --path.data directory must be writable by the logstash user. Because this command uses -f, the warning about /etc/logstash/pipelines.yml being ignored is expected for this isolated test run.

   Related: How to test a Logstash pipeline configuration

5. Restart the Logstash service so it loads the new output plugin.

   $ sudo systemctl restart logstash

   Restarting Logstash restarts every active pipeline in the service, so ingestion can pause briefly while plugins reopen their inputs and outputs.

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

6. Append a sample line after the service is running so the file input treats it as a new event.

   $ printf 'stdout output test\n' | sudo tee -a /var/lib/logstash/examples/stdout-output.log >/dev/null

   With start_position ⇒ “end”, only lines appended after the pipeline starts are picked up from this sample file.

7. Query the Logstash pipeline stats API and confirm the named stdout output has emitted an event.

   $ curl -s "http://localhost:9600/_node/stats/pipelines/main?pretty&filter_path=pipelines.main.plugins.outputs.id,pipelines.main.plugins.outputs.name,pipelines.main.plugins.outputs.events"
   {
     "pipelines" : {
       "main" : {
         "plugins" : {
           "outputs" : [ {
             "id" : "stdout_debug_output",
             "name" : "stdout",
             "events" : {
               "in" : 1,
               "out" : 1
             }
           } ]
         }
       }
     }
   }

   If the pipeline ID is not main, replace it in the API path. The explicit output id keeps the stats readable when the pipeline has multiple outputs.

8. Review recent Logstash service logs for the emitted event dump.

   $ sudo journalctl --unit=logstash --since "5 minutes ago" --no-pager --lines=40
   Apr 08 00:08:41 logstash-01 logstash[21437]: [2026-04-08T00:08:41,412][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}
   Apr 08 00:08:55 logstash-01 logstash[21437]: {
   Apr 08 00:08:55 logstash-01 logstash[21437]:           "message" => "stdout output test",
   Apr 08 00:08:55 logstash-01 logstash[21437]:              "tags" => [
   Apr 08 00:08:55 logstash-01 logstash[21437]:         [0] "stdout_debug"
   Apr 08 00:08:55 logstash-01 logstash[21437]:     ],
   Apr 08 00:08:55 logstash-01 logstash[21437]:              "event" => {
   Apr 08 00:08:55 logstash-01 logstash[21437]:         "original" => "stdout output test"
   Apr 08 00:08:55 logstash-01 logstash[21437]:     }
   Apr 08 00:08:55 logstash-01 logstash[21437]: }

   On package installs started with systemd, the service standard output stream is usually visible in the journal, which makes journalctl the quickest place to read the event dump.

   If the API shows the stdout plugin counters increasing but the journal does not show the event, stop the service and rerun the pipeline in the foreground with sudo -u logstash /usr/share/logstash/bin/logstash --path.settings /etc/logstash --path.data /tmp/logstash-stdout-foreground -f /etc/logstash/conf.d/50-stdout-output.conf to inspect the emitted event directly.

   Related: How to debug Logstash pipelines