How to write a Java filter pluginedit

Warning

This functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features.

To develop a new Java filter for Logstash, you write a new Java class that conforms to the Logstash Java Filters API, package it, and install it with the logstash-plugin utility. We’ll go through each of those steps.

Set up your environmentedit

Copy the example repoedit

Start by copying the example filter plugin. The plugin API is currently part of the Logstash codebase so you must have a local copy of that available. You can obtain a copy of the Logstash codebase with the following git command:

git clone --branch <branch_name> --single-branch https://github.com/elastic/logstash.git <target_folder>

The branch_name should correspond to the version of Logstash containing the preferred revision of the Java plugin API.

Note

The beta version of the Java plugin API is available in the 6.7 branch of the Logstash codebase.

Specify the target_folder for your local copy of the Logstash codebase. If you do not specify target_folder, it defaults to a new folder called logstash under your current folder.

Generate the .jar fileedit

After you have obtained a copy of the appropriate revision of the Logstash codebase, you need to compile it to generate the .jar file containing the Java plugin API. From the root directory of your Logstash codebase ($LS_HOME), you can compile it with ./gradlew assemble (or gradlew.bat assemble if you’re running on Windows). This should produce the $LS_HOME/logstash-core/build/libs/logstash-core-x.y.z.jar where x, y, and z refer to the version of Logstash.

After you have successfully compiled Logstash, you need to tell your Java plugin where to find the logstash-core-x.y.z.jar file. Create a new file named gradle.properties in the root folder of your plugin project. That file should have a single line:

LOGSTASH_CORE_PATH=<target_folder>/logstash-core

where target_folder is the root folder of your local copy of the Logstash codebase.

Code the pluginedit

The example filter plugin allows one to configure a field in each event that will be reversed. For example, if the filter were configured to reverse the day_of_week field, an event with day_of_week: "Monday" would be transformed to day_of_week: "yadnoM". Let’s look at the main class in that example filter:

@LogstashPlugin(name = "java_filter_example")
public class JavaFilterExample implements Filter {

    public static final PluginConfigSpec<String> SOURCE_CONFIG =
            PluginConfigSpec.stringSetting("source", "message");

    private String id;
    private String sourceField;

    public JavaFilterExample(String id, Configuration config, Context context) {
        this.id = id;
        this.sourceField = config.get(SOURCE_CONFIG);
    }

    @Override
    public Collection<Event> filter(Collection<Event> events, FilterMatchListener matchListener) {
        for (Event e : events) {
            Object f = e.getField(sourceField);
            if (f instanceof String) {
                e.setField(sourceField, StringUtils.reverse((String)f));
                matchListener.filterMatched(e);
            }
        }
        return events;
    }

    @Override
    public Collection<PluginConfigSpec<?>> configSchema() {
        return Collections.singletonList(SOURCE_CONFIG);
    }

    @Override
    public String getId() {
        return this.id;
    }
}

Let’s step through and examine each part of that class.

Class declarationedit

@LogstashPlugin(name = "java_filter_example")
public class JavaFilterExample implements Filter {

Notes about the class declaration:

  • All Java plugins must be annotated with the @LogstashPlugin annotation. Additionally:

