[jaeger-v2] Deployment options

[yurishkuro]

This project was proposed but not selected as one of CNCF Google Summer of Code projects.

Background

We are working towards Jaeger v2 that is re-architected to be a custom distribution of the OpenTelemetry Collector. There are multiple tracks towards that milestone, one of them is to address the deployment process for the end users.

There are existing solutions for deploying jaeger-v1 and OTEL Collector:

• https://github.com/jaegertracing/jaeger-operator
• https://github.com/jaegertracing/helm-charts

The main issue is that they manage jaeger-v1 deployment, which:

• consists of multiple different binaries, and
• uses CLI flags / env vars for configuration.

In Jaeger-v2 we are dealing with a single binary that is configurable to fit different deployment modes using config files. So the existing operators/charts won't work for v2, we need to modify them.

There is also an OTEL Operator that manages OTEL Collector, which is conceptually much closer to jaeger-v2. However, Jaeger operator/chart also manage storage backends, so OTEL Operator is not sufficient out of the box.

• https://github.com/open-telemetry/opentelemetry-operator

Objectives

• Analyze existing solutions, such as Kubernetes Operators for Jaeger-v1 and OpenTelemetry Collector; and Helm charts
• Propose a strategy for how to support deployment options for Jaeger-v2, get alignment with maintainers;
• Implement and document the new deployment options.

Expected Outcome:

• Support deploying Jaeger v2 via Kubernetes Operator, Helm chart, and brew.
• Documentation on the website.

Recommended Skills

Go, Kubernetes, scripting, CI/CD, understanding of Kubernetes Operator concepts.

Mentors:

• Yuri Shkuro (@yurishkuro, github@ysh.us) - primary
• Jonah Kowall (@jkowall, jkowall@kowall.net)

Use CNCF Slack to reach maintainers (see https://www.jaegertracing.io/get-in-touch/)

References

• Jaeger v2 binary entry point

  jaeger/cmd/jaeger/main.go

  Line 17 in ef4791e

  func main() {

• Jaeger v2 parent issue, including design doc
• https://www.jaegertracing.io/mentorship-for-mentees/

[varshith257]

@yurishkuro I would like to discuss about it and need your valuable guidance to come up with a perfect solution for deployments for v2

[Swastik-Swarup-Dash]

@yurishkuro i would like to work on the issue need some resources to get a brief idea about the project and come with a solution reagarding the issue

[haanhvu]

@yurishkuro i would like to work on the issue need some resources to get a brief idea about the project and come with a solution reagarding the issue

There are already project brief and resources in the issue description. Please check those.

If you need further details, you could look deeper into the deployment options of otel collector on kubernetes. For example, this one explains it well (the author is maintainer of both jaeger and otel): https://github.com/jpkrohling/opentelemetry-collector-deployment-patterns/tree/main/pattern-3-kubernetes

[Swastik-Swarup-Dash]

Thanks for the valuable information @haanhvu it surely helped me a lot about the Isuue

[pavolloffay]

I got working V2 with memory store with the OTEL operator:

kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: jaeger
spec:
  image: jaegertracing/jaeger:latest
  ports:
  - name: jaeger
    port: 16686
  config: |
    extensions:
      jaeger_query:
        trace_storage: memstore

      jaeger_storage:
        memory:
          memstore:
            max_traces: 100000

    receivers:
      otlp:
        protocols:
          grpc:
          http:

    exporters:
      jaeger_storage_exporter:
        trace_storage: memstore

    service:
      extensions: [jaeger_storage, jaeger_query]
      pipelines:
        traces:
          receivers: [otlp]    
          exporters: [jaeger_storage_exporter]
EOF

The elasticsearch will be more complicated as it requires index cleaner and rollover which run as cronjobs in jaeger v1. However, this functionality could be implemented in the V2 as a separate extension or be part of the storage exporter e.g.

extensions:
  jaeger_storage:
    elasticsearch:
      index_cleaner:
        num_days: ....

   jaeger_elasticearch_index_cleeaner:
     num_days: ...

Alternatively we could let users configure https://opensearch.org/docs/latest/im-plugin/ism/index/ directly for rollover and index cleaning functionality and later maybe build it into the storage.

Cassandra will require schema creation job at startup which could be as well implemented in Jaeger as an extension.

[varshith257]

@yurishkuro Isn't our project got slot in GSOC? I haven't seen our project any in selected projects of CNCF. If yes, why can't we prioritise this deployments in LFX Mentorship for this Fall season?

[yurishkuro]

This project was not selected for GSoC 2024. We will likely include it as Fall LFX Mentorship project.