Re: [DISCUSS] Metron Alerts UI

[Houshang Livian]

Field Selection and Easy Filtering: 

If we make every field value clickable as a filter that would work, so I can 
click on any result in any column to refine the list. 

Also, maybe we add some metrics for scores that sit above the table. These 
metrics can also be filters to refine the results below them.





On 2/24/17, 10:54 AM, "Houshang Livian"  wrote:

>Escalate: This is essentially just a flag on the message
>Escalate to Ticketing: If we take these messages and add them to a Kafka Topic 
>would that work? Then people can write scripts that listen to that Topic.
>Double Column Sort: Interesting, Let me think about that.
>Alert ID: +1 for a trackable GUID that isn’t 1,200 characters long
>Table Configure: Great idea, I’ll design it in
>
>
>
>On 2/24/17, 7:08 AM, "Ryan Merriman"  wrote:
>
>>Agreed on adding a GUID.
>>
>>On Fri, Feb 24, 2017 at 8:54 AM, David Lyle  wrote:
>>
>>> Yeah, +1 to that. We'll definitely need a GUID (well, event ID, so GUEID).
>>> Probably calculated pre-parse.
>>>
>>> -D...
>>>
>>>
>>> On Fri, Feb 24, 2017 at 9:48 AM, Casey Stella  wrote:
>>>
>>> > Regarding alert ID, it seems like this is the kind of thing which should
>>> be
>>> > uniform for all the different types of indices: solr and HDFS.  You might
>>> > (and probably do) want to be able to join between IDs in HDFS and ES or
>>> > Solr, for instance, so it probably shouldn't be tied to the ES ID.  We
>>> > might want to make a Metron ID that is baked into the parsers and is a
>>> > SHA-2 hash of the data.
>>> >
>>> >
>>> >
>>> > On Fri, Feb 24, 2017 at 9:29 AM, Ryan Merriman 
>>> > wrote:
>>> >
>>> > > Related to the 'What does "Escalate" do' question, one topic that needs
>>> > > some discussion is how we integrate with 3rd party ticketing systems.
>>> > How
>>> > > should we design this extension point?  Some basic requirements could
>>> be
>>> > > that a call is made to somewhere with the alert as the payload and some
>>> > > kind of ticket or issue id is received as a response.  This is a very
>>> > > open-ended question and there are likely several different ways we go
>>> do
>>> > > it.
>>> > >
>>> > > As for Casey's other points:
>>> > >
>>> > > - The most obvious choice for alert id would be the id in
>>> elasticsearch.
>>> > > Are there other ids we should consider?
>>> > > - Configurable display fields makes a lot of sense to me and should not
>>> > be
>>> > > complex to implement.
>>> > > - Agreed on offering intuitive ways to filter messages by fields.
>>> > >
>>> > > Ryan
>>> > >
>>> > > On Thu, Feb 23, 2017 at 6:42 PM, Casey Stella 
>>> > wrote:
>>> > >
>>> > > >- What does "Escalate" do exactly?
>>> > > >- Where does the Alert ID come from?
>>> > > >- Are the fields displayed configurable?
>>> > > >- It'd be nice to be able to select a set of fields for a message
>>> > and
>>> > > >have the list of messages filter to just those where those fields
>>> > are
>>> > > > the
>>> > > >same as the one viewed.
>>> > > >
>>> > > >
>>> > > > On Thu, Feb 23, 2017 at 3:24 PM, Houshang Livian <
>>> > > hliv...@hortonworks.com>
>>> > > > wrote:
>>> > > >
>>> > > > > Hello Metron Community,
>>> > > > >
>>> > > > > We have mocked up an Alerts UI for Metron for your consideration.
>>> > > Please
>>> > > > > take a look and share your thoughts.
>>> > > > >
>>> > > > > Here is a link to our thoughts on this:
>>> > > > > http://imgur.com/a/KMTKN
>>> > > > >
>>> > > > > Does this look like a reasonable place to start?
>>> > > > > Is there anything that is an absolute MUST have or MUST NOT have?
>>> > > > >
>>> > > > > Houshang Livian
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>

Re: [DISCUSS] Metron Alerts UI

[Houshang Livian]

