[
https://issues.apache.org/jira/browse/METRON-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879080#comment-15879080
]
ASF GitHub Bot commented on METRON-701:
---------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/449
I think what I mean is a little different (but maybe I've missed your
point.)
For example, when @james-sirota first reviewed this PR he was confused why
we would send data to Kafka. He thought it was a replacement for HBase, rather
than an addition to that. His mistake was totally understandable. Using terms
like 'kafka' and 'hbase', forces the user to under why they would want to send
profile data to HBase and why they would want to send profile data to Kafka.
It forces the user to know the implementation.
But I am saying that users should not need to know the implementation
details of the Profiler. They should just tell us if they want the profile
data stored for later and whether they want to triage the data from the
Profiler.
So I am suggesting that to be "user focused" we use terms that focus on the
functionality from the user's perspective, not terms based on how we've
implemented the Profiler. A user would tell us to 'triage' or not; they would
not tell us 'kafka' or not.
> Triage Metrics Produced by the Profiler
> ---------------------------------------
>
> Key: METRON-701
> URL: https://issues.apache.org/jira/browse/METRON-701
> Project: Metron
> Issue Type: Improvement
> Reporter: Nick Allen
> Assignee: Nick Allen
>
> h3. Problem
> The motivating example is that I would like to create an alert if the number
> of inbound flows to any host over a 15 minute interval is abnormal.
> The value being interrogated here, the number of inbound flows, is not a
> static value contained within any single telemetry message. This value is
> calculated across multiple messages by the Profiler. The current Threat
> Triage process cannot be used to interrogate values calculated by the
> Profiler.
> h3. Proposed Solution
> I am proposing that we treat the Profiler as a source of telemetry. The
> measurements captured by the Profiler would be enqueued into a Kafka topic.
> We would then treat those Profiler messages like any other telemetry. We
> would parse, enrich, triage, and index those messages.
> This would have the following advantages.
> 1. We would be able to reuse the same threat triage mechanism for values
> calculated by the Profiler.
> 2. We would be able to generate profiles from the profiled data - aka
> meta-profiles anyone?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
