Http output plugin

The library retry applies to IO related failures. Non retriable errors include SSL related problems, unresolvable hosts, connection issues, and OS/JVM level interruptions happening during a request.

The options for library retry are:

The options for plugin level retry are:

How many times should the client retry a failing URL. We recommend setting this option to a value other than zero if the keepalive option is enabled. Some servers incorrectly end keepalives early, requiring a retry. See Retry Policy for more information.

If you need to use a custom X.509 CA (.pem certs) specify the path to that here

If you’d like to use a client certificate (note, most people don’t want this) set the path to the x509 cert here

If you’re using a client certificate specify the path to the encryption key here

Timeout (in seconds) to wait for a connection to be established. Default is 10s

Content type

If not specified, this defaults to the following:

Enable cookie support. With this enabled the client will persist cookies across requests as a normal web browser would. Enabled by default

Should redirects be followed? Defaults to true

Set the format of the http body.

If json_batch, each batch of events received by this output will be placed into a single JSON array and sent in one request. This is particularly useful for high throughput scenarios such as sending data between Logstash instaces.

If form, then the body will be the mapping (or whole event) converted into a query parameter string, e.g. foo=bar&baz=fizz...

If message, then the body will be the result of formatting the event according to message

Otherwise, the event is sent as json.

Custom headers to use format is headers => ["X-My-Header", "%{host}"]

Enable request compression support. With this enabled the plugin will compress http requests using gzip.

The HTTP Verb. One of "put", "post", "patch", "delete", "get", "head"

If you would like to consider some non-2xx codes to be successes enumerate them here. Responses returning these codes will be considered successes

Turn this on to enable HTTP keepalive support. We highly recommend setting automatic_retries to at least one with this to fix interactions with broken keepalive implementations.

If you need to use a custom keystore (.jks) specify that here. This does not work with .pem keys!

Specify the keystore password here. Note, most .jks files created with keytool require a password!

Specify the keystore type here. One of JKS or PKCS12. Default is JKS

This lets you choose the structure and parts of the event that are sent.

For example:

   mapping => {"foo" => "%{host}"
              "bar" => "%{type}"}

Max number of concurrent connections. Defaults to 50

Max number of concurrent connections to a single host. Defaults to 25

If you’d like to use an HTTP proxy . This supports multiple configuration syntaxes:

This module makes it easy to add a very fully configured HTTP client to logstash based on [Manticore](https://github.com/cheald/manticore). For an example of its usage see https://github.com/logstash-plugins/logstash-input-http_poller Timeout (in seconds) for the entire request

Note that this option controls plugin-level retries only. It has no affect on library-level retries.

Set this option to false if you want to disable infinite retries for HTTP error response codes defined in the retryable_codes or retryable exceptions (Timeout, SocketException, ClientProtocolException, ResolutionFailure and SocketTimeout). See Retry policy for more information.

When this option is set to false and automatic_retries is enabled, GET, HEAD, PUT, DELETE, OPTIONS, and TRACE requests will be retried.

When set to true and automatic_retries is enabled, this will cause non-idempotent HTTP verbs (such as POST) to be retried. See Retry Policy for more information.

If the plugin encounters these response codes, the plugin will retry indefinitely. See Retry Policy for more information.

Timeout (in seconds) to wait for data on the socket. Default is 10s

List of allowed SSL/TLS versions to use when establishing a connection to the HTTP endpoint.

For Java 8 'TLSv1.3' is supported only since 8u262 (AdoptOpenJDK), but requires that you set the LS_JAVA_OPTS="-Djdk.tls.client.protocols=TLSv1.3" system property in Logstash.

Controls the verification of server certificates. The full option verifies that the provided certificate is signed by a trusted authority (CA) and also that the server’s hostname (or IP address) matches the names identified within the certificate.

The none setting performs no verification of the server’s certificate. This mode disables many of the security benefits of SSL/TLS and should only be used after cautious consideration. It is primarily intended as a temporary diagnostic mechanism when attempting to resolve TLS errors. Using none in production environments is strongly discouraged.

If you need to use a custom truststore (.jks) specify that here. This does not work with .pem certs!

Specify the truststore password here. Note, most .jks files created with keytool require a password!

Specify the truststore type here. One of JKS or PKCS12. Default is JKS

URL to use

How long to wait before checking if the connection is stale before executing a request on a connection using keepalive. You may want to set this lower, possibly to 0 if you get connection errors regularly Quoting the Apache commons docs (this client is based Apache Commmons): Defines period of inactivity in milliseconds after which persistent connections must be re-validated prior to being leased to the consumer. Non-positive value passed to this method disables connection validation. This check helps detect connections that have become stale (half-closed) while kept inactive in the pool. See these docs for more info

The codec used for output data. Output codecs are a convenient method for encoding your data before it leaves the output without needing a separate filter in your Logstash pipeline.

Disable or enable metric logging for this specific plugin instance. By default we record all the metrics we can, but you can disable metrics collection for a specific plugin.

Add a unique ID to the plugin configuration. If no ID is specified, Logstash will generate one. It is strongly recommended to set this ID in your configuration. This is particularly useful when you have two or more plugins of the same type. For example, if you have 2 http outputs. Adding a named ID in this case will help in monitoring Logstash when using the monitoring APIs.

output {
  http {
    id => "my_plugin_id"
  }
}