Port 14268: Jaeger Collector — The Witness to Every Journey

Port 14268 is the HTTP endpoint for the Jaeger Collector. When a request travels through your distributed system, touching ten services, spawning fifty operations, taking paths you never anticipated, port 14268 is where that story gets told.

This is the port where microservices confess.

What Port 14268 Does

The Jaeger Collector accepts trace data via HTTP at the /api/traces endpoint. Applications instrumented with tracing libraries send their spans here, encoded in Thrift format over HTTP. Each span contains a trace ID, a span ID, timestamps, operation names, and metadata about what happened during that slice of execution.¹

When you configure your application to export traces to http://jaeger:14268/api/traces, you're telling it: "When you finish an operation, tell the collector what you did." The collector receives these confessions, validates them, and stores them in a backend like Cassandra, Elasticsearch, or Kafka.²

Port 14268 is one of several ports in the Jaeger ecosystem. Port 16686 serves the UI where humans explore traces. Port 14250 accepts gRPC traffic for higher throughput. Port 14268 is the HTTP alternative, more accessible, easier to debug, the choice when you need to see what's being sent in plaintext.³

How Distributed Tracing Works

The problem: a user clicks "checkout" and the request fails. Somewhere. In one of your 2,000 microservices. Good luck.

The solution is deceptively simple. When a request enters your system, it gets assigned a trace ID, a 128-bit identifier that will follow it everywhere. Every service that touches this request creates a span, a record of what it did and how long it took. Each span carries the trace ID and its own span ID, plus the ID of its parent span.⁴

Context propagates through HTTP headers. The W3C standardized this as the traceparent header: version, trace ID, parent span ID, flags. When Service A calls Service B, it passes along the context. Service B creates a child span, inherits the trace ID, and passes it forward. The trace grows like a tree.⁵

All these spans eventually flow to the collector on port 14268. The collector assembles them into traces, the complete story of a request's journey. Now when that checkout fails, you don't search logs across six services. You pull up the trace and see exactly where time was lost, which service returned an error, what led to the failure.

The Origin Story

August 3, 2015. Yuri Shkuro commits the first code to an internal repository at Uber called Jaeger.⁶

Uber was in a period of explosive growth. In fall 2015, they had around 500 microservices. Two years later, they would have 2,000. Traditional monitoring couldn't keep up. Metrics told you something was slow. Logs told you something happened. But neither could show you the path a request took through the maze of services.⁷

Shkuro had spent 15 years on Wall Street building trading systems before joining Uber's New York observability team. He formed a two-person distributed tracing team with engineer Keekay. Their mission: transform an existing prototype into a production system, then make it available to every microservice at Uber.⁸

They named it Jaeger, German for hunter. It took weeks of brainstorming words around tracing, detectives, and hunting before they settled on it.⁹

The system they built drew inspiration from Google's Dapper paper (2010) and Twitter's open source Zipkin project (2012). Dapper had introduced the concepts of traces and spans. Zipkin had made them practical. Jaeger would make them scale.¹⁰

By 2016, Jaeger was recording thousands of traces per second across hundreds of microservices at Uber. In April 2017, Uber open sourced it. Six months later, the Cloud Native Computing Foundation accepted Jaeger as an incubating project. On October 31, 2019, Jaeger graduated, becoming the seventh project to achieve that status, joining Kubernetes, Prometheus, and Envoy.¹¹

The Technical Details

Jaeger's architecture has several components. The collector on port 14268 is stateless; you can run many collectors in parallel for high availability. Incoming spans are validated, indexed, transformed, and written to storage.¹²

Port 14268 accepts Thrift-encoded data. Apache Thrift is a serialization and RPC framework originally developed at Facebook, designed for efficient cross-language communication. The binary protocol encodes integers in big-endian byte order, optimizing for network transmission rather than human readability.¹³

The full port landscape:

The agent ports (6831, 6832 UDP) are now deprecated. Modern deployments send traces directly to the collector using OpenTelemetry Protocol (OTLP) on ports 4317/4318.¹⁴

Security Considerations

Port 14268 should not be exposed to the public Internet. Trace data often contains sensitive information: user IDs, request parameters, internal service names, timing data that reveals your architecture. An attacker with access to your traces has a map of your system.¹⁵

Known vulnerabilities have included XSS issues in the Jaeger UI (before v1.31.0) that could allow an attacker controlling a trace to execute arbitrary JavaScript. Dependency vulnerabilities in the Go stdlib have required patching.¹⁶

Best practices:

• Run the collector behind a firewall or service mesh
• Use TLS for trace transmission
• Implement authentication if exposing the collector endpoint
• Be careful about what metadata you attach to spans

Jaeger maintains active security practices with daily dependabot scans and a clear security reporting process through GitHub.¹⁷

Related Ports

Port 16686 (Jaeger Query/UI): Where you explore traces after they've been collected. The investigation interface.

Port 9411 (Zipkin): The compatibility layer. Jaeger can accept Zipkin-formatted traces, honoring its ancestor.

Port 4317/4318 (OTLP): The future. OpenTelemetry has become the standard, and Jaeger now accepts traces in OTLP format directly.

Port 14250 (gRPC): The high-performance alternative to 14268. Same collector, different protocol.

The Weight of What Flows Through

When Uber's internal services grew from 500 to 2,000, something broke. Not the services themselves, but human understanding. No engineer could hold the whole system in their head. No one could follow a request's path by intuition alone.

Port 14268 exists because distributed systems exceeded human cognitive limits. It's the port where machines report to other machines about what they did, generating data that helps humans regain understanding of systems they created but can no longer comprehend directly.

Every span that arrives is a small truth: "I was called at this time, I took this long, I called these other services, I succeeded or I failed." Millions of these truths per day, flowing through port 14268, assembling into stories.

The next time a checkout fails, the next time latency spikes, the next time a service drowns in requests it didn't expect, the answer lives in the traces. And those traces entered the system through port 14268, the witness to every journey.