Month: January 2026

kubernetes, Observability, OpenTelemetry

Part 2 – Deploying Jaeger v2 with the OpenTelemetry Collector

Posted on by Mark Johnson

In Part 1, we explored why Jaeger v2, OpenTelemetry, and GitOps form a natural, modern observability stack. Now we get hands‑on. This part walks through deploying Jaeger v2 using the OpenTelemetry Collector, using a minimal but production‑aligned configuration.

The goal is simple:
Get a working Jaeger v2 deployment running in Kubernetes, backed by the OpenTelemetry Collector, with the Jaeger UI exposed and ready to receive traces.

This is the foundation the rest of the series builds on.

All manifests and configuration used in this post are available in the companion GitHub repository

🧩 What Jaeger v2 Actually Is

Jaeger v2 is not a standalone set of components anymore. It is a distribution of the OpenTelemetry Collector that bundles:

  • OTLP receivers (gRPC/HTTP)
  • Jaeger query service
  • Jaeger UI
  • A Storage backend (memstore for demos, pluggable for production)

Instead of deploying multiple Jaeger components, you deploy one Collector with the right extensions enabled.

This dramatically simplifies operations and aligns Jaeger with the broader OpenTelemetry ecosystem.

📦 The Deployment Model

In this walkthrough, Jaeger v2 is deployed as:

  • An OpenTelemetryCollector resource (managed by the OpenTelemetry Operator)
  • A single Kubernetes Deployment created by the Operator
  • A Service exposing:
    • OTLP gRPC on port 4317
    • OTLP HTTP on port 4318
    • Jaeger UI on port 16686

This keeps the setup simple, reproducible, and GitOps‑friendly.

📁 The Collector (Jaeger v2)

Here is the core of the Collector configuration used in this series:

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: jaeger-inmemory-instance
spec:
  mode: deployment
  image: jaegertracing/jaeger:latest
  ports:
    - name: jaeger-ui
      port: 16686
      protocol: TCP
      targetPort: 0
    - name: otlp-grpc
      port: 4317
      protocol: TCP
      targetPort: 0
    - name: otlp-http
      port: 4318
      protocol: TCP
      targetPort: 0
  config:
    service:
      extensions: [jaeger_storage, jaeger_query]
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [jaeger_storage_exporter]
    extensions:
      jaeger_query:
        storage:
          traces: memstore
      jaeger_storage:
        backends:
          memstore:
            memory:
              max_traces: 100000
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    processors:
      batch:
        timeout: 1s
        send_batch_size: 8192
    exporters:
      jaeger_storage_exporter:
        trace_storage: memstore

Why this matters

  • OTLP gRPC (4317) is the default for .NET auto‑instrumentation
  • OTLP HTTP (4318) supports other languages and tools
  • Jaeger UI (16686) is built into the Collector
  • memstore keeps the demo simple and dependency‑free
  • The Operator handles lifecycle, rollout, and health checks

This is Jaeger v2 in its simplest, cleanest form.

🖥️ Exposing the Jaeger UI

Once deployed, the Jaeger UI is available on port 16686.

For local access:

kubectl port-forward svc/jaeger-inmemory-instance-collector 16686:16686 -n monitoring

Once deployed, the Jaeger UI is available on port 16686.

Then open:

http://localhost:16686

This UI is where you’ll verify traces in Part 3.

🚀 Deploying the Collector with Argo CD

Although you could apply the YAML manually:

kubectl apply -f platform/collector/collector.yaml

This series uses GitOps as the primary deployment method.

Argo CD applies the Collector automatically through the applicationset-platform.yaml ApplicationSet, which syncs the contents of:

platform/collector/

into the monitoring namespace.

Once ArgoCD syncs, you should see:

kubectl get pods -n monitoring
NAME                                                                READY   STATUS
jaeger-inmemory-instance-collector-xxxxx       1/1     Running

🔍Verifying the Deployment

Before moving on to instrumentation, confirm the Collector is healthy.

1. Check pod readiness

kubectl get pods -n monitoring

2. Check logs

kubectl logs deploy/jaeger-inmemory-instance-collector -n monitoring

You should see logs indicating:

  • OTLP receiver started
  • Jaeger query service started
  • Jaeger UI listening on 16686

3. Check service ports

kubectl get svc jaeger-inmemory-instance-collector -n monitoring

You should see:

  • 4317 (gRPC)
  • 4318 (HTTP)
  • 16686 (UI)

🧭 What’s Next

With Jaeger v2 deployed and ready to receive traces, the next step is to instrument an application. In Part 3, we’ll walk through:

  • How .NET auto‑instrumentation works
  • How the OpenTelemetry Operator injects the .NET agent automatically
  • How to enable instrumentation using an Instrumentation resource
  • How to annotate a Deployment to opt‑in
  • How to deploy the app and see traces appear in Jaeger

This is where the system comes alive.

1
Architecture, Cloud Native, Observability

Part 1 – Why Jaeger v2, OpenTelemetry, and GitOps Belong Together

Posted on by Mark Johnson

Modern distributed systems generate a staggering amount of telemetry. Logs, metrics, and traces flow from dozens or hundreds of independently deployed services. Teams want deep visibility without drowning in operational overhead. They want consistency without slowing down delivery. And they want observability that scales with the system, not against it.

