I'll second Otto's suggestion. I like the idea of "splitting" the ES and Kibana components from the pure Metron components. I suppose that would mean having two mpacks to build for a while though.
I agree with others that, at least for now, Kibana is an integral part of the Metron user experience. -Kyle On Wed, Nov 1, 2017 at 7:37 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > It would not be installed with/by Metron. You'd install and manage Kibana > on your own. Some things can be done with the head plugin, but it wouldn't > be as pretty. > > From the sounds of it the community still uses and wants Kibana, so we'll > hold off until the UI can manage more of this functionality. Thanks > everyone for the input. > > On Nov 1, 2017 4:18 PM, "Laurens Vets" <laur...@daemon.be> wrote: > > > How would I do that without Kibana? Having a SIEM without the ability to > > see raw processed events (whether they are alerts or not), would be a big > > issue I think. > > > > Or would Kibana always be required, just not installed by Metron? > > > > On 2017-11-01 11:34, Michael Miklavcic wrote: > > > >> You could absolutely still do it, I'm simply saying it would not be > >> managed > >> by us. > >> > >> On Nov 1, 2017 12:20 PM, "Laurens Vets" <laur...@daemon.be> wrote: > >> > >> If there's a viable way of looking at raw processed events (not > >>> necessarily alerts), then I'm all for removeing Kibana. I use Discover > a > >>> lot to filter and look at events and create new policies from that. > >>> > >>> Is there currently a simple way to do this without Kibana? > >>> > >>> On 2017-11-01 09:13, Michael Miklavcic wrote: > >>> > >>> As part of the ES upgrade, I got to thinking that it makes sense to > >>>> remove > >>>> Kibana and the dashboards we're currently bundling in the MPack. To be > >>>> clear, this would not remove the ability to independently install and > >>>> use > >>>> Kibana if the user so chooses, it would only remove the dashboards, > and > >>>> potentially, the Ambari/MPack management support that we ship. > >>>> > >>>> *pros* > >>>> Removes need to support tooling outside our wheelhouse > >>>> Smaller testing effort for ongoing support and future upgrades > >>>> Simplifies our base Metron install via Ambari. Also simplifies full > dev > >>>> setup. > >>>> > >>>> *cons* > >>>> User would need to install and setup their own Kibana instance and > >>>> dashboards. > >>>> If any existing users are using this, they'd need to backup and manage > >>>> their own Kibana dashboards going forward. They would also need to > >>>> handle > >>>> any upgrade issues with Kibana post-Metron ES 5.x upgrade. > >>>> > >>>> Any concerns? > >>>> > >>>> Mike > >>>> > >>> >
