Private corporate batches, live online cohorts and 1-on-1 mentoring in open-source distributed tracing — collection, storage, sampling and trace analysis at production volume — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Jaeger as a pipeline rather than a UI: how spans get from an OpenTelemetry SDK through collectors — optionally via Kafka and an ingester — into Elasticsearch or Cassandra, and what each hop costs in latency, storage and lost data. Sessions cover deployment topologies on Kubernetes with the Jaeger Operator, index rollover and retention that keeps storage bounded, constant, probabilistic, rate-limiting and adaptive remote sampling with the reasoning behind each, and systematic diagnosis of incomplete traces — broken propagation, dropped spans, queue saturation and clock skew — followed by reading the resulting traces properly with critical-path analysis and service performance monitoring.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Jaeger that means a trainer who has run it in production — open-source distributed tracing — collection, storage, sampling and trace analysis at production volume — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Jaeger batchJaeger is an open-source distributed tracing platform. It receives spans from instrumented applications, stores them, and gives engineers a way to search and read the resulting traces — the record of one request as it moved through every service, database call and queue hop on its path. It was created at Uber, donated to the CNCF and graduated there, and it remains one of the most widely deployed tracing backends in Kubernetes estates.
Architecturally Jaeger is a small number of cooperating components. Collectors receive spans, validate them, and write to storage, optionally through a Kafka buffer with an ingester behind it for estates whose write rate outpaces the database. A query service reads from storage and serves the UI, where traces are searched by service, operation, tag and duration, then read as a timeline or a flame graph. From Jaeger v2 onwards the whole backend is built on the OpenTelemetry Collector, so receivers, processors and exporters are the same components used elsewhere in an OpenTelemetry pipeline.
Two choices dominate a real deployment. The first is storage: Elasticsearch or OpenSearch, Cassandra, or ScyllaDB for production, with Badger and in-memory for development — each with different index behaviour, retention mechanics and cost curve. The second is sampling. Tracing every request at production volume is usually unaffordable, so Jaeger supports constant, probabilistic and rate-limiting samplers, plus remote and adaptive sampling served centrally by the collectors so per-service rates can be tuned without redeploying anything. Instrumentation itself now comes from OpenTelemetry SDKs; the original Jaeger client libraries are retired.
Once a request crosses more than three services, aggregate latency graphs stop being useful. The p99 climbs, every service looks individually healthy, and nobody can say which hop is responsible. Distributed tracing is the only signal that answers that question directly, and Jaeger is the default open-source answer for teams that will not send trace data to a hosted vendor.
That constraint is common and getting more so. Data residency rules, contractual restrictions and the cost of per-span pricing all push organisations toward a backend they run themselves. Jaeger fits that requirement, is CNCF-graduated, and speaks OTLP natively, so it slots into an OpenTelemetry pipeline without custom glue.
The skill organisations hire for is operating it rather than opening it. A single-binary Jaeger is a five-minute exercise. Sizing an Elasticsearch cluster for span volume, configuring index rollover so retention does not silently fill disks, deciding between head and tail sampling, buffering through Kafka when a storage backend stalls, and diagnosing why a quarter of traces arrive incomplete — that is the work that makes tracing dependable enough for people to rely on during an incident.
What tracing answers that metrics and logs cannot, and how Jaeger implements it. The component model end to end, the retirement of the Jaeger agent and client libraries in favour of OpenTelemetry, the move to a Collector-based backend in v2, and an honest comparison against Zipkin, Tempo and hosted platforms.
Topics: The distributed latency problem and why aggregate graphs fail · Traces, spans, span context and the trace tree · Jaeger architecture: collector, query, UI, ingester and storage · The retired agent and client libraries, and what replaced them · Jaeger v1 versus v2 and the OpenTelemetry Collector foundation · OTLP as the primary ingestion path · Jaeger compared with Zipkin, Grafana Tempo and hosted tracing · Where a self-hosted tracing backend is the wrong choice
Jaeger stores what applications emit, so instrumentation quality decides everything downstream. Instrumenting with OpenTelemetry SDKs across languages, auto-instrumentation and its limits, span naming and attributes that make traces searchable, and the propagation formats — W3C, B3 and the legacy Jaeger header — that must agree across a fleet.
Topics: Instrumenting with OpenTelemetry SDKs and exporting over OTLP · Auto-instrumentation across JVM, Python, Node.js, Go and .NET · Span naming, operation cardinality and why bad names ruin search · Attributes, span kinds, events and status codes · Context propagation: W3C trace context, B3 and the Jaeger header · Migrating from retired Jaeger client libraries · Instrumenting message queues and asynchronous work · Verifying instrumentation before it reaches production
From all-in-one to something that survives a bad afternoon. Direct-to-collector deployment, the Kafka-buffered topology with ingesters, collector scaling and queue configuration, running on Kubernetes with the Jaeger Operator, and securing the pipeline with TLS, authentication and multi-tenancy.
Topics: All-in-one for development, and why it is never production · Direct-to-collector via OTLP: sizing, queues and backpressure · The Kafka-buffered topology: collector, Kafka, ingester · Collector scaling, replicas and resource sizing · The Jaeger Operator: custom resources, strategies and autoprovisioning · Sidecar, DaemonSet and gateway patterns on Kubernetes · TLS, authentication and securing collector endpoints · Multi-tenancy and separating trace data by team · Ingress, service mesh interaction and network policy
Where the traces actually live, and where the cost actually is. Elasticsearch and OpenSearch index layout, rollover and lifecycle management, Cassandra schema and compaction behaviour, Badger for small deployments, plus sizing arithmetic, the index cleaner, and what happens when retention is not enforced.
Topics: Storage options compared: Elasticsearch, OpenSearch, Cassandra, ScyllaDB, Badger, memory · Elasticsearch index layout, mappings and span-to-document shape · Index rollover, aliases and index lifecycle management · The Elasticsearch index cleaner and enforced retention · Cassandra schema, replication and compaction for span workloads · Sizing arithmetic: spans per second to bytes per day · Dependency storage and the spark dependencies job · Archive storage for long-retention traces · Backup, restore and reindexing
The decision that determines both bill and blind spots. Client-side samplers and their semantics, remote sampling served centrally by collectors, adaptive sampling that adjusts per service and operation, and tail-based sampling in an OpenTelemetry Collector in front of Jaeger when you need every error but not every success.
Topics: Constant, probabilistic and rate-limiting samplers · Per-service and per-operation sampling strategies · Remote sampling: serving strategy files from the collector · Adaptive sampling and how it rebalances across operations · Sampling propagation and consistency across a trace · Tail sampling in an OpenTelemetry Collector ahead of Jaeger · Guaranteeing capture of errors and slow requests · Measuring what sampling hides, and setting a fidelity target
The analysis skill the whole pipeline exists to support. Searching by service, operation, tag and duration, reading a timeline and a flame graph, comparing a slow trace with a fast one, using the dependency graph to see the architecture as it actually is, and Service Performance Monitoring for RED metrics derived from spans.
Topics: Trace search: service, operation, tag, duration and lookback · Reading the timeline view and identifying the critical path · Flame graph analysis and spotting serial calls that should be parallel · Span detail: attributes, events, logs and error status · Trace comparison — slow versus fast, before versus after a release · The dependency graph and the architecture nobody documented · Service Performance Monitoring: RED metrics from span data · Deep linking from dashboards and logs into a specific trace · Common findings: N+1 calls, retry storms, sequential fan-out, slow dependencies
Keeping it dependable enough that people trust it mid-incident. Monitoring the pipeline itself, finding and fixing dropped spans, tuning queues and batch sizes, upgrades and the v1 to v2 migration path, clock skew adjustment, access control, and controlling the total cost of a self-hosted tracing platform.
Topics: Monitoring Jaeger itself: collector, ingester and query metrics · Dropped spans: queue saturation, batch sizing and backpressure · Diagnosing incomplete traces and clock skew adjustment · Query performance tuning and slow search diagnosis · Upgrades, version skew and the v1 to v2 migration path · Access control, authentication proxies and exposing the UI safely · Capacity planning as span volume grows · Total cost of ownership versus a hosted tracing platform · Runbook: what to do when tracing itself is broken during an incident
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument two services with OpenTelemetry, export over OTLP to a Jaeger collector, and follow one request from entry point to database call in the UI.
Deploy collector, Kafka and ingester through the Jaeger Operator, then stall the storage backend and prove that spans buffer instead of disappearing.
Configure index rollover, lifecycle policies and the index cleaner, size the cluster against a measured span rate, and hold storage flat for a week.
Serve remote sampling strategies from the collector, tune one service's rate live, then add tail sampling that keeps every error trace.
Compare traces before and after a seeded change, identify the serial call responsible for the p99 shift, and quantify the fix from span data.
Run a full Jaeger deployment under load with monitoring, alerting on dropped spans, enforced retention, a sampling policy and a written failure runbook.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Good discussion, helped us to understand different tools in SRE.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.