Elasticsearch Datehistogram Interval

[Soumen_Das]

I am creating a date histogram aggregation like this, where min and max of extended_bounds are unix epoch values.

    "aggs": {
        "0": {
          "date_histogram": {
            "field": "@timestamp",
            "fixed_interval": "30s",
            "time_zone": "Asia/Kolkata",
            "extended_bounds": {
              "min": 1656419435318,
              "max": 1656420335318
            }   
          }
        }
      }

Now I am using "30s" as hard-coded value for fixed_interval value.

How can this value be dynamically generated depending on the duration of the bounds (min & max of extended bounds), if I want same number of buckets for each duration? Is there any function available from any kibana plugins for this purpose?

For example if I want 30 buckets:

(a) for 1 hour duration, fixed_interval will be 2 mins

(b) for 24 hours, fixed_interval will be 45 mins

I can write code of own to do this calculation, but any existing api would be helpful.

Also, when to use calendar_interval in place of fixed_interval. I have checked kibana lens generated queries, where depending of search duration fixed_interval or calendar_interval is used.

[warkolm (Mark Walkom)]

Welcome to our community!

I don't think there is a way to do this automatically unfortunately, it's not something I have seen a lot of people ask for. It might make an interesting feature request if you wanted to raise it?

@Soumen_Das

Also, when to use calendar_interval in place of fixed_interval

To quote the docs - Date histogram aggregation | Elasticsearch Guide [8.11] | Elastic;

When configuring a date histogram aggregation, the interval can be specified in two manners: calendar-aware time intervals, and fixed time intervals.

Calendar-aware intervals understand that daylight savings changes the length of specific days, months have different amounts of days, and leap seconds can be tacked onto a particular year.

Fixed intervals are, by contrast, always multiples of SI units and do not change based on calendaring context.