Private corporate batches, live online cohorts and 1-on-1 mentoring in the archived tracing API, the estates still running it, and the migration path to OpenTelemetry — 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 OpenTracing for the situation teams are actually in: an existing estate on an archived API that has to keep working while it moves to OpenTelemetry. Sessions cover the specification honestly — Tracer and Span, scope and thread propagation, tags, span logs, baggage and references — then the operational half: standing up Jaeger or Zipkin behind it, reading traces to isolate a misbehaving service, root-cause analysis across service dependencies, sampling and environment configuration, and instrumenting RPC frameworks on both client and server sides. The migration module is the centre of the course: the OpenTelemetry shim, mixed-mode traces during a phased cutover, propagator interoperability, attribute mapping, and how to decommission the old path without a gap in coverage.
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 OpenTracing that means a trainer who has run it in production — the archived tracing API, the estates still running it, and the migration path to OpenTelemetry — 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 OpenTracing batchOpenTracing is a vendor-neutral API specification for distributed tracing. It defined a small set of concepts — Tracer, Span, SpanContext, tags, logs, baggage and references — so that a library could be instrumented once and work with any compatible backend, rather than being tied to whichever tracing vendor an application happened to use. It was a CNCF project, and it solved a genuine problem: before it, instrumentation for Zipkin, a commercial agent and a home-grown tracer shared nothing at all.
It is important to be direct about its status. OpenTracing merged with OpenCensus to form OpenTelemetry, was archived by the CNCF, and receives no further development. New instrumentation should be written against OpenTelemetry. That does not make this material irrelevant — a large amount of production code, and many long-lived internal libraries, still call the OpenTracing API today, and those estates need people who can operate them and move them forward safely.
So this course is framed around that reality. It teaches the OpenTracing model properly, because you cannot migrate code whose semantics you do not understand, and because the concepts carried through almost unchanged: OpenTracing tags became OpenTelemetry attributes, span logs became span events, and baggage survived by name. It then treats migration as the main event — using the OpenTelemetry shim so shimmed and native services emit one connected trace, running mixed instrumentation through a phased cutover, reconciling propagation formats, and decommissioning the old path once nothing depends on it.
Archived does not mean absent. OpenTracing had years of adoption before the merger, and the code that adopted it is still running — in payment systems, in internal RPC frameworks, in shared libraries maintained by teams that have since moved on. Somebody has to keep those traces flowing while the estate moves to a supported standard.
That migration is the actual demand. It is not a rewrite you can do in one release: services deploy independently, and during the transition a single request will cross both shimmed and native instrumentation. Getting one connected trace out of that mixture — correct propagator configuration, consistent attribute names, no orphan spans at the boundary — is fiddly, high-risk work, and it is exactly what organisations bring an instructor in for.
There is a second reason to learn the model rather than skip it. OpenTelemetry inherited most of its tracing semantics from OpenTracing. Engineers who understand spans, references, scope and propagation from the original specification read the newer one faster and make better instrumentation decisions than engineers who only ever copied an auto-instrumentation snippet.
Why tracing exists, what OpenTracing was created to fix, and where it stands today. Observability in distributed systems, the fragmentation of tracing libraries before a standard existed, how OpenTracing standardised the API, and a direct account of the OpenCensus merger, the CNCF archival, and what that means for a team running it right now.
Topics: Networking and observability in distributed systems · The growing importance of distributed tracing instrumentation · The problem with earlier tracing solutions: per-vendor libraries and no shared model · Communication package maintenance and inconsistencies across platforms · How OpenTracing standardises distributed tracing · The OpenCensus merger, the formation of OpenTelemetry, and CNCF archival · What archival means in practice for an estate already running it · Deciding: operate, migrate, or both in parallel
The specification itself, because migration requires understanding the semantics you are moving. Tracer and Span, the span lifecycle, scope and active-span management across threads, tags versus span logs, baggage as propagated business context, and the reference types that shape the trace tree.
Topics: Tracer and Span: the two objects everything is built from · Span lifecycle: start, finish, and the errors caused by getting it wrong · Scope, ScopeManager and the active span across threads and callbacks · Tags, span logs and structured span data · Baggage: propagating context that is not a trace identifier · References: child-of and follows-from, and when each is correct · SpanContext, inject and extract, and the built-in propagation formats · Transaction identity, references, types and timestamps · How each concept maps onto its OpenTelemetry successor
An API with nowhere to send data is a no-op. Setting up an OpenTracing-compatible stack, the architecture behind it, and getting a first trace visible. Jaeger and Zipkin compared on storage, sampling and UI, then a working hello-world path from application code to a rendered trace.
Topics: Setting up an OpenTracing-compatible software stack · Overview of OpenTracing features and reference architecture · Jaeger: components, storage options and configuration · Zipkin: components, storage options and configuration · Choosing a backend on retention, query needs and operational cost · A hello-world instrumented service, end to end · Verifying the pipeline when no traces appear · Running the backend locally versus as shared infrastructure
Turning a request path into a trace that answers questions. Where spans belong relative to services, packages and business logic, what to record on each one, and how a trace assembles from independently emitted spans. The design decisions here determine whether the traces are useful or merely present.
Topics: Services, packages and application-specific business logic as span boundaries · Choosing operation names that stay searchable at scale · Transaction destiny, reference, type and timestamps · What belongs in a tag, what belongs in a span log, and what belongs nowhere · Span granularity: too coarse to be useful, too fine to be affordable · Assembling a trace from spans emitted by independent processes · Clock skew and the traces that appear to travel backwards · Instrumenting shared libraries without forcing a coupling on consumers
The reason any of this exists. Working from a symptom to a cause using trace data: identifying the misbehaving component, reading tags, spans, scope, threads and logs together, establishing how an error actually occurred rather than where it surfaced, and using dependency analysis to find the calls nobody documented.
Topics: Identifying a misbehaving system from trace evidence · Analysing tags, spans, scope, threads and logs together · Determining how an error occurred, not just where it appeared · Debugging a distributed system across service boundaries · Filtering performance monitoring to the requests that matter · Analysing service dependencies and unexpected call paths · Root cause analysis workflow from symptom to commit · Optimising code from trace evidence: serial calls, N+1 patterns, retry storms
Making tracing survivable in production. Configuration through environment variables, adjusting event frequency and sampling so cost stays bounded, monitoring live environments without becoming the reason they are slow, and instrumenting both sides of RPC and messaging boundaries.
Topics: Configuring tracers through environment variables · Adjusting the frequency of events and the sampling rate · Sampling strategies and their effect on what you can still debug · Monitoring live environments safely: overhead, buffering and backpressure · Integrating OpenTracing with RPC and other frameworks · Server-side and client-side tracing, and reconciling the two views · Tracing through queues, schedulers and asynchronous work · Best practices for production instrumentation · Troubleshooting: missing spans, broken parents, silent tracer failures
The environments where this API is most often still found. Tracing systems you cannot freely recompile or redeploy, evidencing request flow for audit and compliance purposes, working around components that will never be instrumented, and deciding honestly which parts of an estate are worth migrating at all.
Topics: Case study: evidencing request flow for compliance in a legacy estate · Tracing across components you cannot rebuild · Proxy, sidecar and gateway tracing when the application cannot change · Retention and access control for trace data containing regulated fields · Keeping sensitive values out of tags and baggage · Assessing which legacy services justify migration and which justify replacement · Documenting an estate whose architecture exists only in its traces
The centre of the course. Moving an OpenTracing estate onto a supported standard without a big-bang rewrite: the OpenTelemetry shim, running shimmed and native services in one connected trace, mapping tags to attributes and span logs to events, reconciling propagators, sequencing the rollout, and proving the old path is safe to remove.
Topics: Why migration is not optional in the long run · The OpenTelemetry shim: how it works and what it does not cover · Mapping the model: tags to attributes, span logs to events, baggage, references · Propagator interoperability across Jaeger, B3 and W3C trace context · Running shimmed and native instrumentation in one connected trace · Sequencing a phased cutover across independently deployed services · Adopting semantic conventions during the move rather than after it · Redirecting export from a legacy tracer to an OpenTelemetry Collector · Verifying trace continuity and detecting regressions during the transition · Decommissioning the OpenTracing path with evidence nothing depends on it · Summary: what to carry forward and what to leave behind
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument a service directly against the OpenTracing API — spans, scope across threads, tags, span logs and baggage — then find the bugs that finishing a span incorrectly causes.
Stand up both backends, send identical traces to each, and compare storage, sampling behaviour and what the two user interfaces let you actually find.
Take a seeded distributed failure with no useful logs, isolate the misbehaving service from tags and spans, and establish how the error actually occurred.
Instrument an RPC boundary on both sides, tune sampling and event frequency until overhead and storage are inside a stated ceiling, and measure what you lost.
Run a shimmed OpenTracing service alongside a native OpenTelemetry one, reconcile propagators, and prove a single request produces one connected trace.
Plan and execute a phased migration of a service group to OpenTelemetry with attribute mapping, trace-continuity verification and a documented decommission step.
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.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| 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.