Before you begin reading this guide, we recommend you try running the Elasticsearch Error Check-Up which can resolve issues that cause many errors.
This guide will help you check for common problems that cause the log ” can’t round a histogram ” to appear. It’s important to understand the issues related to the log, so to get started, read the general overview on common issues and tips related to the Elasticsearch concepts: plugin and aggregations.
Advanced users might want to skip right to the common problems section in each concept or try running the Check-Up which analyses ES to pinpoint the cause of many errors and provides suitable actionable recommendations how to resolve them (free tool that requires no installation).
Overview
A plugin is used to enhance the core functionalities of Elasticsearch. Elasticsearch provides some core plugins as a part of their release installation. In addition to those core plugins, it is possible to write your own custom plugins as well. There are several community plugins available on GitHub for various use cases.
Examples
Get all the instructions for the plugin
sudo bin/elasticsearch-plugin -h
Installing the S3 plugin for storing Elasticsearch snapshots on S3
sudo bin/elasticsearch-plugin install repository-s3
Removing a plugin
sudo bin/elasticsearch-plugin remove repository-s3
Installing a plugin using the file’s path
sudo bin/elasticsearch-plugin install file:///path/to/plugin.zip
Notes and good things to know
- Plugins are installed and removed using the elasticsearch-plugin script, which ships as a part of the Elasticsearch installation and can be found inside the bin/ directory of the Elasticsearch installation path.
- A plugin has to be installed on every node of the cluster and each of the nodes has to be restarted to make the plugin visible.
- You can also download the plugin manually and then install it using the elasticsearch-plugin install command, providing the file name/path of the plugin’s source file.
- When a plugin is removed, you will need to restart every elasticsearch node in order to complete the removal process.
Common issues
- Managing permission issues during and after plugin installation is the most common problem. If Elasticsearch was installed using the deb or rpm package then the plugin has to be installed using the root user, or else you can install the plugin as the user that owns all of the Elasticsearch files.
- In case of deb or rpm package installation, it is important to check the permission of the plugins directory after plugin installation and update the permission if it has been modified using the following command:
chown -R elasticsearch:elasticsearch path_to_plugin_directory
- If your Elasticsearch nodes are running in a private subnet without internet access, you cannot install a plugin directly. In this case, you can simply download the plugins at once and copy the files inside the plugins directory of the Elasticsearch installation path on every node. The node has to be restarted in this case as well.
Aggregations in Elasticsearch
What is an Elasticsearch aggregation?
In Elasticsearch, an aggregation is a collection or the gathering of related things together. The aggregation framework collects data based on the documents that match a search request which helps in building summaries of the data. Below are the different types of aggregations:
Types of aggregations
- Bucket aggregations: Bucket aggregations create buckets or sets of documents based on values of fields in the documents. When the aggregation is performed, the documents are placed in the respective bucket(s). This way you can divide a set of invoices into several buckets, one for each customer, system logs can be divided into “error”,”warning” and “info”, or CPU performance data divided into hourly buckets. The output consists of a list of buckets, each with a key and a count of documents. Here are some examples of bucket aggregations: Histogram Aggregation, Range Aggregation, Terms Aggregation, Filter(s) Aggregations, Geo Distance Aggregation and IP Range Aggregation.
- Metric aggregations: Metric aggregation mainly refers to the mathematical calculations performed across a set of documents, usually based on the values of a numerical field present in the document, such as COUNT, SUM, MIN, MAX, AVERAGE etc. Metrics may be carried out at top level, but are often more useful as a sub aggregation to calculate values for a bucket aggregation.
- Pipeline aggregations: These aggregations allow you to aggregate based on the result of another aggregation rather than from document sets. Typically this aggregation is used to find the average number of documents in a bucket, or to sort buckets based upon a metric produced by a metric aggregation.
Aggregation syntax
GET /logs-000001/_search { "aggs": { "errors": { "terms": { "field": "log_type" } } } }
The above query does two things: The “query” part selects a number of documents from the index (the number of documents in the “hits” output, not the actual documents returned), while the aggregation (which is at the same level in the json) will split the document into buckets determined by the contents of the log_type field.
Nesting aggregations
It is possible to nest aggregations inside one another (nothing to do with nested fields), so as to divide the buckets into sub buckets, or to calculate metrics from the sub buckets. The below aggregation will separate out all exam results by gender of the pupil and then calculate the average results for each gender. In this case, the important thing to understand is that the second aggregation will be calculated on the individual set of the bucket rather than the document set as a whole.
POST exam_results*/_search { "size": 0, "aggs": { "genders": { "terms": { "field": "gender" }, "aggs": { "avg_grade": { "avg": { "field": "grades" } } } } } }
Aggregation performance
Aggregations are typically carried out in RAM memory, and require a different document access structure than a search query that is obtained from the inverted index, so it is important to consider the implication of performance when constructing your aggregations. The most important considerations are:
Number of buckets
This would be controlled by the “size” parameter in a terms aggregation, or the “calendar interval” in a date histogram. Bear in mind that where you have bucket aggregations nested at more than one level, then the total number of buckets will be multiplied for each level of aggregation.
Number of documents
When running an aggregation,it is preferable (if possible) to adjust the query so that your aggregation is only performed on a restricted set of those documents that you are interested in, instead of using a match_all query. This will reduce the memory required to run the aggregation.
Fielddata
Aggregations as a rule should always be run on keyword type fields, not analysed text. It is possible to run on analyzed text by using the mapping setting “fielddata”:”true” but this is highly memory intensive and should be avoided if possible.
Log Context
Log”can’t round a [histogram]”classname is HistogramValuesSource.java We extracted the following from Elasticsearch source code for those seeking an in-depth context :
public abstract HistogramValues getHistogramValues(LeafReaderContext context) throws IOException; @Override public FunctionroundingPreparer(IndexReader reader) throws IOException { throw new AggregationExecutionException("can't round a [histogram]"); } public static class Fielddata extends Histogram { protected final IndexHistogramFieldData indexFieldData;