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" <[email protected]> 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" <[email protected]> wrote: > >>Agreed on adding a GUID. >> >>On Fri, Feb 24, 2017 at 8:54 AM, David Lyle <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> > 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 <[email protected]> >>> > 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 < >>> > > [email protected]> >>> > > > 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 >>> > > > > >>> > > > > >>> > > > > >>> > > > >>> > > >>> > >>>
