Index stats enhancement: creation date and tier_preference

[3kt]

What

This adds two additional fields to the index stats API call response:

• creation_date
• tier_preference

Both information are transparently pushed from the IndexMetadata class, otherwise natively displayed in the index settings.

A stats call against an index would give such a response:

[...]
  "indices": {
    "foobar": {
      "uuid": "H3BofqE4QWqk21PZk314pg",
      "health": "yellow",
      "status": "open",
      "tier_preference": [
        "data_content"
      ],
      "creation_date": 1730912491278,
      "primaries": {
        "docs": {
          "count": 1,
          "deleted": 0,
          "total_size_in_bytes": 5208
        },
[...]

This is similar to #81954

Why

In their current state, the index stats are hard to consume for users, as most exposed stats are increasing counters. Giving contextual information such as when the index was created or what data tier it currently lives in allows users to answer questions like:

• What is my relative usage (query time, storage, index time, etc...) for one data tier compared to another?
• Within a given data tier, what index is the most used?
• What is my relative usage, as function of the index age?

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[elasticsearchmachine]

Hi @3kt, I've created a changelog YAML for you.

[DaveCTurner]

LGTM

[joegallo]

I went to revert this, but it involves a TransportVersion change, so it's not quite as trivial as hitting revert and merging the resulting PR, so I'm ignoring this for now. I imagine @elastic/es-data-management will discuss again on Monday and figure out a way forward.

[3kt]

What's the matter @joegallo ? Are there implications I didn't foresee?

[dakrone]

@3kt yes, we discussed this as a Data Management team, and decided we didn't want to pursue this (and not in this format also). I'm sorry, I hadn't had a chance to comment that yet on the PR before it was reviewed.