Change time filter quick ranges default settings

[flash1293]

If the time range is large enough to hit multiple shards, we should try to keep the start of the range stable so the shards containing data can leverage their request cache.

Right now a lot of the default quick ranges look like this:

  {
    "from": "now-30m",
    "to": "now",
    "display": "Last 30 minutes"
  }

This compiles to a filter like this (note the uneven gte):

"range": {
            "timestamp": {
              "gte": "2021-05-19T13:34:29.128Z",
              "lte": "2021-05-19T14:04:29.128Z",
              "format": "strict_date_optional_time"
            }
          }

Refreshing after a few seconds leads to a filter like this:

"range": {
            "timestamp": {
              "gte": "2021-05-19T13:34:33.764Z",
              "lte": "2021-05-19T14:04:33.764Z",
              "format": "strict_date_optional_time"
            }
          }

With a lower bound rounded to the minute it would look like this:

"range": {
            "timestamp": {
              "gte": "2021-05-19T13:34:00.000Z",
              "lte": "2021-05-19T14:04:33.764Z",
              "format": "strict_date_optional_time"
            }
          }

These defaults would play better with caches without changing the user experience in a meaningful way:

[
  {
    "from": "now/d",
    "to": "now/d",
    "display": "Today"
  },
  {
    "from": "now/w",
    "to": "now/w",
    "display": "This week"
  },
  {
    "from": "now-15m/m",
    "to": "now",
    "display": "Last 15 minutes"
  },
  {
    "from": "now-30m/m",
    "to": "now",
    "display": "Last 30 minutes"
  },
  {
    "from": "now-1h/m",
    "to": "now",
    "display": "Last 1 hour"
  },
  {
    "from": "now-24h/h",
    "to": "now",
    "display": "Last 24 hours"
  },
  {
    "from": "now-7d/d",
    "to": "now",
    "display": "Last 7 days"
  },
  {
    "from": "now-30d/d",
    "to": "now",
    "display": "Last 30 days"
  },
  {
    "from": "now-90d/d",
    "to": "now",
    "display": "Last 90 days"
  },
  {
    "from": "now-1y/d",
    "to": "now",
    "display": "Last 1 year"
  }
]

Not sure who owns this (I'm guessing @elastic/kibana-app-services ?)

cc @nik9000

[flash1293]

@ppisljar What do you think about this change? Happy to prepare a PR if you are fine with it

[nik9000]

Performance wise this is more important in the "last 24 hours" case and beyond. For smaller time ranges you are likely to end up on one shard: the one being written to. Writing to the shard invalidates ES's refresh cache. But as soon as you go to the previous day's shard it'll help. Some. When you go back seven days or thirty days it should help much more because those shards can end up on even slower hardware and slower hardware wants the request cache even more!

[ppisljar]

would not doing the conversion from date math to absolute time (from now-30d to "2021-05-19T13:34:00.000Z) on kibana side, but rather sending actual datemath string to es (now-30d) have any (positive) impact on performance ?

[nik9000]

I don't believe it'd make anything faster, no. It just depends on who's clock you want to use.

[ppisljar]

@flash1293 yeah i think changing those defaults makes sesne, feel free to create a PR for it