On 07/31/2015 11:51 AM, Timur Batyrshin wrote:
Sounds good. Thanks for considering it!
Do you think creating a mapping in the way similar to
PayloadRegexDecoder would work here?
No, I don't. Describing such mappings using declarative configuration tends to be quite awkward. I think a
generic decoder should look for keys that match the default message fields (i.e. "hostname",
"payload", "severity", etc.) and store those where you'd expect. Then all remaining data
would be written out to the dynamic message fields, with nested JSON structures flattened into top level
keys, such as what's happening here:
https://github.com/mozilla-services/lua_sandbox/blob/dev/modules/util.lua#L13
If you want to support a custom JSON to Heka message field mapping, then just
write your own SandboxDecoder. The Lua code to do this would be shorter and
easier to read than any declarative mapping syntax we might define.
-r
Timur
On 31 Jul 2015 20:58:22, Rob Miller <[email protected]> wrote:
------------------------------------------------------------------------
We don't currently have a generic JSON decoder. Mainly this is b/c
generic JSON doesn't map directly to Heka message fields, so
generally we encourage folks to spend a few minutes actually
thinking about how they'd like their JSON input to be mapped to the
Heka message structure. It would be possible, and is probably a good
idea, however, to write one that does this for you automatically. It
would have to recurse through the JSON structure, collapsing it into
a flat structure that can be represented by Heka message fields.
I've opened an issue for it:
https://github.com/mozilla-services/heka/issues/1651 -r On
07/31/2015 08:51 AM, Timur Batyrshin wrote: > I've seen that. By
"this module" I'm referring to encoder/decoder. > > On Fri, Jul 31,
2015 at 6:41 PM, Simon Pasquier
_______________________________________________
Heka mailing list
[email protected]
https://mail.mozilla.org/listinfo/heka
