Where to install Kibana?


(Turbo Fredriksson) #1

I'm trying to setup my own ES service in AWS because the native AWS service isn't any where near enough suitable for what we need. It was nice and simple for us to get up and running, but we've now outgrown it..

At the moment, I have (for our devel/test/pre-release cluster):

2x Coordinating nodes (with a AWS ALB in front of them for user/client access)
3x Master eligible nodes
1x Ingest node (don't need it, but ES complained when I didn't have one)
3x Data nodes (only needed/wanted two, but because of the "note.attr" and "awareness.force" etc, I needed at least one in each AZ).

I've installed X-Pack (the free one at the moment) on all of them and managed to get it setup (roughly) the way I want it. I'm assuming that was right?

My ES cluster is ONLY accessible via the ALB (everything else is blocked via the security groups, and only the ALB allow HTTP access, with HTTPS offloading to the coordinating nodes) and only the Coordinating nodes have HTTP enabled (and allows access only from the ALB)...

So the question is, where do I install Kibana? On all of them (sounds like overkill) or only on the Coordinating nodes? Or do/should I have a separate Kibana host(s)?

I've planned a two-instance monitoring cluster next to this one, but I haven't started that up yet.. Maybe I should have Kibana on that one (with an(other) ALB infront of those instances)?


(Spencer Alger) #2

Disclaimer: my exposure to this stuff is mostly "academic". Elastic support is really helpful when it comes to resource planning, and a service like https://cloud.elastic.co prevent you from having to worry about this at all.

In case you haven't already, I recommend reading https://www.elastic.co/guide/en/kibana/6.2/production.html. We recommend against running Kibana on the same machine as your Elasticsearch master or data nodes, which might mean that you could put them on the hosts running your coordinating nodes, but I think it's important to remember that coordinating nodes can still do a decent amount of work depending on the query types and frequency.

If your coordinating nodes are primarily to power Kibana and/or would like to avoid extra hosts if possible then I would experiment with running them together. If you're not often running queries that will bog-down the coordinating nodes, or your hosts are beefy enough, then it could work fine. It really depends on your usage.

If the number of hosts is somewhat irrelevant, or Kibana is more of an ancillary service, or you just want the most resilient deployment possible, then I would isolate the Kibana instances to separate hosts and load balance across them.


(Turbo Fredriksson) #3

Ok, so those where the lines I was thinking along myself... I do want to keep the coordinating nodes "clean" (they'll have enough on their hands eventually to also have to run Kibana).

So separate node(s) it is then. I think, because it's "only" for looking at stats etc (?), I don't need them highly available. If the Kibana node goes down and it takes me/the ASG x minutes to get back up, it's not a big deal..

Thanx for the input.


(Mark Walkom) #4

You can definitely run another two coordinating nodes with Kibana on those, and then load balance them.

But how fault tolerant do you want to be and at what cost?


(system) #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.