Escalate: This is essentially just a flag on the message
Escalate to Ticketing: If we take these messages and add them to a Kafka Topic 
would that work? Then people can write scripts that listen to that Topic.
Double Column Sort: Interesting, Let me think about that.
Alert ID: +1 for a trackable GUID that isn’t 1,200 characters long
Table Configure: Great idea, I’ll design it in



On 2/24/17, 7:08 AM, "Ryan Merriman"  wrote:

>Agreed on adding a GUID.
>
>On Fri, Feb 24, 2017 at 8:54 AM, David Lyle  wrote:
>
>> Yeah, +1 to that. We'll definitely need a GUID (well, event ID, so GUEID).
>> Probably calculated pre-parse.
>>
>> -D...
>>
>>
>> On Fri, Feb 24, 2017 at 9:48 AM, Casey Stella  wrote:
>>
>> > Regarding alert ID, it seems like this is the kind of thing which should
>> be
>> > uniform for all the different types of indices: solr and HDFS.  You might
>> > (and probably do) want to be able to join between IDs in HDFS and ES or
>> > Solr, for instance, so it probably shouldn't be tied to the ES ID.  We
>> > might want to make a Metron ID that is baked into the parsers and is a
>> > SHA-2 hash of the data.
>> >
>> >
>> >
>> > On Fri, Feb 24, 2017 at 9:29 AM, Ryan Merriman 
>> > wrote:
>> >
>> > > Related to the 'What does "Escalate" do' question, one topic that needs
>> > > some discussion is how we integrate with 3rd party ticketing systems.
>> > How
>> > > should we design this extension point?  Some basic requirements could
>> be
>> > > that a call is made to somewhere with the alert as the payload and some
>> > > kind of ticket or issue id is received as a response.  This is a very
>> > > open-ended question and there are likely several different ways we go
>> do
>> > > it.
>> > >
>> > > As for Casey's other points:
>> > >
>> > > - The most obvious choice for alert id would be the id in
>> elasticsearch.
>> > > Are there other ids we should consider?
>> > > - Configurable display fields makes a lot of sense to me and should not
>> > be
>> > > complex to implement.
>> > > - Agreed on offering intuitive ways to filter messages by fields.
>> > >
>> > > Ryan
>> > >
>> > > On Thu, Feb 23, 2017 at 6:42 PM, Casey Stella 
>> > wrote:
>> > >
>> > > >- What does "Escalate" do exactly?
>> > > >- Where does the Alert ID come from?
>> > > >- Are the fields displayed configurable?
>> > > >- It'd be nice to be able to select a set of fields for a message
>> > and
>> > > >have the list of messages filter to just those where those fields
>> > are
>> > > > the
>> > > >same as the one viewed.
>> > > >
>> > > >
>> > > > On Thu, Feb 23, 2017 at 3:24 PM, Houshang Livian <
>> > > hliv...@hortonworks.com>
>> > > > wrote:
>> > > >
>> > > > > Hello Metron Community,
>> > > > >
>> > > > > We have mocked up an Alerts UI for Metron for your consideration.
>> > > Please
>> > > > > take a look and share your thoughts.
>> > > > >
>> > > > > Here is a link to our thoughts on this:
>> > > > > http://imgur.com/a/KMTKN
>> > > > >
>> > > > > Does this look like a reasonable place to start?
>> > > > > Is there anything that is an absolute MUST have or MUST NOT have?
>> > > > >
>> > > > > Houshang Livian
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

Re: [DISCUSS] Metron Alerts UI

[Anand Subramanian]

Hello Houshang,

Would it be a good idea to have two levels of sorting on the columns? For e.g. 
If a user would like to sort by alert score, and within them sort by Age. That 
way, a SOC analyst can get to the most recent critical events.

Thanks,
Anand



On 2/24/17, 4:54 AM, "Houshang Livian"  wrote:

>Hello Metron Community,
>
>We have mocked up an Alerts UI for Metron for your consideration. Please take 
>a look and share your thoughts.
>
>Here is a link to our thoughts on this:
>http://imgur.com/a/KMTKN
>
>Does this look like a reasonable place to start?
>Is there anything that is an absolute MUST have or MUST NOT have?
>
>Houshang Livian
>
>

Re: [DISCUSS] Metron Alerts UI

[Casey Stella]

