public class SyslogOutput
extends org.thales.punch.libraries.storm.api.BaseProcessingNode
The SyslogBolt supports SSL/TLS and compression. For efficiency the SyslogBolt relies on an internal send queue, in order to perform bulk writes towards the server, as well as supporting a good level of compression. Check the real time reported metrics to estimate the compression level or your bolt.
*
Because the Syslog bolt does not rely on an acknowledged protocol, sent data can be lost in case the remote peer fails or restart. The SyslogBolt will acknowledge the Storm tuples without ensuring the corresponding data has been received and processed by the Server. The configuration parameters of each destination are the following: Each destination takes the following properties
property | mandatory | type | default | comment |
---|---|---|---|---|
host | yes | string | - | The server host address. Accepted values are dotted number IP addresses, or hostname. You can set several destination addresses using the destination property. |
port | yes | int | - | The server listening port. |
proto | no | string | "tcp" | The socket protocol, "tcp" or "lumberjack" |
compression | no | boolean | false | activate netty level compression |
connect_timeout_ms | no | long | 5000 | the socket connection timeout. |
connect_retry_interval_ms | no | long | 5000 | If the connection to the destination(s) fails, a new connection attempt is performed regularly. Set this to the retry interval. |
send_queue_size | no | int | 1000 | The size of the blocking send queue. If the remote server is too slow, this queue will eventually fills up. Once full, you have two options: you can decide to give up sending data or make your bolt wait to catch up. You can also set this property for each destination. |
drop_if_queue_full | no | boolean | true | Shutdown the connection if the input queue is full. This will make the bolt throw away the queued data and reconnect to the server. This option has no effect with the lumberjack protocol. |
ssl | no | string | false | Set to true to listen on SSL. |
secret | no | string | - | The secret to load a TLS PKCS12 SSL context |
Often what you need is to forward the data to another format, and/or to filter out some unnecessary fields. To do that you must insert a PunchBolt before this SyslogBolt. For example here is a punchlet that transform the (Json) log into a plain key-value string:
{
// get the Json under the stream and field id.
Tuple input = root:[logs][log];
// transform it into a key value string
String kv = toKv().on(input);
// replace the input document by that String.
root:[logs][log] = kv;
}
With such a punchlet, the bolt will send something like
"message"="original log", "vendor"="apache" ...
Besides destination the bolt has the following settings:
property | mandatory | type | default | comment |
---|---|---|---|---|
acked | no | boolean | false | if the syslog bolt is connected to none of its configured destination, you can make it eventually block the processing, or instead considered it
harmless. You control that with this parameter, if set to true, Storm tuples will be acknowledged (in the Storm sense) only if it was sucessfully written to
the output socket. In turn if the bolt cannot connect to any destination it will make the tuple fail, which eventually will make the topology
repeat or block tuple processing. If false, tuples will always be acked.
Note that even if tuples are acked, it does not mean yet that the remote server has received the data. It only means the data has been written to the socket. It you need real end-to-end acnowledgement with the remote server, you must in addition use the lumberjack acknowledged protocol. Note also that even is set to false, your bolt can slow down your topology if the remote server is too slow. Check the destination drop_if_queue_full property below. |
Constructor and Description |
---|
SyslogOutput(org.thales.punch.libraries.storm.api.NodeSettings config)
Public constructor.
|
Modifier and Type | Method and Description |
---|---|
void |
declareOutputFields(org.apache.storm.topology.OutputFieldsDeclarer declarer) |
void |
prepare(Map map,
org.apache.storm.task.TopologyContext topologyContext,
org.apache.storm.task.OutputCollector collector)
Setup this spout before starting emitting Tuples into the topology.
|
void |
process(org.apache.storm.tuple.Tuple tuple)
The Syslog bolt expects a single field, and forwards that field to the destination.
|
public SyslogOutput(org.thales.punch.libraries.storm.api.NodeSettings config)
config
- the configpublic void prepare(Map map, org.apache.storm.task.TopologyContext topologyContext, org.apache.storm.task.OutputCollector collector)
prepare
in interface org.apache.storm.task.IBolt
prepare
in class org.thales.punch.libraries.storm.api.BaseProcessingNode
map
- the storm settingstopologyContext
- the topology settingsscollector
- the output collector for sending out tuples.public void process(org.apache.storm.tuple.Tuple tuple)
process
in class org.thales.punch.libraries.storm.api.BaseProcessingNode
tuple
- the tuple to sendpublic void declareOutputFields(org.apache.storm.topology.OutputFieldsDeclarer declarer)
declareOutputFields
in interface org.apache.storm.topology.IComponent
declareOutputFields
in class org.thales.punch.libraries.storm.api.BaseProcessingNode
Copyright © 2022. All rights reserved.