Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs New Relic 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 New Relic from the agent outward rather than from the default dashboards, because on a long-lived application the data is only as good as the instrumentation decisions underneath it. Sessions cover Java agent attachment across application server variants and .NET profiler registration under IIS, proxy and TLS handling where outbound access is restricted, transaction naming for framework-heavy and home-grown request dispatchers, custom instrumentation for batch jobs and asynchronous work the agent never sees, transaction traces and slow query traces, NRQL to the point where a query becomes an alert condition unchanged, alert conditions with correct signal-loss behaviour, private synthetic locations for applications with no public route, and the ingest and user-tier decisions that determine what the platform costs before a rollout rather than after the first invoice.
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 New Relic that means a trainer who has run it in production — New Relic APM, NRQL and alert design for Pune's Java and .NET application estates — 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.
Onsite delivery covers Kharadi, Magarpatta, Baner, Hinjewadi, Yerwada, Viman Nagar and Talawade; you provide the room, a screen and network egress to New Relic, we bring trainer, agenda, dashboards, assessments and certificates. Hours are 09:30 to 17:30 IST, with 08:00 to 13:00 IST half-days available so an evening handover is untouched, and we can run a shorter separate sitting for a second shift roster instead of asking anyone to attend outside their hours. Labs need a trial or non-production account plus one real application to instrument — bringing your own Java or .NET service is what makes the instrumentation and transaction-naming exercises stick, and for teams whose application cannot leave the estate we work with a representative sample application instead. Where you already run a production account we can review alert policies, muting rules and user-tier allocation live, under NDA if required. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 New Relic batchNew Relic is a hosted telemetry platform: agents and integrations push metrics, events, logs and traces into one store, and everything that lands there is queryable in the same language. For the estates it is usually bought to watch in Pune that matters more than the feature list, because those estates are not a tidy set of microservices. They are Java applications running on Tomcat, JBoss, WebLogic or WebSphere and .NET applications hosted in IIS, several of them older than the team maintaining them, and they get instrumented by attaching an agent to a running process rather than by rewriting anything.
The application agent works by instrumenting the framework it recognises. It names a transaction from the request handler, times the segments inside it, and records database calls, external HTTP calls, message queue operations and errors as attributed children of that transaction. That is precisely where the value sits in a decade-old system — being able to say that the month-end run spends its time in one stored procedure rather than in something vaguely described as the platform. It is also where the work sits, because framework-heavy or home-grown dispatchers frequently report everything under a single transaction name, and custom instrumentation is what repairs that.
Above the agents sits NRQL, which turns every event type into something you can query with SQL-shaped syntax, facet, bucket into a time series, and then reuse unchanged as a chart or an alert condition — so a dashboard and an alert are the same statement expressed twice. And because New Relic bills on ingested data volume and on user tier rather than per host, decisions about sampling, log filtering, attribute cardinality and who genuinely needs full platform access are engineering decisions with an invoice attached to them.
Pune's demand for New Relic skill comes from the shape of the applications, not from a technology cycle. The banking, insurance and enterprise captives around Kharadi, Yerwada and Magarpatta run business systems that have been in production for ten years or more, and the questions asked of monitoring there are attribution questions: which query, which external call, which thread pool, and can you demonstrate to a business owner that a slow month-end batch is not the platform's fault. Answering that needs agent configuration, transaction naming and custom instrumentation — not another dashboard template.
The second source is the services and support side in Hinjewadi, Talawade and Hadapsar, where teams operate the platform inside a customer's account and are judged on alert quality during the India-hours leg of a follow-the-sun rota. The valuable skills there are workflow-shaped: conditions that do not fire on a gap in data, muting rules aligned to the customer's release calendar, and dashboards a colleague in another timezone can pick up at 21:00 IST without a handover call.
Third, and increasingly first in the buying conversation, is cost. Ingest and user tier are the two billing dimensions, and both are controlled by engineers rather than by procurement. Pune buyers now ask for a straight answer on drop rules, sampling, attribute pruning and who actually needs full platform access before they approve a wider rollout — which is why governance is taught here as a module rather than mentioned in a closing slide.
The concepts, sized for applications that already exist and cannot be rewritten. What metrics, events, logs and traces each answer; the data model and entity graph everything else hangs from; how accounts and sub-accounts are usually arranged in a portfolio; and how to plan instrumentation coverage when the code is owned by six different teams.
Topics: Metrics, events, logs and traces: which question each one actually answers · Monitoring and observability, stated without the marketing · The data model: event types, attributes and the entity graph · Accounts, sub-accounts and how a portfolio is normally organised · Coverage planning across an existing application portfolio · What auto-instrumentation gives you, and what it will never give you · Data residency, retention and the security review you will face
The module everything else depends on. Attaching the Java agent to Tomcat, JBoss, WebLogic and WebSphere, and the .NET agent to IIS on both the Framework and modern .NET; where configuration lives and which settings are worth changing; proxy and certificate handling in restricted networks; measuring agent overhead; and upgrading agents on applications with hard-won uptime.
Topics: Java agent installation: JVM arguments, application server variants, containers · newrelic.yml, environment variables and configuration precedence · The .NET agent: profiler registration, IIS, .NET Framework versus modern .NET · Proxy configuration, TLS interception and restricted outbound access · Agent logging, and diagnosing an agent that reports nothing at all · High-security mode, attribute filtering and keeping sensitive data out · Agent overhead: what it costs and how to measure it rather than assume it · Agent version management, staged rollout and rollback
Making the data say something specific. How transactions get their names and why framework-heavy applications collapse into one entry, transaction traces and where the time really goes, database and external-service attribution, slow query traces, thread profiling, and the errors inbox used as a triage surface rather than as a count on a tile.
Topics: Transaction naming rules, and the metric grouping problem · Renaming transactions for Struts, Spring MVC, ASP.NET and home-grown dispatchers · Transaction traces: reading one and finding the actual cost · Database instrumentation and slow query traces · External service calls and the dependency view · Thread profiler and CPU-bound investigation · JVM and CLR internals: heap, garbage collection, thread pools · Errors inbox: grouping, triage and separating new from chronic · Deployment markers and change tracking against a release · Service maps and dependency analysis
Everything the agent cannot see for itself. XML instrumentation and annotations for Java, attribute-based instrumentation for .NET, custom attributes that carry business context into every event, custom events and metrics through the APIs, and the batch, scheduled and asynchronous work that never appears until somebody instruments it deliberately.
Topics: When custom instrumentation is the right answer, and when it is not · Java: XML instrumentation files and the trace annotation · .NET: custom instrumentation XML and the agent API · Custom attributes, and the business context worth attaching to a transaction · Custom events and metrics through the Event and Metric APIs · Instrumenting batch jobs, scheduled tasks and non-web transactions · Message queue and asynchronous work attribution · Flex for pulling arbitrary data from a host
The layer that explains half of application incidents. Infrastructure agent installation on Linux and Windows, on-host integrations for the databases and web tiers these applications actually sit on, Windows services and event log, container coverage where workloads have moved, and cloud integrations for the managed services around the edges.
Topics: Infrastructure agent on Linux and Windows: install, configure, verify · Host metrics and events actually worth alerting on · On-host integrations: Microsoft SQL Server, Oracle, MySQL, PostgreSQL · IIS, Apache and Tomcat integrations · Windows services, event log and performance counters · Docker and Kubernetes integration where workloads have already moved · AWS and Azure integrations: polling versus metric streams · Tagging that ties hosts to applications, teams and cost centres
The language that decides whether the platform answers real questions or only shows pictures. Syntax and the event types behind each product, aggregation and faceting, time series and comparison windows, percentiles and histograms, subqueries and nested aggregation, and the cardinality behaviour that makes a dashboard load in a second or in thirty.
Topics: SELECT, FROM, WHERE, FACET, SINCE, UNTIL and LIMIT · Event types: Transaction, TransactionError, Log, Span, SystemSample and the rest · Aggregation: average, percentile, uniqueCount, rate, apdex, filter · TIMESERIES, COMPARE WITH and time-window behaviour · Histograms, funnels and cohort analysis · Subqueries and nested aggregation · String, maths and parsing functions inside a query · Query cost: cardinality, high-volume event types and limits · Running NRQL through NerdGraph for automation
Logs treated as attributed telemetry rather than as files on a server somebody has to SSH into. Forwarding from log4j, Logback, NLog and Serilog as well as the infrastructure agent and Fluent Bit; parsing rules that turn a line into attributes; linking a log line to the trace that produced it; obfuscation for fields that must not leave the estate; and the drop rules that decide what logging costs.
Topics: Forwarding paths: infrastructure agent, Fluent Bit, Fluentd, cloud services · Application forwarders for log4j, Logback, NLog and Serilog · Logs in context: linking a line to a trace and a transaction · Parsing rules, Grok patterns and moving to structured logging · Obfuscation and dropping sensitive fields before they are stored · Querying logs with NRQL and building log-based conditions · Log patterns and surfacing what is new rather than what is loudest · Data partitions, drop rules and retention tiers
Following a request through systems that were never designed to be traced together. How spans and trace context work, propagating context across the boundaries that matter — message queues, scheduled jobs, SOAP endpoints and gateway calls — sampling decisions, and bridging OpenTelemetry data from newer services into the same traces as agent-instrumented legacy ones.
Topics: What a span records, and what a trace can and cannot prove · W3C trace context and propagation across services · Tracing across message queues and asynchronous boundaries · Infinite tracing and tail-based sampling: when it earns its cost · Instrumenting a service the agent does not support · OpenTelemetry ingest and attribute mapping alongside agent data · Prometheus remote write for teams that already collect metrics · Finding the genuine latency contributor in a multi-hop request
The outside-in view, including for applications that are only reachable from inside the estate. Browser agent deployment and real user monitoring, single-page route tracking, Core Web Vitals, then synthetic monitors — ping, simple browser, scripted browser and API tests — and private locations for endpoints no public checker can ever reach.
Topics: Browser agent deployment: copy-paste, APM-injected and package-managed · Real user monitoring, session traces and AJAX analysis · Single-page application route-change tracking · JavaScript errors and source maps · Core Web Vitals and the front-end work they imply · Synthetic monitor types and when each is appropriate · Scripted browser monitors for multi-step internal workflows · Private locations for endpoints with no public route · Correlating a synthetic failure with APM and infrastructure data
Turning telemetry into something a person acts on, including a person in a different timezone who was not in the room. Alert policies and condition types, NRQL conditions, signal loss and gap-filling behaviour, workflows and destinations, muting rules tied to a release calendar, then dashboard design and the annotation that lets a colleague pick up an investigation cold.
Topics: Alert policies, conditions, and how incidents get grouped · Static, baseline, outlier and NRQL alert conditions · Signal loss, gap filling and evaluation offset — the settings behind most false pages · Workflows, destinations and enrichment · Muting rules aligned to a release or maintenance calendar · Applied Intelligence for anomaly detection and correlating related incidents · Dashboard design: layout, template variables and audience · Annotating a dashboard so it survives a shift handover · Integration with ITSM, PagerDuty and chat tooling · Managing alert policies at scale and assigning ownership
The commercial and administrative half, which is what most buyers ask about second and worry about first. Service levels and error budgets on real event data, user management and the full-platform versus core distinction, what actually drives ingested gigabytes, drop rules and sampling as levers, and forecasting a bill before an instrumentation rollout instead of explaining one afterwards.
Topics: Service levels: defining SLIs and SLOs against real event data · Error budgets and reporting them to a service owner · Users, roles, groups and authentication domains · Full platform, core and basic users — what each can actually do · Ingest accounting: which data types drive the bill and by how much · Data management: drop rules, sampling, attribute pruning and partitions · Retention tiers, and what is genuinely worth keeping long · Forecasting ingest before a rollout, then auditing it afterwards · NerdGraph and Terraform for configuration as code · Requesting account-level changes when you operate somebody else's account
We rebuild the agenda around the tools you actually run.
Request a custom agendaAttach the Java or .NET agent to an application server you did not build, get data flowing through a proxy with TLS interception in the way, then measure the overhead you introduced.
Take an application reporting a single catch-all transaction, repair the naming for its request dispatcher, and show the attribution difference before and after on the same workload.
Turn ten recurring production questions into NRQL, facet and bucket the results, then promote two of the queries into alert conditions without rewriting them.
Propagate trace context across three services and a message queue, bridge one OpenTelemetry-instrumented service into the same trace, and name the real latency contributor.
Build the alert set, muting rules and dashboard for one service, then hand it to another attendee who must run an investigation from it with no verbal briefing at all.
Audit ingest and user tiers for an account, model the cost of instrumenting three more applications, apply drop rules and sampling to reach a stated budget, and record what visibility each trade-off cost.
New Relic estates in Pune sit mostly on top of long-lived business applications rather than greenfield microservices, and that changes what a batch has to teach. The banking, insurance and enterprise captives around Kharadi, Yerwada and Magarpatta run Java and .NET systems that have been in production for a decade, and what they need from application monitoring is attribution at transaction level — which query, which external call, which thread pool — plus the ability to demonstrate to a business owner that a slow month-end batch is not the platform's fault. So agent configuration, custom instrumentation for code the agent does not detect automatically, transaction naming for framework-heavy applications, and NRQL become the substance rather than the appendix.
The second Pune group is the services and support side in Hinjewadi, Talawade and Hadapsar, where teams operate New Relic inside a customer's account and are measured on alert quality during the India-hours leg of a follow-the-sun rota. There the useful skills are workflow-shaped: alert conditions with sensible signal-loss handling, muting rules aligned to the customer's release calendar, dashboards a colleague in another timezone can pick up at handover without a call, and service levels that survive a 21:00 IST shift change. Because New Relic is licensed by user and by ingested data, Pune buyers also want a straight answer on drop rules, sampling and which people genuinely need full platform access — so cost governance is taught here rather than left to procurement.
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| 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.