[
https://issues.apache.org/jira/browse/METRON-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550930#comment-16550930
]
Justin Leet commented on METRON-1453:
-------------------------------------
With the parser aggregation, we can already have all those bolts in your
example be colocated, which makes the flow:
kakfa_input -> aggregate_bolt (syslog + other parser) -> kafka_intermediate ->
aggregate_bolt (syslog + other parser) -> other parser
Where aggregate_bolt is the same bolt in the same topology. The only real
catch here is the intermediate Kafka topic leading to the other parser.
If we build out that capability (in particular,
https://issues.apache.org/jira/browse/METRON-1682), that flow drops the
kafka_intermediate topic and just becomes the same flow you talked about:
kafka_input -> aggregate_bolt (syslog + other parser)
This then fits within the parser chaining and aggregation paradigms with the
same efficiency and composability while leveraging what we've built out.
> Create a Generic Syslog Base Parser Capability
> ----------------------------------------------
>
> Key: METRON-1453
> URL: https://issues.apache.org/jira/browse/METRON-1453
> Project: Metron
> Issue Type: New Feature
> Reporter: Otto Fowler
> Assignee: Otto Fowler
> Priority: Major
>
> We have several parsers now, with many imaginable that are based on syslog,
> where the format is SYSLOG HEADER MESSAGE.
> With message being in a different format. It would be great is we
> had a way to generically handle syslog headers, such that ANY parser data
> could come over syslog.
> Either you could have a custom parser, or configure CSV or JSON such that
> they could be the payload, such that you can handle JSON over syslog by
> configuration only.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
