On 10/14/2014 02:37 AM, chenlin rao wrote:
great! It work now.
Then I change to RsyslogDecoder using official example configuration.
And found it also need to use `token` but not `message.proto`.
I think we need to upgrade documents, and, which usage is `message.proto`?
I can add some more context here that might help. The `parser_type`
option is what tells the TcpInput (and a few others) how to determine
where a record boundary is. Using `message.proto` means that you expect
the data to use Heka's default message stream framing, which uses a
protobuf encoded header, described here:
http://hekad.readthedocs.org/en/v0.7.2/message/index.html#stream-framing
It's technically possible to use this framing with any message
serialization format, but it is most often used in conjunction with
protobuf encoded messages, which is in a sense Heka's native encoding.
If you set up a TcpOutput with a ProtobufEncoder, the stream framing
will automatically be used, so it will communicate very nicely w/ a
TcpInput, parser_type of message.proto, and ProtobufDecoder.
If you're using a TcpInput for any other reason, chances are that your
data isn't going to use Heka's message stream framing, unless you go out
of your way to do so. In this case you'll want to use one of the other
parser_type options, either `token` (when a simple string is the message
delimiter) or `regexp` (when you need to specify something more
complicated as the delimiter).
I'm not aware of any places in our documentation where message.proto is
being incorrectly specified as the parser_type, but it's very possible
that we just missed it somewhere. If you can point directly to where you
see such a mistake, I'll be happy to correct it.
Cheers,
-r
_______________________________________________
Heka mailing list
[email protected]
https://mail.mozilla.org/listinfo/heka
