You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by "Casey Stella (JIRA)" <ji...@apache.org> on 2016/11/21 20:49:59 UTC

[jira] [Comment Edited] (METRON-567) Usernames as numerics strings attempted to be parsed and compared as numbers

    [ https://issues.apache.org/jira/browse/METRON-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684684#comment-15684684 ] 

Casey Stella edited comment on METRON-567 at 11/21/16 8:49 PM:
---------------------------------------------------------------

Yes, so, looking at this a bit, the Krakken Grok parser is doing this.  If it sees something that it can cast to an int, it'll treat it as an int.  Doing so, will strip leading 0's.

I'd suggest changing the grok statement to as follows:
{{M_DELIMITED "username":%{GREEDYDATA:username},"source":"%{IP:source}","activity":"%{WORD:activity}","event_time":"%{GREEDYDATA:event_time}"}}

Note the lack of quotes around the username field.  What will happen is that it will include the quotes as the string, notice that it's not an integer, then it will strip them out.

Hope this help!

Casey


was (Author: cestella):
Yes, so, looking at this a bit, the Krakken Grok parser is doing this.  If it sees something that it can cast to an int, it'll treat it as an int.  Doing so, will strip leading 0's.

I'd suggest changing the grok statement to as follows:
M_DELIMITED "username":%{GREEDYDATA:username},"source":"%{IP:source}","activity":"%{WORD:activity}","event_time":"%{GREEDYDATA:event_time}"

Note the lack of quotes around the username field.  What will happen is that it will include the quotes as the string, notice that it's not an integer, then it will strip them out.

Hope this help!

Casey

> Usernames as numerics strings attempted to be parsed and compared as numbers
> ----------------------------------------------------------------------------
>
>                 Key: METRON-567
>                 URL: https://issues.apache.org/jira/browse/METRON-567
>             Project: Metron
>          Issue Type: Bug
>    Affects Versions: 0.2.1BETA
>         Environment: Linux CentOS 6.5
> 252GB RAM
> HDP 2.5
> 16TB HDD
>            Reporter: ed de
>            Assignee: Otto Fowler
>            Priority: Minor
>         Attachments: metron-567.zip
>
>
> 1. Windows logs are being ingested through Nifi, most usernames are number (ex: 423191384) 
> 2. Windows parser Grok pattern for element "usrName" has been modified to and from : GREEDYDATA, NUMBER, WORD, USERNAME.
> 3. An enrichment has been flatline loaded into Hbase containing department, manager, firstname, lastname, etc.
> 4. The enrichment works if the usrName is characters (ex: DONALDDUCK)
> 5. The consistent error message is "cannot cast java.lang.Long to java.lang.String". This is readily apparent in the enrichment log under /var/log/storm/enrichment*
> To recreate, build a parser that looks for a username, then build a simple enrichment, then feed a sample of numeric and non-numeric username logs through the system and see which one parses and enriches. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)