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 [email protected] or file a JIRA ticket
with INFRA.
---
