Make Elasticsearch index prefix configurable

[pavolloffay]

If the index prefix was configurable people could deploy {collector, query} per k8s namespace and use one elasticsearch deployment.

Related to jaegertracing/jaeger-kubernetes#85

[CpuID]

+1 would love to see this added.

Our specific use case is using Elasticsearch with AZ specific ES clusters in EC2 (to avoid cross AZ replication $), while using Cross Cluster Search nodes to aggregate jaeger-query searches across N x AZ specific clusters. We do the same now with Logstash and it works great, but we use an index format like purpose-az-date to namespace correctly, as opposed to what jaeger supports now of purpose-date.

I assume the main item is making these configurable, as opposed to constants. I wonder if it's worth enforcing the two jaeger-span- + jaeger-service- prefixes, and just allow an extra namespace string between the prefix and the date? This would suit both the k8s use case in this GH issue as well as our use case of AZ specific clusters, I suspect this may be flexible enough while using a single namespace config rather than two (one for spans + one for services)?

@pavolloffay would you be open to a PR for this as a first step?

[golonzovsky]

just to mention spark-dependencies job configuration and jaeger-dependencies-* indexes as well

[CpuID]

just to mention spark-dependencies job configuration and jaeger-dependencies-* indexes as well

noting there's 3 (known) different index name patterns in use, makes me think the namespace string between the prefix and the date is the safer solution here.

I'm happy to dive into a PR for at least parts of this, but would love some feedback from @pavolloffay or @yurishkuro re the proposed direction before proceeding.

[yurishkuro]

related #840

[CpuID]

@yurishkuro good spot, thx. Both definitely related to eachother, do we try get it in as a single PR or split it into two...?

[yurishkuro]

my preference is to do it in one go, because as discussed in #840 it requires coordinated changes in 3 places, which if not made would leave some components unable to handle the modified index naming.

[CpuID]

@yurishkuro perfectly valid, thx for weighing in. I'll drop some comments on #840 - feel free to close this in favour of the PR.