Regarding alert ID, it seems like this is the kind of thing which should be
uniform for all the different types of indices: solr and HDFS.  You might
(and probably do) want to be able to join between IDs in HDFS and ES or
Solr, for instance, so it probably shouldn't be tied to the ES ID.  We
might want to make a Metron ID that is baked into the parsers and is a
SHA-2 hash of the data.



On Fri, Feb 24, 2017 at 9:29 AM, Ryan Merriman  wrote:

> Related to the 'What does "Escalate" do' question, one topic that needs
> some discussion is how we integrate with 3rd party ticketing systems.  How
> should we design this extension point?  Some basic requirements could be
> that a call is made to somewhere with the alert as the payload and some
> kind of ticket or issue id is received as a response.  This is a very
> open-ended question and there are likely several different ways we go do
> it.
>
> As for Casey's other points:
>
> - The most obvious choice for alert id would be the id in elasticsearch.
> Are there other ids we should consider?
> - Configurable display fields makes a lot of sense to me and should not be
> complex to implement.
> - Agreed on offering intuitive ways to filter messages by fields.
>
> Ryan
>
> On Thu, Feb 23, 2017 at 6:42 PM, Casey Stella  wrote:
>
> >- What does "Escalate" do exactly?
> >- Where does the Alert ID come from?
> >- Are the fields displayed configurable?
> >- It'd be nice to be able to select a set of fields for a message and
> >have the list of messages filter to just those where those fields are
> > the
> >same as the one viewed.
> >
> >
> > On Thu, Feb 23, 2017 at 3:24 PM, Houshang Livian <
> hliv...@hortonworks.com>
> > wrote:
> >
> > > Hello Metron Community,
> > >
> > > We have mocked up an Alerts UI for Metron for your consideration.
> Please
> > > take a look and share your thoughts.
> > >
> > > Here is a link to our thoughts on this:
> > > http://imgur.com/a/KMTKN
> > >
> > > Does this look like a reasonable place to start?
> > > Is there anything that is an absolute MUST have or MUST NOT have?
> > >
> > > Houshang Livian
> > >
> > >
> > >
> >
>

Re: [DISCUSS] Metron Alerts UI

[Ryan Merriman]

Related to the 'What does "Escalate" do' question, one topic that needs
some discussion is how we integrate with 3rd party ticketing systems.  How
should we design this extension point?  Some basic requirements could be
that a call is made to somewhere with the alert as the payload and some
kind of ticket or issue id is received as a response.  This is a very
open-ended question and there are likely several different ways we go do
it.

As for Casey's other points:

- The most obvious choice for alert id would be the id in elasticsearch.
Are there other ids we should consider?
- Configurable display fields makes a lot of sense to me and should not be
complex to implement.
- Agreed on offering intuitive ways to filter messages by fields.

Ryan

On Thu, Feb 23, 2017 at 6:42 PM, Casey Stella  wrote:

>- What does "Escalate" do exactly?
>- Where does the Alert ID come from?
>- Are the fields displayed configurable?
>- It'd be nice to be able to select a set of fields for a message and
>have the list of messages filter to just those where those fields are
> the
>same as the one viewed.
>
>
> On Thu, Feb 23, 2017 at 3:24 PM, Houshang Livian 
> wrote:
>
> > Hello Metron Community,
> >
> > We have mocked up an Alerts UI for Metron for your consideration. Please
> > take a look and share your thoughts.
> >
> > Here is a link to our thoughts on this:
> > http://imgur.com/a/KMTKN
> >
> > Does this look like a reasonable place to start?
> > Is there anything that is an absolute MUST have or MUST NOT have?
> >
> > Houshang Livian
> >
> >
> >
>

Re: [DISCUSS] Metron Alerts UI

[Casey Stella]

   - What does "Escalate" do exactly?
   - Where does the Alert ID come from?
   - Are the fields displayed configurable?
   - It'd be nice to be able to select a set of fields for a message and
   have the list of messages filter to just those where those fields are the
   same as the one viewed.


On Thu, Feb 23, 2017 at 3:24 PM, Houshang Livian 
wrote:

> Hello Metron Community,
>
> We have mocked up an Alerts UI for Metron for your consideration. Please
> take a look and share your thoughts.
>
> Here is a link to our thoughts on this:
> http://imgur.com/a/KMTKN
>
> Does this look like a reasonable place to start?
> Is there anything that is an absolute MUST have or MUST NOT have?
>
> Houshang Livian
>
>
>