[GitHub] metron issue #579: METRON-941 native PaloAlto parser corrupts message when h...

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] metron issue #579: METRON-941 native PaloAlto parser corrupts message when h...

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] metron issue #579: METRON-941 fix PaloAltoParser

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] metron issue #579: METRON-941 fix PaloAltoParser

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] metron issue #579: METRON-941 fix PaloAltoParser

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] metron issue #579: METRON-941 fix PaloAltoParser

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] metron issue #579: METRON-941 fix PaloAltoParser

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] metron issue #579: METRON-941 fix PaloAltoParser

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

[GitHub] metron issue #579: METRON-941 fix PaloAltoParser

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] metron issue #531: METRON-854 create dhcp dump parser

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] metron issue #584: METRON-950: Migrate storm-kafka-client to 1.1

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] incubator-metron issue #579: METRON-941 fix PaloAltoParser

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] incubator-metron issue #579: METRON-941 fix PaloAltoParser

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] incubator-metron pull request #579: METRON-941 fix PaloAltoParser

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] incubator-metron pull request #537: METRON-864 fix typo in indexing readme

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] incubator-metron pull request #537: METRON-864 fix typo in indexing readme

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