Private corporate batches, live online cohorts and 1-on-1 mentoring in business transaction monitoring, agent-based instrumentation and call-graph diagnostics for enterprise applications — 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 AppDynamics from its model outward: applications, tiers and nodes, and the business transaction detection rules that decide whether the whole deployment reflects reality or noise. Sessions cover agent installation and configuration across Java and .NET runtimes, custom entry points and transaction splitting, dynamic baselines and health rules that alert on deviation rather than static thresholds, and the snapshot-driven diagnostic path from a slow business transaction down to the offending method or SQL statement. The operational edges get equal time — transaction registration limits, agent overhead on latency-sensitive services, backend resolution for exit calls, and driving configuration through the REST API so it is reviewed rather than clicked.
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 AppDynamics that means a trainer who has run it in production — business transaction monitoring, agent-based instrumentation and call-graph diagnostics for enterprise applications — 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 AppDynamics batchAppDynamics is an application performance monitoring platform, now part of Cisco, built around one organising idea: the business transaction. Rather than starting from hosts and processes, it identifies the logical user operations an application performs — checkout, login, quote request — and measures each one end to end, across every tier and backend it touches. Everything else in the product hangs off that model, which is why getting business transaction detection right is the difference between a useful deployment and an expensive dashboard.
Collection is agent-based. Language agents attach to the runtime — Java through the JVM agent, plus .NET, Node.js, Python, PHP and others — and report to a Controller, available as SaaS or on-premises. A Machine Agent covers host and server visibility, a Database Agent covers query-level performance, and analytics agents feed transaction analytics. AppDynamics organises what it collects into a hierarchy of applications, tiers and nodes, and automatically discovers the exit calls each tier makes to render a flow map of the architecture as it actually runs.
The diagnostic workflow is what long-time users value. Dynamic baselines learn normal behaviour per business transaction and per hour of week, so health rules can alert on deviation rather than on fixed thresholds nobody maintains. When a transaction breaches, the agent captures a transaction snapshot containing the full call graph, and the engineer follows it down to the method, the SQL statement or the remote call responsible. Around that sit health rules, policies and actions for alerting, dashboards and the metric browser, Business iQ for transaction analytics, end-user monitoring for browsers and mobile applications, and a REST API for managing configuration as code.
Enterprises with large Java and .NET estates rarely rewrite them, and those applications still carry the revenue. Deep runtime instrumentation that can point at a specific method or SQL statement remains the fastest route from a complaint to a fix, and AppDynamics is entrenched in exactly those estates — banking, insurance, telecom, retail and public sector.
What those organisations struggle to hire is not someone who can read a dashboard. It is someone who can configure the model: define business transactions that match how the business actually thinks, keep transaction registration inside its limits instead of exhausting them on a bad URL pattern, tune agent overhead on latency-sensitive services, write health rules that reflect user impact, and connect AppDynamics to the incident tooling and release pipeline so a regression is caught before customers report it.
The platform also rewards knowing where it stops. AppDynamics is strong on deep runtime diagnostics and weaker as a general telemetry store, and most estates now run it alongside other tooling. Engineers who can place it correctly in an observability strategy — and export or correlate where it makes sense — get far more from the licence than teams who treat it as the only view.
What the product is and why it is shaped the way it is. The features overview, the Controller as SaaS or on-premises, and the hierarchical model of applications, tiers and nodes with the business transaction at its centre — including an honest view of where AppDynamics is the wrong tool for a job.
Topics: Features overview: what AppDynamics collects and what it does not · Application performance monitoring and the questions it answers · The Controller: SaaS versus on-premises, and what that changes · The hierarchical configuration model: applications, tiers and nodes · Business transactions as the central abstraction · Agents in the product family: language, machine, database, analytics · Licensing units and how they constrain a rollout · Where AppDynamics fits alongside other observability tooling
Getting agents attached and reporting reliably. Controller connectivity, the Java agent on application servers and containers, .NET and other language agents, machine and database agents, then the configuration files and system properties that name business applications, tiers and nodes consistently across an estate.
Topics: Installation and configuration: Controller connectivity, ports and proxies · The Java agent: JVM arguments, application server specifics and containers · The .NET agent and the Windows agent coordinator · Node.js, Python and PHP agents · Machine Agent for server visibility · Database Agent for query-level monitoring · Naming business applications, tiers and nodes at deployment time · Agent configuration files, system properties and environment variables · Basic configuration: time ranges, tiers, and the first health check · Agent troubleshooting: logs, registration failures and version compatibility
The configuration work that decides whether the data means anything. Mapping real application services onto the AppDynamics model, automatic entry point discovery and its blind spots, custom detection rules for frameworks and messaging, transaction splitting, and controlling transaction registration so the limits are not exhausted by a careless URL pattern.
Topics: Mapping application services onto the AppDynamics model · Instrumenting the application: automatic discovery and its limits · Entry point types: servlet, POJO, web service, message queue, background task · Custom business transaction detection rules · Transaction splitting by URI, parameter or payload · Business transaction limits, registration and the effect of exhausting them · Excluding transactions and grouping low-value traffic · Using AppDynamics for the first time against a real application · Custom exit points and backend detection for unrecognised calls
Day-to-day monitoring once the model is right. Reading flow maps as a live picture of the architecture, transaction scorecards for normal, slow, very slow, stalled and error, dynamic baselines that learn behaviour per hour of week, and choosing the key transactions that deserve attention over the long tail that does not.
Topics: Monitoring a business application: the dashboards that matter · Understanding flow maps and reading them as architecture · Business transaction monitoring and the transaction list · Transaction scorecards: normal, slow, very slow, stalled, error · Dynamic baselines and baseline types · Server health and node-level metrics in context · Key business transactions and the long tail · Tier and node comparison for uneven behaviour across instances
Turning collected data into a page someone should act on. The event model, application change events that correlate a deployment with a regression, health rules built on baselines rather than fixed thresholds, and policies and actions that route to email, HTTP endpoints and incident tooling.
Topics: Understanding events and the event model · Monitoring events and filtering the event list · Monitoring application change events and correlating with deployments · Health rules: conditions, scope, evaluation windows and warning versus critical · Baseline-based conditions versus static thresholds · Policies binding health rules to actions · Actions: email, HTTP request templates, custom actions and remediation scripts · Integrating with incident tooling and on-call rotation · Alerting hygiene: suppressing noise, scheduling maintenance, tuning after incidents
The core diagnostic skill. Drilling from a degraded business transaction into snapshots, reading the call graph down to the slow method or SQL statement, working with exceptions and error transactions, running diagnostic sessions on demand, and using events to establish what changed before the degradation started.
Topics: Troubleshooting workflow: from symptom to snapshot to call graph · Business transaction health drilldown · Transaction snapshots: automatic, periodic and diagnostic-session capture · Reading the call graph and finding the method that owns the time · Slow, very slow and stalled transactions, and what distinguishes them · Exceptions and error detection configuration · Troubleshooting using events and change correlation · Diagnosing the issue and identifying the bottleneck across tiers · Configuring snapshot collection without unacceptable overhead
Everything outside the request path that still causes incidents. Server visibility and infrastructure metrics, backend and exit call resolution so a remote dependency is named rather than anonymous, database visibility for query-level analysis, and background task monitoring for the batch work no user is waiting on until it fails.
Topics: Backend monitoring and infrastructure visibility · Exit calls, backend detection and resolving unnamed remote services · Server visibility: hosts, processes, disks and network · Database visibility: query performance, wait states and blocking · Background task monitoring and batch job instrumentation · Correlating application slowness with infrastructure saturation · Troubleshooting application performance across the full stack · Containers and orchestration: agents in Kubernetes and Docker
Communicating what the platform knows. The metric browser and custom dashboards for different audiences, analytics over business and infrastructure metrics, comparing releases to prove or disprove a regression, and end-user monitoring for the browser and mobile experience the server-side view cannot see.
Topics: The metric browser and building queries from raw metrics · Custom dashboards for on-call, for application teams and for management · Analysing business metrics and infrastructure metrics together · Transaction analytics and Business iQ concepts · Reports and scheduled delivery · Comparing releases: before and after a deployment · End-user monitoring: browser real user monitoring and synthetic checks · Mobile application monitoring · Custom metrics and extensions when the built-in set is not enough
Making AppDynamics repeatable across an estate. The REST API and configuration export and import, driving agent deployment and instrumentation from CI, integrating with change and incident systems, then a realistic rollout plan built from the use cases and case studies the group brings.
Topics: Automation and workflow overview · The AppDynamics REST API: configuration, metrics and events · Exporting and importing configuration between environments · Agent deployment through configuration management and CI pipelines · Integrating with change management, ticketing and incident tooling · Multi-environment strategy: development, staging and production separation · Governance: naming standards, ownership and licence consumption · Discussion of real use cases brought by the group · Case study: instrumenting and tuning a Java application end to end
We rebuild the agenda around the tools you actually run.
Request a custom agendaAttach Java and machine agents to a multi-tier application, drive application, tier and node naming from deployment configuration, and diagnose a registration failure.
Write custom detection rules and splitting for a framework AppDynamics misses, then repair an application that has exhausted its transaction registration limit.
Replace static-threshold health rules with baseline-based conditions, bind them to policies and actions, and measure the reduction in false alerts over a load run.
Follow a seeded slow transaction through the drilldown into a snapshot call graph and identify the exact query and method responsible, then verify the fix.
Resolve unnamed exit calls into real dependencies, instrument a scheduled batch job as a background task, and correlate a latency spike with host saturation.
Manage an application's AppDynamics configuration through the REST API, deploy agents from CI, and promote identical configuration across three environments.
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.