You know, I am going to back this up.
I usually thing of replay as replay, profiler or not, but that is not true.
Replay of data through the full pipeline (parsers/enrichement) has more
consequences or concerns, so we can drop this.
I don’t want to expand the scope of your idea. We can reuse/refactor to
the other case (parser + enrichment) later.
So, about re-writing.
If we replay a set of data with a new version of a profile I think it will
always have to be a new profile and not ‘replace’
the old one. Series1, Seriers2 etc?
On February 2, 2018 at 17:24:46, Nick Allen (n...@nickallen.org) wrote:
I think that is definitely a reasonable extension.
In this case would we need any additional actions to indicate that data
will be overwritten?
I am trying to think of other additional needs that this use case has over
On Feb 2, 2018 12:38 PM, "Otto Fowler" <ottobackwa...@gmail.com> wrote:
> Scenario 3:
> As a Security ? I have modified a profile or parser configuration (
> replay is replay ), and I want to run the new version
> against my old data.
> On February 2, 2018 at 12:19:54, Nick Allen (n...@nickallen.org) wrote:
> I have been thinking about an enhancement to the Profiler for quite some
> time. Actually, my first pass at defining this was called "Replay
> Telemetry through Profiler" back in METRON-594 .
> I'd like to first discuss the use case to make sure we start out on the
> right foot. Here is how I would define the use cases for this
> *> Scenario 1: Model Development*
> As a Security Data Scientist, I want to understand the historical behaviors
> and trends of a profile that I have created so that I can understand if it
> is valuable for model building.
> There are two possible negative outcomes that the Security Data Scientist
> must be aware of when creating profiles.
> - The profile might have been defined incorrectly resulting in a feature
> set that does not match reality (a bug in the profile definition).
> - The profile might have been defined correctly, but the feature set
> itself has no predictive value.
> Analyzing the profile over archived, historical telemetry allows the
> Security Data Scientist to better to mitigate both of these negative
> *> Scenario 2: Model Deployment*
> As a Security Platform Engineer, I want to generate a profile using
> archived telemetry when I deploy a new model to production so that models
> depending on that profile can begin to function on day 1.
> (Q) Do these make sense? Am I missing anything? Too broad or too narrow?
> Once we nail down the use case(s), I'll delete the old JIRA and create a
> new JIRA with the use cases. That would give us a place to start on the
> technical details of the implementation.
>  https://issues.apache.org/jira/browse/METRON-594