    • The name property of the annotation must be supplied and defines the name of the plugin as it will be used in the Logstash pipeline definition. For example, this filter would be referenced in the filter section of the Logstash pipeline defintion as filter { java_filter_example => { .... } }
    • The value of the name property must match the name of the class excluding casing and underscores.
  • The class must implement the co.elastic.logstash.api.Filter interface.

Plugin settingsedit

The snippet below contains both the setting definition and the method referencing it:

public static final PluginConfigSpec<String> SOURCE_CONFIG =
        PluginConfigSpec.stringSetting("source", "message");

@Override
public Collection<PluginConfigSpec<?>> configSchema() {
    return Collections.singletonList(SOURCE_CONFIG);
}

The PluginConfigSpec class allows developers to specify the settings that a plugin supports complete with setting name, data type, deprecation status, required status, and default value. In this example, the source setting defines the name of the field in each event that will be reversed. It is not a required setting and if it is not explicitly set, its default value will be message.

The configSchema method must return a list of all settings that the plugin supports. In a future phase of the Java plugin project, the Logstash execution engine will validate that all required settings are present and that no unsupported settings are present.

Constructor and initializationedit

private String id;
private String sourceField;

public JavaFilterExample(String id, Configuration config, Context context) {
    this.id = id;
    this.sourceField = config.get(SOURCE_CONFIG);
}

All Java filter plugins must have a constructor taking a String id and a Configuration and Context argument. This is the constructor that will be used to instantiate them at runtime. The retrieval and validation of all plugin settings should occur in this constructor. In this example, the name of the field to be reversed in each event is retrieved from its setting and stored in a local variable so that it can be used later in the filter method.

Any additional initialization may occur in the constructor as well. If there are any unrecoverable errors encountered in the configuration or initialization of the filter plugin, a descriptive exception should be thrown. The exception will be logged and will prevent Logstash from starting.

Filter methodedit

@Override
public Collection<Event> filter(Collection<Event> events, FilterMatchListener matchListener) {
    for (Event e : events) {
        Object f = e.getField(sourceField);
        if (f instanceof String) {
            e.setField(sourceField, StringUtils.reverse((String)f));
            matchListener.filterMatched(e);
        }
    }
    return events;

Finally, we come to the filter method that is invoked by the Logstash execution engine on batches of events as they flow through the event processing pipeline. The events to be filtered are supplied in the events argument and the method should return a collection of filtered events. Filters may perform a variety of actions on events as they flow through the pipeline including:

  • Mutation — Fields in events may be added, removed, or changed by a filter. This is the most common scenario for filters that perform various kinds of enrichment on events. In this scenario, the incoming events collection may be returned unmodified since the events in the collection are mutated in place.
  • Deletion — Events may be removed from the event pipeline by a filter so that subsequent filters and outputs do not receive them. In this scenario, the events to be deleted must be removed from the collection of filtered events before it is returned.
  • Creation — A filter may insert new events into the event pipeline that will be seen only by subsequent filters and outputs. In this scenario, the new events must be added to the collection of filtered events before it is returned.
  • Observation — Events may pass unchanged by a filter through the event pipeline. This may be useful in scenarios where a filter performs external actions (e.g., updating an external cache) based on the events observed in the event pipeline. In this scenario, the incoming events collection may be returned unmodified since no changes were made.

In the example above, the value of the source field is retrieved from each event and reversed if it is a string value. Because each event is mutated in place, the incoming events collection can be returned.

The matchListener is the mechanism by which filters indicate which events "match". The common actions for filters such as add_field and add_tag are applied only to events that are designated as "matching". Some filters such as the grok filter have a clear definition for what constitutes a matching event and will notify the listener only for matching events. Other filters such as the UUID filter have no specific match criteria and should notify the listener for every event filtered. In this example, the filter notifies the match listener for any event that had a String value in its source field and was therefore able to be reversed.

getId methodedit

@Override
public String getId() {
    return id;
}

For filter plugins, the getId method should always return the id that was provided to the plugin through its constructor at instantiation time.

Unit testsedit

Lastly, but certainly not least importantly, unit tests are strongly encouraged. The example filter plugin includes an example unit test that you can use as a template for your own.

Package and deployedit

Java plugins are packaged as Ruby gems for dependency management and interoperability with Ruby plugins.

Note

One of the goals for Java plugin support is to eliminate the need for any knowledge of Ruby or its toolchain for Java plugin development. Future phases of the Java plugin project will automate the packaging of Java plugins as Ruby gems so no direct knowledge of or interaction with Ruby will be required. In the current phase, Java plugins must still be manually packaged as Ruby gems and installed with the logstash-plugin utility.

Compile to JAR fileedit

The Java plugin should be compiled and assembled into a fat jar with the vendor task in the Gradle build file. This will package all Java dependencies into a single jar and write it to the correct folder for later packaging into a Ruby gem.

Manually package as Ruby gemedit

Several Ruby source files are required to package the jar file as a Ruby gem. These Ruby files are used only at Logstash startup time to identify the Java plugin and are not used during runtime event processing.

Note

These Ruby source files will be automatically generated in a future release.

logstash-filter-<filter-name>.gemspec

Gem::Specification.new do |s|
  s.name            = 'logstash-filter-java_filter_example'
  s.version         = PLUGIN_VERSION
  s.licenses        = ['Apache-2.0']
  s.summary         = "Example filter using Java plugin API"
  s.description     = ""
  s.authors         = ['Elasticsearch']
  s.email           = 'info@elastic.co'
  s.homepage        = "http://www.elastic.co/guide/en/logstash/current/index.html"
  s.require_paths = ['lib', 'vendor/jar-dependencies']

  # Files
  s.files = Dir["lib/**/*","spec/**/*","*.gemspec","*.md","CONTRIBUTORS","Gemfile","LICENSE","NOTICE.TXT", "vendor/jar-dependencies/**/*.jar", "vendor/jar-dependencies/**/*.rb", "VERSION", "docs/**/*"]

  # Special flag to let us know this is actually a logstash plugin
  s.metadata = { 'logstash_plugin' => 'true', 'logstash_group' => 'filter'}

  # Gem dependencies
  s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99"
  s.add_runtime_dependency 'jar-dependencies'

  s.add_development_dependency 'logstash-devutils'
end

You can use this file with the following modifications:

  • s.name must follow the logstash-filter-<filter-name> pattern
  • s.version must match the project.version specified in the build.gradle file. Both versions should be set to be read from the VERSION file in this example.

lib/logstash/filters/<filter-name>.rb

# encoding: utf-8
require "logstash/filters/base"
require "logstash/namespace"
require "logstash-filter-java_filter_example_jars"
require "java"

class LogStash::Filters::JavaFilterExample < LogStash::Filters::Base
  config_name "java_filter_example"

  def self.javaClass() org.logstash.javaapi.JavaFilterExample.java_class; end
end

Modify these items in the file above:

  • Change the name to correspond with the filter name.
  • Change require "logstash-filter-java_filter_example_jars" to reference the appropriate "jars" file as described below.
  • Change class LogStash::Filters::JavaFilterExample < LogStash::Filters::Base to provide a unique and descriptive Ruby class name.
  • Change config_name "java_filter_example" to match the name of the plugin as specified in the name property of the @LogstashPlugin annotation.
  • Change def self.javaClass() org.logstash.javaapi.JavaFilterExample.java_class; end to return the class of the Java filter.

lib/logstash-filter-<filter-name>_jars.rb

require 'jar_dependencies'
require_jar('org.logstash.javaapi', 'logstash-filter-java_filter_example', '0.0.1')

In the file above:

  • Rename the file to correspond to the filter name.
  • Change the require_jar directive to correspond to the group specified in the Gradle build file, the name of the filter JAR file, and the version as specified in both the gemspec and Gradle build file.

After you have created the previous files and the plugin JAR file, build the gem using the following command:

gem build logstash-filter-<filter-name>.gemspec

Installing the Java plugin in Logstashedit

After you have packaged your Java plugin as a Ruby gem, you can install it in Logstash with this command:

bin/logstash-plugin install --no-verify --local /path/to/javaPlugin.gem

For Windows platforms: Substitute backslashes for forward slashes as appropriate in the command.

Run Logstash with the Java filter pluginedit

The following is a minimal Logstash configuration that can be used to test that the Java filter plugin is correctly installed and functioning.

input {
  generator { message => "Hello world!" count => 1 }
}
filter {
  java_filter_example {}
}
output {
  stdout { codec => rubydebug }
}

Copy the above Logstash configuration to a file such as java_filter.conf. Start Logstash with:

bin/logstash --java-execution -f /path/to/java_filter.conf
Note

The --java-execution flag to enable the Java execution engine is required as Java plugins are not supported in the Ruby execution engine.

The expected Logstash output (excluding initialization) with the configuration above is:

{
      "sequence" => 0,
      "@version" => "1",
       "message" => "!dlrow olleH",
    "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ,
          "host" => "<yourHostName>"
}

Feedbackedit

If you have any feedback on Java plugin support in Logstash, please comment on our main Github issue or post in the Logstash forum.