Private corporate batches, live online cohorts and 1-on-1 mentoring in agent-based infrastructure, APM, log and synthetic monitoring unified by a tagging model — 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 Datadog around its tagging model rather than its dashboards — because env, service and version are what let a single filter follow a problem from a host map to a trace to a log line. Sessions cover Agent deployment on hosts, Docker and Kubernetes with the Cluster Agent and Autodiscovery, log pipelines and index filters, APM instrumentation and distributed tracing, monitors with composite and anomaly conditions, SLOs and downtimes, and the cost levers most teams find only after the first large invoice: custom metric cardinality, indexed log volume and span sampling.
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 Datadog that means a trainer who has run it in production — agent-based infrastructure, APM, log and synthetic monitoring unified by a tagging model — 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 Datadog batchDatadog is a hosted observability platform that collects metrics, traces, logs, profiles and user-experience data from infrastructure and applications, and presents them in one query surface. Collection is agent-based: the Datadog Agent runs on hosts, as a DaemonSet on Kubernetes, or as a sidecar alongside containers, and uses integrations and Autodiscovery to find what is running and start collecting from it without a per-service configuration file for every workload.
The idea that makes the platform coherent is tagging. Every metric, trace, log line and host carries a set of tags, and the same tag — env, service, version, team, availability zone — is the join key across every product. That is why a latency spike on an APM service page can be filtered to one Kubernetes deployment, then pivoted to the logs and the infrastructure metrics for the same tag set. Getting the tagging model right is the difference between a useful Datadog account and an expensive one.
On top of collection sit the products teams actually buy: dashboards and notebooks, monitors with composite and anomaly detection alongside simple thresholds, Service Level Objectives, APM with distributed tracing and continuous profiler, Log Management with pipelines and indexes, Synthetics for API and browser tests, Real User Monitoring, Network Performance Monitoring and Security Monitoring — plus DogStatsD, custom checks and a full API for everything the UI can do.
Most organisations did not choose one monitoring tool; they accumulated six. Infrastructure metrics in one system, application traces in another, logs in a third, uptime checks in a fourth — and an incident that spans them takes an hour of tab-switching before anyone even forms a hypothesis. Datadog's commercial proposition is that correlation is the product, and it is why platform teams keep consolidating onto it.
The skill that organisations hire for is not clicking through the UI. It is the design work underneath: a tagging taxonomy applied consistently at deployment time, agent configuration that scales to thousands of ephemeral containers, log pipelines that parse and enrich before indexing, and monitor definitions that are managed as code rather than created by hand and forgotten.
Cost is the other reason depth matters. Datadog bills on hosts, indexed log events, custom metrics and ingested spans, and every one of those is something an engineer controls directly. Teams that understand index filters, exclusion rules, metric cardinality and retention run the same visibility for a fraction of the spend of teams that do not.
What Datadog actually is, product by product, and how data gets in. Getting started, the integration catalogue, the infrastructure list and host map, the event stream, and an honest view of where a hosted platform differs from a self-run stack — including where Datadog is the wrong purchase.
Topics: What Datadog is: the product surface and how the parts join · Getting started: account, organisation, API and application keys · Integrations: the catalogue and how an integration differs from an agent check · Infrastructure list, host map and container map · Events and the event stream · Datadog Watchdog and what automated detection can and cannot do · Where a hosted platform is the wrong choice
The component everything depends on. Agent architecture and configuration, running it on hosts, in Docker, and on Kubernetes as a DaemonSet with the Cluster Agent. Autodiscovery for workloads that move, log collection, proxy configuration for restricted networks, version management, security posture and systematic troubleshooting.
Topics: Agent architecture: collector, forwarder, DogStatsD, trace agent · Agent usage: datadog.yaml, conf.d, checks and the status command · Datadog Agent on Docker · Datadog Agent on Kubernetes as a DaemonSet · The Cluster Agent and cluster checks · Autodiscovery: annotations, labels and template variables · Agent log collection configuration · Agent behind a proxy · Agent versions, upgrade path and release channels · Agent security: secrets management and least privilege · Troubleshooting: flare, agent logs, status output
The short module that determines whether everything else works. How tags are assigned, at which layers, and the reserved tags that unify the platform. Unified service tagging with env, service and version, tag cardinality and its cost, and the governance problem of keeping a taxonomy consistent across teams.
Topics: Assigning tags: agent config, host tags, integration tags, cloud provider tags · Unified service tagging: env, service, version · Using tags to scope dashboards, monitors and queries · Tag cardinality and its billing consequences · Tag inheritance across containers, pods and hosts · Designing and enforcing a tagging taxonomy across teams
How Datadog stores and queries metrics, and the query builder underneath every graph. Metric types and submission, the metrics explorer and summary, distributions, the function library from rollups to arithmetic, going from a query to a graph, and graph JSON for anything the UI will not build.
Topics: Metrics introduction: types, submission, resolution and retention · Metrics explorer and metrics summary · Metric distributions and global percentiles · From the query to the graph: scope, group-by, aggregation, rollup · The function library: rate, derivative, smoothing, forecasting, arithmetic · Correlations · Graphing JSON and the graph editor · Notebooks: list, creation, and using them for investigations and postmortems
Turning queries into something a team reads under pressure. Timeboards versus screenboards and when each is right, the widget library, template variables that make one dashboard serve every environment, sharing and public dashboards, and building dashboards from JSON so they live in source control.
Topics: Timeboards vs screenboards: different jobs · The widget library: timeseries, toplist, query value, table, heat map, host map, service map, SLO · Querying inside widgets and widget-level scope · Template variables and saved views · Dashboard lists and organisation · Sharing dashboards internally and publicly · Graphing with JSON and dashboards as code · Dashboard design for on-call versus for management
The infrastructure product in depth. Infrastructure list and host map, container map and live containers, live processes for the question no metric answers, and serverless monitoring for Lambda and managed runtimes where there is no host to install an agent on.
Topics: Infrastructure list: filtering, muting and host lifecycle · Host map and container map as diagnostic tools · Live processes: finding the process that is actually consuming the box · Live containers and container-level resource attribution · Serverless monitoring: Lambda, Fargate and the extension model · Cloud integrations: AWS, Azure, Google Cloud · Integration coverage for Apache, Tomcat, nginx, MySQL, Redis, Docker, Kubernetes, Java, PHP and .NET · GitHub and source-code integration
The part that wakes people up, so the part that has to be right. Monitor types and their evaluation semantics, multi-alert monitors grouped by tag, composite and anomaly and forecast conditions, no-data and auto-resolve behaviour, notification templating, downtimes for planned work, and Service Level Objectives on top.
Topics: Monitor types: metric, service check, event, log, APM, synthetic, composite · Multi-alert monitors and grouping by tag · Thresholds, recovery thresholds and evaluation windows · Anomaly, outlier and forecast monitors — and when they mislead · No-data, auto-resolve and notify-no-data settings · Notification templating and conditional messages · Managing monitors at scale and monitor-as-code · Monitor status and check summary pages · Downtimes: scheduled, recurring and tag-scoped · Service Level Objectives: metric-based and monitor-based, error budgets
Application-level visibility. Enabling trace collection, instrumenting applications across runtimes, reading flame graphs and service maps, connecting logs to traces through trace IDs, runtime metrics, the continuous profiler, and manual instrumentation when auto-instrumentation misses the span that matters.
Topics: Enabling trace collection: trace agent, ports and container setups · Instrumenting applications: Java, Python, Node, Go, .NET, PHP, Ruby · Services, resources, spans and the APM glossary · Service map, service page and endpoint-level analysis · Distributed tracing across service boundaries and message queues · Trace search, retention filters and sampling · Connecting logs and traces with trace_id injection · Runtime metrics and the continuous profiler · Manual instrumentation and custom spans · OpenTracing and OpenTelemetry compatibility · APM troubleshooting: missing traces, broken parenting, orphan spans
Logs as a first-class, and expensive, data source. Collection paths, processing pipelines with grok parsers and remappers, live tail, the log explorer, generating metrics from logs, and the indexing model — indexes, exclusion filters and archives — which is where log cost is actually decided.
Topics: Log collection: agent, integrations, cloud services, HTTP intake · Processing pipelines: grok parser, date remapper, status remapper, attribute remapper · Standard attributes and the naming convention · Live tail for real-time debugging · Log explorer: search syntax, facets, patterns and aggregations · Indexes, retention and exclusion filters · Generating metrics from logs · Archives to S3, Azure Blob or GCS, and rehydration · Correlating logs with metrics and traces · Sensitive data scanning and log security
The products that watch from outside the application. Synthetic API and browser tests including private locations, Real User Monitoring for what browsers actually experience, Network Performance Monitoring for flow-level visibility, and Security Monitoring with detection rules and the signals explorer.
Topics: Synthetics: API tests, multistep tests and assertions · Browser tests: recording, step editing and maintenance · Private locations for internal endpoints · Synthetics and APM integration; identifying synthetics bots · Real User Monitoring: setup, explorer, and the data collected · Core Web Vitals and session replay concepts · Network Performance Monitoring: installation, network page and network map · Security Monitoring: detection rules and the signals explorer · Choosing between synthetic and real-user signals for an SLO
Datadog as code, and Datadog as a line item. DogStatsD and custom metrics, writing custom and OpenMetrics checks, the client libraries, CloudFormation and Terraform provisioning, then the API with authentication and rate limiting. Finally account management: users, SSO, multi-org, billing and the levers that actually move the invoice.
Topics: DogStatsD: counters, gauges, histograms, distributions and tagging from code · Custom metrics: what counts as one, and cardinality arithmetic · Service checks · Writing a custom Agent check · Writing an OpenMetrics check · Client libraries and community resources · Provisioning with CloudFormation and Terraform · The Datadog API: authentication, success and errors, rate limiting · Dashboard lists and comments through the API · User management, roles and organisation settings · SSO with SAML; multi-org accounts and switching between orgs · Billing: host, custom metric, indexed log and ingested span pricing · Cost control levers and how to audit spend
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy the Agent to VMs, Docker and Kubernetes with the Cluster Agent and Autodiscovery, then diagnose a check reporting no data using flare and status output.
Apply unified service tagging at deployment time and prove that a single env/service/version filter follows a problem from host map to trace to log line.
Build multi-alert, composite and anomaly monitors with correct no-data behaviour, add a tag-scoped downtime for planned work, and wire an SLO burn-rate alert.
Instrument a multi-service application, read the flame graph, fix a broken trace parent, and pivot from a slow span to the exact log lines through trace ID injection.
Write a grok pipeline for an unstructured format, set standard attributes, then halve indexed volume with exclusion filters and archives without losing incident signal.
Define monitors, dashboards, SLOs and index filters in Terraform, deploy them through CI, and produce a documented cost model for the resulting account.
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.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
| 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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.