-
Notifications
You must be signed in to change notification settings - Fork 528
Add decoder for Docker Fluentd [wip] #1666
base: dev
Are you sure you want to change the base?
Conversation
|
||
func (m *MessagePackSplitter) ConfigStruct() interface{} { | ||
return &MessagePackSplitterConfig{ | ||
UseMsgBytes: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The UseMsgBytes config option is automatically supported by Heka for every splitter, and you're not changing the default, so I don't think there's any reason for you to have a UseMsgBytes option. Which in turn means you don't even need a custom config struct.
@carlanton this looks great. My only concern is that you have this specifically written for docker_fluentd.lua while most fluent messages are the same (1: string tag 2: long? time 3: object record, from https://github.com/fluent/fluentd/blob/master/lib/fluent/plugin/in_forward.rb). It would be great to have a generic fluent format decoder as other projects use this as well. For example https://github.com/saltstack/salt/blob/develop/salt/log/handlers/fluent_mod.py. |
@salekseev I haven't had time to finish all of this, but I did some benchmarks between this version and another version in Go: carlanton@930b2d8 |
Any reason you aren't using the native lib https://github.com/kengonakajima/lua-msgpack-native? The performance would be much better. Also, I would rather see an external dependency instead of having to maintain a copy and paste version of the much slower pure lua version of a msgpack API. |
@trink Hmm, I don't think so. Maybe that's the best option :-) Would that require a PR to mozilla-services/lua_sandbox? |
mozilla-services/lua_sandbox#97 No it would just be a external dependency that the user would install since On Thu, Sep 17, 2015 at 12:15 PM, Anton Lindström [email protected]
|
@carlanton I'm loving carlanton@930b2d8 implementation. But a generic fluent/messagepack decoder in Lua is also very useful as people could use brokers (like Kafka) to connect fluentd and hekad for example where they wouldn't talk directly to each other. Great work. 👍 |
Add decoder for Docker Fluentd [wip]
Hi!
In the upcoming release of Docker 1.8 they have added a logging driver for Fluentd, making it possible to send container logs over TCP encoded in the Fluentd format. This PR adds support for decoding those messages in the Heka sandbox. Heka can already pull logs directly from Docker with the
DockerLogInput
plugin but there are some advantages of doing it this way:Here is some more info about the logging driver: https://github.com/docker/docker/blob/master/docs/reference/logging/fluentd.md
Example usage
First you need to upgrade to the latest release candidate of Docker:
curl -sSL https://test.docker.com/ | sh
or just downloadhttps://test.docker.com/builds/Linux/x86_64/docker-1.8.0-rc2
Then start Heka with the following config:
Start a hello world container:
The log output should look something like this:
Implementation / Questions
The plugin seems to work pretty well, but I had some problems understanding Heka's internals:
The data that the logging driver uses is encoded in MessagePack (It's like JSON. but fast and small), and since I thought it made sense to reuse the
TcpInput
plugin I've added aMessagePackSplitter
plugin to find the boundaries of the received messages. Since the data is "raw messagepack", should the splitter useuse_message_bytes = true
? Is is unsafe to store those bytes in the Payload field?I presumed that you often want to use an additional decoder to parse the actual log line. Therefore, the decoder is implemented in Lua using lua-MessagePack, with the intent that it would be easier to chain decoders/modules without leaving the sandbox. I haven't done any benchmarks yet, so maybe it's better to do everything in Go and then use the
MultiDecoder
instead... Doing it in Go would also not require two different MessagePack libs. What do you think?