[
https://issues.apache.org/jira/browse/METRON-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983176#comment-15983176
]
ASF GitHub Bot commented on METRON-854:
---------------------------------------
Github user basvdl commented on the issue:
https://github.com/apache/incubator-metron/pull/531
@nickwallen, these are indeed the options we have discussed...
> I am going to lay out all of the possibilities that I can think of just
so that we don't leave any stone unturned.
(1) Alter the Source of Telemetry - ...
(2) Use an Alternative Source of Telemetry - ...
(3) Reunite lines at the parser - ...
(4) Transport Mechanism - ...
1. Alter the Source of Telemetry - I agree with you that this is the least
preferred method.
2. Use an Alternative Source of Telemetry - The alternative I've looked
into was `tcpdump`, but this is less detailed.
3. Reunite lines at the parser - This will not give you a reliable
solution, mainly due to the reason you have given: 'We cannot rely on ordering
of the messages'
4. Transport Mechanism - In our case we are shipping the log using
(Mi)NiFi. We could look into a custom NiFi processor.
Another option that just came as a brainwave, maybe we can develop a kind
of yaf / yafscii solution. Where you pipe the output of DHCPDump into the stdin
of a `DHCPDumpToSingleLine` which will stitch the lines together and output
single line events to disk.
> Create DHCPDump Parser
> ----------------------
>
> Key: METRON-854
> URL: https://issues.apache.org/jira/browse/METRON-854
> Project: Metron
> Issue Type: New Feature
> Reporter: Bas van de Lustgraaf
> Priority: Minor
> Labels: parser
>
> Create a DHCPDump parser. This information can be used during enrichment to
> link ip-addresses to hostnames.
> {noformat}
> TIME: 2017-01-16 16:54:21.655|INTERFACE: eth2|OP:1 BOOTPREQUEST|CIADDR:
> 172.20.75.77|YIADDR: 0.0.0.0|SIADDR: 0.0.0.0|GIADDR: 172.20.75.8|CHADDR:
> fc:f8:ae:e8:ef:db:00:00:00:00:00:00:00:00:00:00|OPTION: 53 1 DHCP message
> type: 8 |DHCPINFORM|OPTION: 61 7 Client-identifier:
> 01:fc:f8:ae:e8:ef:db|OPTION: 12 5 Host name: Q1244|OPTION: 60 8 Vendor
> class identifier: MSFT 5.0|OPTION: 55 13 Parameter Request List: 1
> (Subnet mask)|| 15 (Domainname)|| 3 (Routers)|| 6 (DNS server)|| 44
> (NetBIOS name server)|| 46 (NetBIOS node type)|| 47 (NetBIOS scope)|| 31
> (Perform router discovery)|| 33 (Static route)||121 (Classless Static
> Route)||249 (MSFT - Classless route)|| 43 (Vendor specific info)||252 (MSFT -
> WinSock Proxy Auto Detect)|||IP: 10.10.10.177 > 172.20.1.11 |
> b8:ca:3a:67:95:8a > 0:50:56:84:68:43
> TIME: 2017-01-16 17:13:14.548|INTERFACE: eth2|OP:1 BOOTPREQUEST|CIADDR:
> 172.20.75.77|YIADDR: 0.0.0.0|SIADDR: 0.0.0.0|GIADDR: 172.20.75.8|CHADDR:
> fc:f8:ae:e8:ef:db:00:00:00:00:00:00:00:00:00:00|OPTION: 53 1 DHCP message
> type: 8 |DHCPINFORM|OPTION: 61 7 Client-identifier:
> 01:fc:f8:ae:e8:ef:db|OPTION: 12 5 Host name: Q1244|OPTION: 60 8 Vendor
> class identifier: MSFT 5.0|OPTION: 55 13 Parameter Request List: 1
> (Subnet mask)|| 15 (Domainname)|| 3 (Routers)|| 6 (DNS server)|| 44
> (NetBIOS name server)|| 46 (NetBIOS node type)|| 47 (NetBIOS scope)|| 31
> (Perform router discovery)|| 33 (Static route)||121 (Classless Static
> Route)||249 (MSFT - Classless route)|| 43 (Vendor specific info)||252 (MSFT -
> WinSock Proxy Auto Detect)|||IP: 10.10.10.177 > 172.20.1.10 |
> b8:ca:3a:67:95:8a > 0:50:56:b9:28:ac
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
