Contributing to Logstash

You can add your own input, codec, filter, or output plugins to Logstash.

Acceptance guidelines

Start with the end in mind. These guidelines and best practices can help you build a better plugin, even if you choose not to share it with the world.

  • Consistency. Your plugin must be consistent in quality and naming conventions used by other plugins. The plugin name must be unique and in this format: logstash-plugintype-pluginname. If the plugin name is more than one word, separate words after plugin type with underscores. Example: logstash-output-elastic_app_search
  • Documentation. Documentation is a required component of your plugin. If we list your plugin in the Logstash Reference, we point to your documentation—​a readme.md, docs/index.asciidoc, or both—​in your plugin repo.
  • Code Review. Your plugin must be reviewed by members of the community for coherence, quality, readability, stability and security.
  • Tests. Your plugin must contain tests to be accepted. You can refer to http://betterspecs.org/ for examples.

Add a plugin

Plugins can be developed and deployed independently of the Logstash core. Here are some documents to guide you through the process of coding, deploying, and sharing your plugin:

Plugin Shutdown APIs

You have three options for shutting down a plugin: stop, stop?, and close.

  • Call the stop method from outside the plugin thread. This method signals the plugin to stop.
  • The stop? method returns true when the stop method has already been called for that plugin.
  • The close method performs final bookkeeping and cleanup after the plugin’s run method and the plugin’s thread both exit. The close method is a a new name for the method known as teardown in previous versions of Logstash.

The shutdown, finished, finished?, running?, and terminating? methods are redundant and no longer present in the Plugin Base class.

Sample code for the plugin shutdown APIs is available.