Github user ottobackwards commented on the issue:

    https://github.com/apache/metron/pull/711
  
    part of the issue is there is no use case for how this is going to be used 
beyond the general.  How often do analysts that have possibly 1000s of alerts 
find the one magic alert?
    
    I can imagine a flow in the ui like:
    
    Do some queries and dig around, select some set of alerts from there to 
escalate, get an escalate dialog where you add some info, fill out some fields 
required for target routing etc ( so you need per target config unless you are 
going to automate it with nifi in-between? ) and then send the alerts as a set.
    
    Aside from that, to restate where I am coming from:
    
    * it is my exp. that escalateTheseAlerts is preferable and more practical 
than escalateThisOneAlert
    * it is my exp. that most query api with possibly huge returns, paging etc 
for dense data objects ( remember the original string etc ) try to return 
contextually appropriate subsets of the data, across different network zones 
etc for performance etc, and the assumption that what the UI has is what you 
need to push to the other system is not a good one.  There is def. a tradeoff 
between optimizing for server-client ( only send what you need to, LDAP comes 
to mind for example, you get the props you need ) and not wanting to make other 
ES/? calls to get the real data.
    
    These things are worth talking about though.
    
    At this point in our REST api, we only have the main readme.  So just the 
call descriptions.  We don't have examples, more in depth docs per call or 
anything.  That is just were we are at.  But in the context of the PR I think 
we can talk about the call patterns, and maybe we should have a usage example.  
Since we did not have a DISCUSS on this before hand, the PR is it.
    
    
    
    
    
    



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to