Document environment variables for jaeger-es-index-cleaner

[a1300]

Requirement - what kind of business use case are you trying to solve?

I didn't found the documentation for the jaegertracing/jaeger-es-index-cleaner docker image. I think this is the file which documents the options https://github.com/jaegertracing/jaeger/blob/master/plugin/storage/es/esCleaner.py . Am I right?

Problem - what in Jaeger blocks you from solving the requirement?

Nothing.

Proposal - what do you suggest to solve the problem or improve the existing situation?

I would like to add this section to the documentation website

Any open questions to address

[yurishkuro]

It is my understanding that index-cleaner is the original, simpler strategy of managing indices, and the newer, recommended strategy is using built-in index rollover functionality. If you add the index-cleaner section to the docs, we should make this distinction clear.

Also, given that ES documentation is already pretty long, I would suggest moving it to a separate file under Deployment, and incrementing header levels to get the proper right-hand side content table.

[a1300]

@yurishkuro thank you for your comment
To be 100% sure: Is index-cleaner a standalone solution? Or does it need to be used with the rollover solution together? Are both stand alone solution that do the same job?

I don't fully understand how you want the right-hand side content table structured?
Now it looks like:

Storage Backends

• ...
• Elasticsearch
• ...

Do you mean?

Storage Backends

• ...
• Elasticsearch
  • Configuration
  • Rollover
  • Index Cleaner
  • Upgrade Elasticsearch
• ...

[yurishkuro]

Jaeger supports two modes for indices.:

• The old way is that a new index is created every day automatically by Jaeger backend, and the old indices just sit around, hence the need for index-cleaner. The quest path does manual lookup over N (controlled by the max-something parameter) past indices.
• The new way is using aliases and ES rollover: a write alias that rolls over to new index automatically based on time (as before, but could be more or less frequent than daily) or size, and a read alias that groups past indices and also rolls over as old indices go past their TTL threshold.

Regarding the layout, you see how the left navbar shows sub-items under Deployment?

This is done by using separate child pages. I am suggesting to add ES there, as a sub-page, while leaving only a brief summary in the main Deployment page. This way the page will get its own right-hand table of content, which is not visible for ES portion right now because header levels are below the threshold for the TOC - it only goes up to <h3>, and all ES content is <h4> and lower. By moving them into a separate child page we can increase those header levels and they will become visible in the TOC.