Private corporate batches, live online cohorts and 1-on-1 mentoring in vendor-neutral instrumentation for traces, metrics and logs, with the Collector as the routing layer — 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 OpenTelemetry around the split that decides whether a rollout succeeds: API versus SDK versus Collector, and what belongs in each. Sessions cover auto and manual instrumentation across JVM, Python, Node and Go, context propagation over HTTP, gRPC and queues, semantic conventions as the thing that makes cross-team telemetry comparable, and Collector pipelines built from receivers, processors and exporters — including tail sampling, the k8sattributes processor, and gateway topologies that keep applications pointed at one endpoint no matter which backend is behind it. The migration path from OpenTracing and OpenCensus shims is covered as its own problem rather than a footnote.
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 OpenTelemetry that means a trainer who has run it in production — vendor-neutral instrumentation for traces, metrics and logs, with the Collector as the routing layer — 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 OpenTelemetry batchOpenTelemetry is a vendor-neutral standard and set of libraries for generating telemetry — traces, metrics and logs — from applications and infrastructure, and shipping it anywhere. It is a CNCF project formed from the merger of OpenTracing and OpenCensus, and it is now the second most active project in the foundation, supported by effectively every observability vendor. Its purpose is narrow and deliberate: it owns instrumentation and transport, and it does not store, query or visualise anything.
The project has four separable parts, and confusing them is the most common source of trouble. The specification defines the data model and behaviour. The API is what application code calls and is designed to be a no-op when nothing is configured. The SDK is the implementation that samples, batches and exports. OTLP is the wire protocol everything speaks. Because the API and SDK are separate, a library can be instrumented once and remain useful whether the application exports to a commercial platform, an open-source backend, or nowhere at all.
The OpenTelemetry Collector is the piece that changes operational practice most. It is a standalone binary that receives telemetry in many formats, processes it — batching, filtering, redacting, enriching with Kubernetes attributes, tail-sampling traces — and exports it to one or more destinations. Running a Collector as a node agent and a gateway tier means applications talk to one endpoint forever, while routing, sampling and vendor choice become configuration changes rather than redeployments. Alongside this sit semantic conventions: agreed attribute names for HTTP, databases, messaging, cloud and Kubernetes, which are what make telemetry from different teams and languages actually comparable.
For a decade, instrumenting an application meant adopting a vendor's agent, and changing vendor meant reinstrumenting everything. That cost was real enough to keep teams on platforms they had outgrown. OpenTelemetry removes it by standardising the layer where the lock-in lived, which is why adoption has moved from early-adopter to default in most new architectures.
The practical consequence is that instrumentation has become a platform concern rather than a per-team one. Someone has to decide the semantic conventions, run the Collector tier, set the sampling policy, and keep language SDK versions moving across dozens of services. That is an engineering role, and it is what organisations are recruiting for — not familiarity with a dashboard.
Depth matters here more than breadth. Adding auto-instrumentation to one service takes an afternoon. Designing a Collector topology that survives a backend outage, choosing between head and tail sampling with a cost model behind the decision, handling context propagation across message queues and async code, and migrating a legacy OpenTracing estate without losing trace continuity — that is the work, and it is where most rollouts stall.
The problem the project was created to solve, and the architecture that follows from it. The OpenTracing and OpenCensus merger, the separation of specification, API, SDK and protocol, the signal-by-signal and language-by-language stability matrix, and an honest account of what OpenTelemetry deliberately does not do.
Topics: The instrumentation lock-in problem and how the standard removes it · History: OpenTracing plus OpenCensus, and what the merger settled · Specification, API, SDK and OTLP — four separable things · Signals: traces, metrics, logs and profiles, and their maturity levels · Stability guarantees and the language and signal support matrix · What OpenTelemetry is not: no storage, no query language, no UI · Reading the specification and the registry when documentation runs out
What actually travels on the wire. Resources and attributes, spans with their kinds, events, links and status, the metric data point types including exponential histograms, the log data model, and the semantic conventions that turn a pile of attributes into something a query can rely on across teams.
Topics: Resources and resource detectors · Attributes: types, naming and cardinality consequences · Spans: kind, status, events, links and the trace tree · Metric instruments: counter, up-down counter, gauge, histogram, and asynchronous variants · Aggregation temporality — delta versus cumulative, and why the backend cares · Exponential histograms and high-fidelity latency · The logs data model and log-to-trace correlation · OTLP over gRPC and HTTP: encoding, compression and endpoints · Semantic conventions for HTTP, database, messaging, cloud and Kubernetes · Defining organisation-specific conventions that do not collide
Getting real telemetry out of real code. Zero-code auto-instrumentation and where its coverage ends, then manual instrumentation with tracers, meters and loggers — creating spans, recording exceptions, adding attributes that make a span searchable, and emitting custom metrics that are not just counters of everything.
Topics: Auto-instrumentation: the JVM agent, Python, Node.js, .NET and Go approaches · Configuring the SDK through environment variables and code · Tracer, meter and logger providers, and the global registration pattern · Creating spans manually: scope, lifecycle, exceptions and status · Instrumentation libraries for frameworks, clients and databases · Custom metrics: choosing the instrument and the attribute set · Instrumenting asynchronous, threaded and event-loop code correctly · Bridging existing logging frameworks into OpenTelemetry · Testing instrumentation and asserting on emitted spans in CI
The single most common cause of broken traces. How context travels, the W3C trace context and baggage headers, propagator configuration and interoperability with B3 and vendor formats, propagation through message queues and batch jobs, and a systematic method for diagnosing traces that arrive split or parentless.
Topics: Context, scope and the propagation API · W3C traceparent and tracestate · Baggage: propagating business context such as tenant or customer tier · Configuring and composing propagators; B3 and legacy format interoperability · Propagating across message queues, schedulers and batch workloads · Cross-language propagation and where it commonly breaks · Diagnosing orphan spans, split traces and missing parents · Propagation through proxies, service meshes and load balancers
The component that turns instrumentation into an operable pipeline. Receivers, processors, exporters, connectors and extensions; pipelines per signal; agent versus gateway deployment; and the processors that matter in production — batch, memory limiter, resource, attributes, filter, transform and tail sampling.
Topics: Collector architecture: receivers, processors, exporters, connectors, extensions · Core versus contrib distributions, and building a custom distribution with the builder · Pipelines per signal and multi-destination fan-out · Essential processors: batch, memory_limiter, resource, attributes, filter, transform · Receiving from Prometheus, Jaeger, Zipkin, Fluent Forward and the filelog receiver · Agent topology versus gateway topology, and when you need both · Scaling, load balancing and the loadbalancing exporter for trace-aware routing · Queueing, retry and persistent queues for backend outages · Self-monitoring the Collector: its own metrics, zpages and health checks · Securing the pipeline: TLS, authentication and redaction of sensitive attributes
Keeping everything is rarely affordable and usually unnecessary. Head sampling and its parent-based semantics, tail sampling in the Collector with policy composition, the trace-aware routing that tail sampling requires at scale, and the metric-side equivalents: attribute cardinality, views, and dropping what nobody queries.
Topics: Head sampling: always-on, trace ID ratio, parent-based and custom samplers · Sampling decisions and how they propagate downstream · Tail sampling in the Collector: latency, status, rate-limiting and composite policies · Why tail sampling requires all spans of a trace on one Collector instance · Metric views: renaming, dropping attributes and changing aggregation · Cardinality budgets and the cost of one careless attribute · Log sampling and filtering before export · Modelling telemetry cost per service and setting a ceiling
Running OpenTelemetry where most of it runs. The Operator, auto-instrumentation injection through annotations, Collector as DaemonSet and Deployment, enriching with Kubernetes attributes, and container log collection. Then the migration problem: moving off OpenTracing, OpenCensus or a vendor agent while keeping traces connected throughout.
Topics: The OpenTelemetry Operator: Collector and Instrumentation custom resources · Auto-instrumentation injection by annotation, and its language limitations · Collector as DaemonSet, Deployment and sidecar — choosing per signal · The k8sattributes processor and pod-level enrichment · Collecting container logs with the filelog receiver and CRI parsing · Scraping Prometheus endpoints through the Collector · Migration from OpenTracing and OpenCensus using the compatibility shims · Running mixed instrumentation during a phased migration without breaking traces · Replacing a vendor agent: parallel run, comparison and cutover · Troubleshooting: no data, partial data, dropped spans and version skew
We rebuild the agenda around the tools you actually run.
Request a custom agendaAuto-instrument a service, find the three things auto-instrumentation cannot see, and add manual spans and custom metrics that answer a real production question.
Carry trace context through HTTP, gRPC and a message broker so a single request appears as one connected trace, then break it deliberately and find the failing hop.
Build a node agent plus gateway topology with batching, memory limiting, attribute redaction and fan-out to two exporters, then survive a simulated backend outage.
Configure tail sampling with composite policies and trace-aware load balancing, then measure the fidelity you lost and the spend you saved.
Deploy the OpenTelemetry Operator, inject auto-instrumentation by annotation, enrich with k8sattributes, and collect container logs through the filelog receiver.
Move one application from an OpenTracing or vendor agent to OpenTelemetry using shims and a parallel run, keeping traces connected across mixed instrumentation throughout.
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.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| 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.