[
https://issues.apache.org/jira/browse/METRON-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671013#comment-15671013
]
Otto Fowler commented on METRON-567:
------------------------------------
from [~cestella]
The core problem, from my understanding, is that the HBase enrichment does
not support non-strings as keys and it's making the assumption that the
indicator being passed is a String. In this case, it's a Long. CacheKey
is a more general object and should be allowed to not be string dependent.
In fact, there is already a method that is called "coerceValue" to coerce
the value into the type of your choosing.
In my opinion, the bug that this JIRA has unearthed is that we're making
the assumptions on the cache key that we are not handling when doing HBase
enrichments. This, I think should be corrected by coercing the value into
a String type when doing HBase enrichments, which would mean changing the
"getValue" calls to "coerceValue" calls at the following places:
- SimpleHBaseAdapter line 79
- ThreatIntelAdapter line 80 and line 60
and converting the indicator argument to a String on line 148 of
SimpleHBaseEnrichmentFunctions
The other argument is that we should just be throwing a better error
message and insist that the data comes in as a consistent type. I'm not so
fond of this argument, personally.
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)
