Hello, I am attempting to create a sizing estimate and did not find specific guidance for Kibana, could anyone clarify if there is an official guide? As of now, I am considering this setup to be a single machine:
4 CPUs
16 GB RAM
Storage - not sure about this one, also I believe it does not need to be a SSD.
The use case is not completely defined yet but I would expect to have dashboards using aggregations over an index having 2M documents ingested per day, I am envisaging creating a Transforms job to send aggregated data to another index to make Kibana's life easier.
The post was from elastic team member. He says it is quite light weight.
I suppose Kibana coexisting in Elasticsearch node could be a good start point.
I did see this post before which got me thinking on the requirements needed since it will use the reporting features, I do not know for instance that "X" Number of dashboards running aggregation queries over an index with "X" documents demand "X" CPUs, "Y" Storage capacity and so forth. I agree with your approach as a starting point but was somewhat frustrated for not finding a clear guidance as we see for Elasticsearch here https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf
That's nearly 5 years old @Tomo_M
I would probably add a bit more resources to Kibana these days, as there's substantially more functionality and complexity to it.
Usually the limiting factor with sizing is going to be with Elasticsearch, not Kibana. I'd focus on that first.
@crpj At least, the number of documents in index to be aggregated has no effect on Kibana node sizing. And also just existance of dashboards doesn't matter without reporting.
If you feel frustrated by slow rendering, Kibana is just waiting for the response from Elasticsearch cluster. Even if you enhance the Kibana node, dashboard rendering will not speed up in most cases.
To speed up dashboards, transform is a good strategy. Transform can do the heavy aggregation in Elasticsearch cluster in advance.
In my opinion what affects Kibana sizing should be the number of simultaneous connetions, the enthusiasm for editing the dashboards, the number of accesses to the shared dashboard, etc. I agree that it is nice if there are some guidence for kibana sizing in official document (even if it is not as clear as that of Elasticsearch).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
