Extract script and script cache stats from nodes stats into separate API

[dakrone]

Description

From the nodes stats API, we should extract the script and/or script_cache (they appear to present the same information) stats into their own endpoint. This endpoint can then be non-node-centric, and present a global view of the number of script compilations, cache hits/misses, and so on.

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[elasticsearchmachine]

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

[HiDAl]

Hey @dakrone and @mattc58

checking the classes for scriptCacheStats, it seems to be deprecated since 2 years ago. Even, we don't have documentation for it https://www.elastic.co/guide/en/elasticsearch/reference/master/cluster-nodes-stats.html. And apparently, we never had that documentation. Should we create the target script_cache? or would suffice with script? thanks

[dakrone]

@HiDAl when I looked I believe they carry the same information, so we should go with the non-deprecated one.

[rjernst]

@stu-elastic can you give more context on the deprecated stats?

@dakrone Even if moving the stats out of node stats, they would still be per node. So such a new API would have to present stats for the entire cluster (collecting from each node and aggregating) right? I guess that is not different than node stats currently (at least by default without passing a node id)?

[stu-elastic]

@stu-elastic can you give more context on the deprecated stats?

They are when we, for a few versions, had per-context stats and per-context rate limiting

We deprecated per-context rate limiting because users found it confusing and instead ensured no system scripts (like ingest) were not rate limited.

script_cache is around for back compat reasons, script should be used.

[dakrone]

@dakrone Even if moving the stats out of node stats, they would still be per node. So such a new API would have to present stats for the entire cluster (collecting from each node and aggregating) right? I guess that is not different than node stats currently (at least by default without passing a node id)?

Yes, that's correct, these stats would be aggregated and for the entire cluster, not per-node.

[HiDAl]

@rjernst yes, we're doing this for all the stats that we're migrating