Private corporate batches, live online cohorts and 1-on-1 mentoring in APM, distributed tracing, real user monitoring and runtime telemetry — instrumenting, baselining and diagnosing latency in production — 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 performance monitoring as a diagnostic discipline rather than a dashboard tour: which of metrics, traces, profiles and real user data answers a given question, why percentiles and histograms are the working unit and averages are not, and how a trace reconstructs the path a slow request actually took. Sessions cover instrumentation end to end — agents and OpenTelemetry SDKs, span design and context propagation, head and tail sampling, cardinality control — then the operational half: baselines, symptom-based alerting, service level objectives and error budgets, and a live walk from a paging alert to a root cause. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the instrumentation and cost decisions.
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 Performance Monitoring that means a trainer who has run it in production — APM, distributed tracing, real user monitoring and runtime telemetry — instrumenting, baselining and diagnosing latency in production — 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 Performance Monitoring batchPerformance monitoring is the continuous measurement of how a system behaves under real load, and the practice of turning that measurement into a diagnosis fast enough to matter during an incident. It draws on three kinds of telemetry with different properties. Metrics are cheap, pre-aggregated numeric series that answer how much and how often, but they cannot explain an individual slow request. Traces record the causal path of a single request across every service, queue and database it touched, and are the only signal that answers where the time went. Logs and events carry the detail that neither of the others retains, at the highest cost per byte.
Around those sit the specialised layers. Application performance monitoring attaches an agent or an instrumentation library to the runtime and captures transactions, spans, database calls, outbound requests, errors and — increasingly — continuous CPU and allocation profiles. Real user monitoring measures what the browser or mobile client actually experienced, through navigation and resource timing and the Core Web Vitals: largest contentful paint, interaction to next paint and cumulative layout shift. Synthetic monitoring drives scripted transactions on a schedule, giving coverage when real traffic is low. Infrastructure and runtime monitoring covers hosts, containers, garbage collection, thread and connection pools and the saturation signals underneath everything else.
The analytical discipline is what makes performance monitoring useful rather than decorative. Averages hide the users who are suffering, so the working unit is the percentile distribution and the tail. Resources are read through utilisation, saturation and errors; services through rate, errors and duration. Instrumentation is increasingly standardised on OpenTelemetry, which decouples what a system emits from which vendor stores it — and makes cardinality, sampling and retention explicit engineering decisions with a direct cost attached.
Latency has a measurable commercial cost, and the organisations that treat performance as a feature measure it continuously rather than during a pre-release test cycle. Search ranking now incorporates field performance data from real users, checkout and search abandonment correlate directly with response time distributions, and mobile users on poor networks experience a different system from the one that was load-tested.
Architecture has made the diagnosis harder at the same time. In a monolith, a slow page was a slow page. In a system of forty services with queues, caches, service meshes and managed databases between them, the question is not whether something is slow but which hop is slow and for which subset of requests — and that question cannot be answered from metrics alone. Distributed tracing exists because it is the only telemetry that reconstructs the causal path, and Kubernetes has made the underlying infrastructure churn fast enough that host-level dashboards stopped being meaningful on their own.
The economics have become part of the skill. Observability platforms bill on data volume, cardinality and retention, and an unmanaged rollout produces invoices that force a retreat from monitoring at exactly the wrong moment. Engineers who can instrument a system properly, choose a sampling strategy, control cardinality, define service level objectives that reflect user experience, and still diagnose an incident in minutes are hired specifically for that combination.
The measurement theory that everything else depends on. Metrics, traces, logs and profiles and what each can answer; the golden signals, USE for resources and RED for services; and the statistical part that most dashboards get wrong — why averages hide the affected users and how histograms and quantiles behave when aggregated.
Topics: Metrics, traces, logs and profiles as distinct signals · The four golden signals · USE for resources, RED for services · Percentiles, tail latency and the p99 conversation · Histograms, buckets and quantile estimation error · Why you cannot average percentiles across services · Counters, gauges, histograms and summaries · Choosing a small measurement set per service
Getting telemetry out of an application. Automatic instrumentation agents and what they capture for free, the OpenTelemetry API, SDK and collector, and the manual instrumentation that fills the gaps an agent cannot see. Then attributes, semantic conventions and the naming discipline that decides whether the data is queryable later.
Topics: Automatic instrumentation agents and their coverage · OpenTelemetry API, SDK, collector and exporters · Traces, metrics and logs under one instrumentation model · Creating spans manually and choosing span boundaries · Attributes, semantic conventions and consistent naming · Resource attributes: service, version, environment, instance · The collector as a processing and routing layer · Vendor-neutral instrumentation and what it protects you from
The signal that answers the hardest question. Trace and span models, context propagation across HTTP, messaging and asynchronous boundaries, and reading a real trace to separate service time from queue time from downstream time. Then sampling — head-based, tail-based and the trade-off each makes.
Topics: Trace, span, parent-child and span links · Context propagation: W3C trace context and baggage · Propagation across queues and asynchronous work · Reading a waterfall: service time, queue time, downstream time · Database, cache and external call spans · Head-based versus tail-based sampling · Sampling strategies that keep the interesting traces · Exemplars: linking a metric spike to a specific trace
What the user actually experienced, which is frequently not what the server measured. Browser timing APIs, the Core Web Vitals and what each one is sensitive to, mobile client instrumentation, and the segmentation — by geography, device, connection and release — that turns a single aggregate number into an actionable finding.
Topics: Navigation timing, resource timing and paint timing · Largest contentful paint, interaction to next paint, cumulative layout shift · Field data versus lab data and why they disagree · Segmenting by device, geography, network and release · Mobile application performance: startup, frame rate, network · Correlating a slow page view with its backend trace · Synthetic monitoring: scripted checks, locations and schedules · Error tracking and source maps
The layers underneath the application, where saturation shows up before latency does. Host and container metrics that matter, CPU throttling and memory limits in orchestrated environments, runtime internals — garbage collection, thread pools, connection pools — and the database access patterns that dominate most application latency.
Topics: Host and container metrics that predict latency · CPU throttling, memory limits and eviction in Kubernetes · Garbage collection pauses and heap behaviour · Thread pools, connection pools and queueing · Little's law and why saturation precedes latency · Slow queries, missing indexes and N+1 access patterns · Cache hit ratios and cache stampede behaviour · Continuous profiling and flame graphs
Turning measurement into a page that is worth waking someone for. Establishing baselines with seasonality, static thresholds versus anomaly detection and where each fails, symptom-based alerting rather than cause-based, and the routing, grouping and suppression that stops a single failure producing forty pages.
Topics: Baselining with daily, weekly and seasonal patterns · Static thresholds, dynamic baselines and anomaly detection · Symptom-based alerting versus cause-based alerting · Alert severity, routing and escalation · Grouping, deduplication and dependency-aware suppression · Burn-rate alerting and multiwindow conditions · Measuring alert quality: actionability and false page rate · Runbooks attached to alerts
Connecting performance measurement to decisions people actually make. Choosing indicators that reflect the user journey, setting an objective that is achievable and meaningful, calculating an error budget, and using budget burn to arbitrate between shipping features and fixing reliability.
Topics: Service level indicators chosen from the user journey · Availability and latency objectives, and combining them · Error budgets and burn rate · Rolling windows versus calendar windows · Objectives for asynchronous and batch workloads · Dependency objectives and composing them · Using budget burn in prioritisation decisions · Reporting objectives to non-engineering stakeholders
Everything applied under time pressure. A structured walk from an alert to a root cause using the signals in the right order, then the proactive side — load and soak testing tied to the same instrumentation — and the telemetry cost management that decides whether the platform survives the next budget review.
Topics: A diagnostic sequence: symptom, scope, correlate, isolate, confirm · Recent-change correlation: deployments, config, feature flags · Differentiating a dependency problem from a capacity problem · Load, stress and soak testing against instrumented systems · Capacity planning from utilisation and growth data · Cardinality: what causes it and how to bound it · Sampling, aggregation and retention as cost controls · Reviewing telemetry spend against diagnostic value
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument a multi-service application with the OpenTelemetry SDK and a collector, add manual spans where the agent is blind, and route the same data to two backends.
Trace a request through four services with a deliberately injected delay, and account for every millisecond of the waterfall including queue and database time.
Capture Core Web Vitals from a real page, segment by device, network and geography, and link the worst segment to the backend trace responsible.
Drive load into a service until connection pool and CPU saturation appear, and show how each becomes visible in the telemetry before latency does.
Define indicators from real traffic, set an objective, compute the error budget, and configure multiwindow burn-rate alerts validated against historical incidents.
Work an unseen performance incident under time pressure — scope it, correlate against recent change, isolate the failing component and present the evidence trail.
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's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
| 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.