Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
Rebasing to master to see where we are. If this comes back clean please
don't merge yet, I want to add 8.0 log format first.
---
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
I think
https://github.com/apache/metron/pull/579/commits/ccd99dda3c8a72408ae13eeaca078af1e345a36c#diff-e0385f97ebea64bab3a83bceef70bb4aR67
expected.put
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
For the syslog header vs message parser this future_use is not really
important. This has other implications than just carrying arbitrary data in a
field that is labeled to do something else.
---
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
8.0 log format is also working now
In the latest two commits I included the changed tests from @justinleet but
changed the expected input from full syslog messages including syslog header
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
Any further comments? The old parser was plain broken. So even if there is
room for improvement here, I would really like to see this merged.
Thanks!
---
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
@ottobackwards Where is the regression? If a user used the parser
previously with a full syslog header it will continue to work the same way. The
result will be the same odd domain field &quo
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
No it's not a requirement. The parser will continue to work the same way as
it did before if you feed it a full syslog line including header. (Which
wouldn't produce a valid domain
GitHub user ctramnitz reopened a pull request:
https://github.com/apache/incubator-metron/pull/537
METRON-864 fix typo in indexing readme
## Contributor Comments
I'm sure this should be "indexing" topology rather than "enrichment"
topology in this pla
Github user ctramnitz closed the pull request at:
https://github.com/apache/incubator-metron/pull/537
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
GitHub user ctramnitz opened a pull request:
https://github.com/apache/incubator-metron/pull/579
METRON-941 fix PaloAltoParser
## Contributor Comments
Fixed comma related issue by using Guava Splitter instead of split
(reproduce: send log message with comma in payload, such as
Github user ctramnitz commented on the issue:
https://github.com/apache/incubator-metron/pull/579
Do you have any examples? The previous concept was to use arbitrary (at
least I couldn't find any reference) field names (i.e. source_address or
destination_address) and then fu
Github user ctramnitz commented on the issue:
https://github.com/apache/incubator-metron/pull/579
I agree to both of your points, defining it with the final name from the
beginning would be more efficient and we should come up with a more normalized
and standardized field naming
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/584
Does this change have any impact on using Storm 1.1 (i.e. from HDP 2.6)?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/531
dhcp also carries a client-id that is often (but not always and not
reliably) the hostname. While not reliable, this is intersting information,
especially since you don't have to pe
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
I updated the mapping to use the Metron name right away and added some more
handling for different versions of the log format. Any other feedback?
---
If your project is set up for it, you can
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
I'm running this myself and actively parsing PaloAlto logs with this change
for about 3 weeks. You can also see that the changes are fairly trivial and
that structure and naming follow
16 matches
Mail list logo