Session State and Load Balancing Kibana 4

(Matt Hughes) #1

Unlike Kibana 3, Kibana 4 stores user session state in the Kibana server. Is that accurate?

If this is true, how would one load balance Kibana? I could configure my load balancer to be sticky, but that would require me to terminate SSL at the LB, not Kibana, something I can't do.

I think I can get around this by setting the following fields:

elasticsearch.preserveHost: true ipOfKibanaHostNotLoadBalancer

If Kibana is storing session state in its server, I believe this will ensure that all requests go back to the server that served up this config file. So, as long as the user doesn't do a hard browser refresh, they should always hit the same server.

Can you tell me if this is accurate? What is stored in session state? What are the consequences of doing a hard-refresh in the browser and getting sent to a different Kibana server?

(Joe Fleming) #2

I'm not sure what you mean by session state. The state of the app in Kibana 4 is actually stored in the URL. The user session is stored in the browser session, or in some cases, in localstorage. Long-term storage (saved visualizations and dashboard, for example) is all persisted in Elasticsearch, so if your Kibana instances are all talking to the same node, you shouldn't have any issue load balancing them.

(Matt Hughes) #3

So if the server has no state, what does it do? It just proxies interaction with Elasticsearch for some performance benefit?

(Joe Fleming) #4

Right now, yes, it's really just a proxy layer and file server. That proxy makes it so users don't need to worry about CORS mostly, and it allows us to provide a very, very rudimentary layer of protection by whitelisting the types of requests a user can make (mostly blocking DELETEs through the proxy).

In the future we may offload more to the server, but I don't think that application and user state are likely to be included.

(system) #5