Any thoughts?

There is a bit of overlap with an existing pull request #2872, can you remove the indices_health code?

I feel that the url generation is too confusing, partially because of the current design. It needs to be made more straightforward and shouldn't cache the partial result individualStatsUrlPart onto the struct. Also can you explain why individualStatIncluded() is needed?

@danielnelson thanks for pointing out the existing PR situation regarding Elasticsearch. We desperately need the indices_health solution. We have a relatively big cluster and asking it for indices health takes upwards of 5 seconds and thus produces load we do not want. I am sure we can find a solution on how to fit things in nicely code-wise.

I did the individualStatIncluded approach to make the other method a little bit more readable but I am totally flexible on that. Regarding the caching: I must confess, I am still a little bit in the dark regarding processor life cycle. When would be a good hook to generate a concatenated string from the array? Because it is much preferred to have an array in the first place. Much nicer to read and understand in the config.

Other than that, there should not be too much overlap with the PR you mentioned, right?

And: What is the schedule regarding all these fixes for the Elasticsearch plugin?

Actually, I think I confused indices_health (/_cluster/health?level=indices) with what the other PR calls indices_stats (/_all/_stats). However it would still be best if we make changes in separate pull requests.

We can talk about this more on the new PR but, one issue I have is with the dependency of boolean config variables on each other, when using boolean options they should be independant:

if e.ClusterHealth {
	url = s + "/_cluster/health"
	if e.IndicesHealth {

To avoid this confusion about when indices_health can be used I suggest something like:

cluster_health = true # (ship has sailed on this one)
cluster_health_level = ["indices"]

It will be a little trickier because we need to preserve backwards compatibility, so if the list is nil it should default to "indices", but if it is defined it will be none.

When would be a good hook to generate a concatenated string from the array? Because it is much preferred to have an array in the first place. Much nicer to read and understand in the config.

I agree this is how we want it in the config. I would start by just not caching it at all, it is not that much work in the grand scheme of things, if it ends up being a hotspot we can fix it later.

Thanks for the feedback, @danielnelson. I split this into this PR and #3304.

Thanks!