This is where Jaeger v2, OpenTelemetry, and GitOps converge into a clean, modern, future‑proof model.

This series walks through a complete, working setup that combines:

  • Jaeger v2, built on the OpenTelemetry Collector
  • OpenTelemetry auto‑instrumentation, with a focus on .NET
  • ArgoCD, managing everything declaratively through GitOps
  • A multi‑environment architecture, with dev/staging/prod deployed through ApplicationSets

Before we dive into YAML, pipelines, and instrumentation, it’s worth understanding why these technologies fit together so naturally and why they represent the future of platform‑level observability.

All manifests, ApplicationSets, and configuration used in this series are available in the companion GitHub repository

🧭 The Shift to Jaeger v2: Collector‑First Observability

Jaeger v1 was built around a bespoke architecture: agents, collectors, query services, and storage backends. It worked well for its time, but it wasn’t aligned with the industry’s move toward OpenTelemetry as the standard for telemetry data.

Jaeger v2 changes that.

What’s new in Jaeger v2

  • Built on the OpenTelemetry Collector
  • Accepts OTLP as the ingestion protocol
  • Consolidates components into a simpler deployment
  • Integrates Jaeger’s query and UI directly into the Collector
  • Aligns with the OpenTelemetry ecosystem instead of maintaining parallel infrastructure

In practice, Jaeger v2 is no longer a standalone tracing pipeline.
It is a distribution of the OpenTelemetry Collector, with Jaeger’s query and UI components integrated into the same deployment.

This reduces operational complexity and brings Jaeger into the same ecosystem as metrics, logs, and traces, all flowing through the same Collector pipeline.

🌐 OpenTelemetry: The Universal Instrumentation Layer

OpenTelemetry has become the de facto standard for collecting telemetry across languages and platforms. Instead of maintaining language‑specific SDKs, exporters, and agents, teams can rely on a unified model:

  • One protocol (OTLP)
  • One collector pipeline
  • One set of instrumentation libraries
  • One ecosystem of processors, exporters, and extensions

For application teams, this means:

  • Less vendor lock‑in
  • Less custom instrumentation
  • More consistency across services

For platform teams, it means:

  • A single collector pipeline to operate
  • A single place to apply sampling, filtering, and routing
  • A consistent deployment model across environments

And with the OpenTelemetry Operator, you can enable auto‑instrumentation, especially for languages like .NET, without touching application code. The Operator injects the right environment variables, startup hooks, and exporters automatically.

🚀 Why GitOps (ArgoCD) Completes the Picture

Observability components are critical infrastructure. They need to be:

  • Versioned
  • Auditable
  • Reproducible
  • Consistent across environments

GitOps provides exactly that.

With ArgoCD:

  • The Collector configuration lives in Git
  • The Instrumentation settings live in Git
  • The Jaeger UI and supporting components live in Git
  • The applications live in Git
  • The environment‑specific overrides live in Git

ArgoCD continuously ensures that the cluster matches what’s declared in the repository. If someone changes a Collector config manually, ArgoCD corrects it. If a deployment drifts, ArgoCD heals it. If you want to roll out a new sampling policy, you commit a change and let ArgoCD sync it.

Git becomes the single source of truth for your entire observability stack.

🏗️ How These Pieces Fit Together

Here’s the high‑level architecture this series will build:

  • OpenTelemetry Collector (Jaeger v2)
    • Receives OTLP traffic
    • Processes and exports traces
    • Hosts the Jaeger v2 query and UI components
  • Applications
    • Auto‑instrumented using OpenTelemetry agents
    • Emit traces to the Collector via OTLP
  • ArgoCD
    • Watches the Git repository
    • Applies Collector, Instrumentation, and app manifests
    • Uses ApplicationSets to generate per‑environment deployments
    • Enforces ordering with sync waves
    • Ensures everything stays in sync

This architecture is intentionally simple. It’s designed to be:

  • Easy to deploy
  • Easy to understand
  • Easy to extend into production patterns
  • Easy to scale across environments and clusters

🎯 What You’ll Learn in This Series

Over the next four parts, we’ll walk through:

Part 2 – Deploying Jaeger v2 with the OpenTelemetry Collector

A working Collector configuration, including receivers, processors, exporters, and the Jaeger UI.

Part 3 – Auto‑instrumenting .NET with OpenTelemetry

How to enable tracing in a .NET application without modifying code, using the OpenTelemetry .NET auto‑instrumentation agent.

Part 4 – Managing Everything with ArgoCD (GitOps)

How to structure your repo, define ArgoCD Applications, and sync the entire observability stack declaratively.

Part 5 – Troubleshooting, Scaling, and Production Hardening

Sampling strategies, storage backends, multi‑cluster patterns, and common pitfalls.

🧩 Why This Matters

Observability is no longer optional. It’s foundational. But the tooling landscape has been fragmented for years. Jaeger v2, OpenTelemetry, and GitOps represent a convergence toward:

  • Standardisation
  • Operational simplicity
  • Developer autonomy
  • Platform consistency

This series is designed to give you a practical, reproducible path to adopting that model, starting with the simplest working setup and building toward production‑ready patterns.

You can find the full configuration for this part — including the Collector manifests and Argo CD setup — in the GitHub repository

1