Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Datadog 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 two things a dashboard tour never reaches: the tagging model that makes every product join, and the ingest economics that decide what the account costs. Sessions cover Agent deployment across hosts, Docker and Kubernetes with the Cluster Agent, Autodiscovery and proxy configuration for restricted networks; unified service tagging with the cardinality arithmetic behind custom metrics done explicitly; log pipelines with grok parsing, standard attributes, index splitting, exclusion filters and archives; APM instrumentation with sampling and retention filters; and monitor design tested against the question that decides everything on a follow-the-sun rota — can the next person on shift act on this alert without calling you. It closes on governance: roles and restriction queries inside an organisation you may not own, SAML and multi-org access, billing levers audited one at a time, and monitors, dashboards, SLOs and index filters defined in Terraform so the configuration is reviewed rather than clicked. It rests on a twenty-year career in DevOps, SRE and security engineering, and on the 10,000-plus engineers who have already been through sessions of this kind.
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 — Datadog instrumentation, alert design and ingest cost control for Pune teams — 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 sessions run across Baner, Balewadi, Kharadi, Viman Nagar, Magarpatta, Hinjewadi and Kalyani Nagar; you provide the room, a screen and network access, we bring trainer, agenda, dashboards, assessments and certificates. Hours are 09:30 to 17:30 IST, though Pune support teams on a follow-the-sun rota routinely book 08:00 to 13:00 IST half-days so the evening overlap with a US or EMEA counterpart is untouched, and we can run a separate short session for the night-shift roster rather than making them attend twice. Labs need either a Datadog trial organisation or a non-production sub-organisation the group can safely misconfigure, plus one real service to instrument — bringing your own application is what makes the tracing and tagging exercises stick. Where you already have a production organisation we can review its monitor and tag hygiene 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 Datadog batchDatadog is a hosted observability platform that pulls metrics, traces, logs, profiles, synthetic checks and browser telemetry into one query surface. Collection is agent-based: the Datadog Agent runs on a host, as a DaemonSet with a Cluster Agent on Kubernetes, or alongside a container, and uses integrations and Autodiscovery to find workloads as they appear rather than needing a configuration file per service. What makes it one product instead of six is tagging — env, service, version, team and region are the join keys that let a single filter follow a problem from a host to a span to a log line.
That design has a commercial edge to it, and in Pune it usually shows up before anything else does. Datadog bills on hosts and containers, custom metrics, indexed log events and ingested spans, and every one of those is set by an engineer rather than by procurement. A tag carrying a request identifier becomes tens of thousands of custom metric series; a debug logger left enabled becomes indexed volume; an untuned sampling rate becomes ingest. Teams that understand cardinality, index and exclusion filters, retention tiers and sampling run the same visibility for a fraction of the invoice, which is why cost governance sits inside this syllabus rather than after it.
The second thing worth stating early is that many Pune teams do not administer the Datadog organisation they work in — it belongs to a customer in another time zone. That makes roles and restriction queries, tag conventions agreed across several vendors, downtime scheduled against somebody else's release calendar, and monitors an inheriting on-call can act on at handover matter more than dashboard aesthetics. Datadog is straightforward to switch on and very easy to run expensively and unreadably. The skill is the design underneath it.
Two distinct Pune populations are buying Datadog training, and they arrive with different opening sentences. The product and SaaS teams around Baner, Balewadi, Kalyani Nagar and Viman Nagar adopted it early, grew quickly, and now hold an ingest bill that has outpaced both their headcount and the usefulness of the data behind it. Their question is how to cut spend without losing the signal that resolves incidents, and the answer is technical rather than commercial: find the high-cardinality tags, split indexes by value, set exclusion filters on what is never queried, move the long tail to archives, and choose sampling deliberately.
The shared-services and captive floors in Kharadi, Magarpatta and Hinjewadi have a different problem entirely. They hold the India-hours leg of a follow-the-sun rota, which means everything they build is inherited by somebody else within a few hours. Monitors have to carry enough context to be actionable by a person who did not write them, downtimes have to line up with a release calendar in another time zone, error budgets are consumed by more than one shift, and dashboards have to be readable without a walkthrough call.
Both demands land on the same underlying discipline: a tagging taxonomy applied at deployment time, monitors and dashboards managed as code, and alert design judged by whether anyone acted on it. Local production-support and SRE listings name Datadog beside an ITSM tool and a paging platform, which is a fair description of the actual role — someone who can make the platform produce decisions rather than charts.
What Datadog collects, product by product, and how each collection path turns into a line on an invoice. The integration catalogue against agent checks, the infrastructure list and host map, events, Watchdog, and the four billing dimensions — hosts and containers, custom metrics, indexed log events, ingested spans — introduced on day one so that every later design decision can be costed rather than regretted.
Topics: The product surface, and how the pieces join through tags · Organisation setup, API keys and application keys · Integrations versus agent checks versus custom checks · Infrastructure list, host map and container map · Events and the event stream · Watchdog, and what automated detection can and cannot do for you · The four billing dimensions and what an engineer controls in each · Data residency, and choosing the site your customer's contract permits · Reading the usage page carefully before anybody changes anything · Where a hosted platform is the wrong purchase
The component everything depends on, and the one that behaves differently on every substrate. datadog.yaml and conf.d, the Agent on hosts, in Docker and on Kubernetes as a DaemonSet with the Cluster Agent, Autodiscovery for workloads that come and go, log and trace collection, proxy configuration for restricted networks, release channels and upgrades, secret handling, and a diagnosis method built on flare and status output rather than guesswork.
Topics: Agent architecture: collector, forwarder, DogStatsD and trace agent · datadog.yaml, conf.d and check configuration · The Agent on hosts, deployed through configuration management · The Agent on Docker, and on Kubernetes as a DaemonSet · Cluster Agent, cluster checks, and reducing API server load · Autodiscovery with annotations, labels and template variables · The Agent behind a proxy and in restricted networks · Versions, release channels and a safe upgrade path · Secret handling and least-privilege agent configuration · Troubleshooting: flare, agent status and check output
The short module that decides whether every other product works, and what the account costs. Where tags are assigned and how they are inherited across hosts, containers and pods, the reserved env, service and version tags that join infrastructure with traces and logs, cardinality arithmetic worked through explicitly, and the governance problem of keeping a taxonomy consistent when several teams and vendors write into the same organisation.
Topics: Tag assignment: agent config, host tags, cloud provider tags, integration tags · Tag inheritance across hosts, containers and pods · Unified service tagging: env, service and version · Using tags to scope queries, dashboards, monitors and access · Cardinality arithmetic: how many series a tag actually creates · Finding and removing a tag that is inflating custom metric counts · Agreeing a taxonomy across internal teams and external vendors · Enforcing tags at deployment time instead of reviewing them afterwards
How metrics get in, and how the query builder underneath every graph actually works. Metric types and submission paths, resolution and retention, the metrics explorer and summary, distributions and global percentiles, and the function library from rollup and rate through smoothing and forecasting — enough to answer an operational question directly without building a dashboard for it first.
Topics: Metric types: count, gauge, rate, histogram and distribution · Submission paths: integrations, DogStatsD, custom checks and the API · Resolution, rollup and retention · Metrics explorer and metrics summary · Distributions and global percentiles · Scope, group-by and aggregation: the shape of a query · The function library: rate, derivative, smoothing, forecast, arithmetic · What counts as a custom metric, and the arithmetic behind the count
Dashboards judged by whether somebody on another shift, possibly in another organisation, can act on them without a phone call. Timeboards against screenboards, choosing the widget that matches the decision, template variables so one dashboard serves every environment, saved views, sharing internally and with a customer, and defining dashboards as JSON so they live in source control instead of in one person's account.
Topics: Timeboards and screenboards: genuinely different jobs · The widget library, and choosing one that matches the decision being made · Template variables and saved views: one dashboard per service, not per person · Dashboard lists and organisation across teams · Sharing internally, with a customer, and publicly · Dashboards as JSON, in source control and deployed through review · Designing for an on-call engineer who did not build it · Notebooks for investigations, postmortems and shift handover notes
Alerting is the only Datadog output that interrupts a human being, and on a rota it interrupts one you have never met. Monitor types and their evaluation semantics, multi-alert monitors grouped by tag, composite conditions, anomaly and forecast monitors and the situations where they mislead, no-data and auto-resolve behaviour, and notification templating that carries enough context for somebody who has never seen the service to take the first action.
Topics: Monitor types: metric, service check, log, APM, synthetic and composite · Multi-alert monitors and grouping by tag · Thresholds, recovery thresholds and evaluation windows · Anomaly, outlier and forecast monitors, and their failure modes · No-data, auto-resolve and notify-no-data settings · Notification templating, conditional messages and runbook links · Routing to a paging platform and to an ITSM queue · Monitor ownership, naming and lifecycle at scale · Alert fatigue: measuring which monitors are routinely acknowledged and ignored · Seasonality, and the quiet weekend that looks exactly like an outage · Testing whether an alert is actionable by somebody who did not write it
Service level objectives as an agreement rather than a chart. Choosing an indicator that reflects the user, metric-based and monitor-based SLOs, error budgets and burn-rate alerting, and the scheduling problem a follow-the-sun rota creates — downtimes aligned to a release calendar in another time zone, muting that expires on its own, and an error budget consumed jointly by several shifts.
Topics: Choosing a service level indicator that reflects what the user experiences · Metric-based and monitor-based SLOs · Error budgets and burn-rate alerting · SLO status, history and reporting to a customer · Downtimes: scheduled, recurring and tag-scoped · Aligning downtime to a release calendar in another time zone · Muting safely: what expires, and what silently does not · Reporting attainment into a monthly service review a customer attends · What the incoming shift needs to see in the first five minutes of theirs
Logs as the most useful and most expensive data source in the account. Where logs enter from, how a pipeline reshapes them with grok parsing and remapping, standard attributes, live tail and the log explorer, generating metrics from logs where that is cheaper than indexing them, and then the indexing model — indexes, exclusion filters, retention tiers and archives with rehydration — which is where log cost is decided rather than discovered.
Topics: Collection: agent, integrations, cloud services and HTTP intake · Processing pipelines: grok, date, status, service and attribute remappers · Standard attributes and a naming convention that holds across teams · Live tail and the log explorer: search syntax, facets and patterns · Generating metrics from logs, and when that beats indexing them · Indexes, retention tiers and index-level sampling · Exclusion filters, and deciding what is genuinely never queried · Archives to object storage, and rehydration when you need the data back · Volume spikes caused by a retry storm, and capping them before they bill · Sensitive data scanning before anything is indexed
Application-level visibility, and the ingest it generates. Enabling trace collection, instrumenting across runtimes, reading a flame graph and the service map, distributed tracing across service and queue boundaries, connecting logs to traces through injected trace identifiers, runtime metrics and the profiler, and the sampling and retention filters that keep the interesting traces without keeping all of them.
Topics: Trace collection: trace agent, ports and container setups · Instrumenting Java, Python, Node, Go, .NET and PHP services · Services, resources and spans; reading a flame graph · Service map and endpoint-level latency analysis · Distributed tracing across HTTP boundaries and message queues · Head-based and tail-based sampling, and retention filters · Connecting logs and traces through trace identifier injection · Runtime metrics and the continuous profiler · Manual instrumentation and custom spans · OpenTelemetry compatibility and migration · Troubleshooting missing traces, broken parenting and orphan spans
The outside-in view, which matters more when the team is not in the same region as the users. Synthetic API and browser tests, private locations for endpoints not reachable from the public internet, Real User Monitoring for what browsers in the customer's geography actually experience, and network monitoring for the dependencies that no service map or trace ever shows.
Topics: Synthetic API tests, multistep tests and assertions · Browser tests: recording, step maintenance and controlling flakiness · Private locations for internal and customer-network endpoints · Choosing test locations that match where the users are, not where the team is · Synthetics and APM integration, and identifying synthetic traffic · Real User Monitoring: setup, explorer and the data collected · Core Web Vitals and session replay considerations · Network monitoring: the network page and map, and finding hidden dependencies · Choosing between synthetic and real-user signals for an availability SLO
Governance for accounts with more than one team, and for engineers who are guests in somebody else's organisation. Users, roles and custom role permissions, restriction queries that limit which data a role can see, SAML and single sign-on, multi-org accounts and switching between them, API and application key ownership and rotation, and a realistic view of what you can and cannot change without the owning administrator.
Topics: Users, roles and custom role permissions · Restriction queries and scoping data by tag · SAML single sign-on and identity provider mapping · Multi-org accounts and switching between organisations · API keys and application keys: ownership, scope and rotation · Audit trail: who changed which monitor, and when · Offboarding a departing engineer: keys, saved views and orphaned dashboards · Working as a vendor inside a customer-owned organisation · Requesting the access you actually need, and designing around what you will not get · Tag conventions agreed across several vendors in one account
The module the invoice pays for. A full spend audit across hosts and containers, custom metrics, indexed logs and ingested spans, with every proposed reduction costed against the visibility it removes. Then the mechanism that keeps the result stable: DogStatsD and custom checks written with a bounded tag set, and monitors, dashboards, SLOs, pipelines and index filters defined in Terraform and deployed through review.
Topics: Auditing spend across hosts, containers, custom metrics, logs and spans · Custom metric attribution: which team, which service, which tag · Reducing host and container counts without losing coverage · Index splitting, exclusion filters and retention tiers as cost levers · Trace sampling and retention filters as cost levers · Attributing usage back to a team with tags, and internal chargeback · DogStatsD, and writing a custom or OpenMetrics check with bounded cardinality · The API: authentication, rate limiting and safe bulk changes · Terraform-managed monitors, dashboards, SLOs and index filters · Forecasting next quarter's ingest from this quarter's growth rate · Guardrails that stop the bill growing back after the clean-up
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy the Agent to a VM, to Docker and to Kubernetes with the Cluster Agent and Autodiscovery, put one instance behind a proxy, then diagnose a check that reports no data.
Apply unified service tagging at deployment time and prove that a single env, service and version filter follows a problem from host map to span to log line.
Build monitors with correct grouping and no-data behaviour, write notifications that carry the runbook, schedule a downtime for a release window in another time zone, then hand them to a second group cold.
Write a grok pipeline and standard attributes for an unstructured format, split the indexes, apply exclusion filters, and demonstrate that the incident signal survived the cut.
Instrument two services, fix a broken trace parent, pivot from a slow span to its exact log lines, then set sampling and retention filters that keep every error trace.
Produce a full spend audit across all four billing dimensions with costed reductions, implement them in Terraform, and add the guardrails that stop the bill growing back.
Pune's Datadog population sits in two places that behave nothing alike. The first is the product and SaaS bench around Baner, Balewadi, Kalyani Nagar and Viman Nagar — adtech, martech, fintech and B2B platforms with their engineering in Pune — where Datadog was adopted early, the bill grew faster than the headcount, and the training request is almost always some version of "help us cut ingest without going blind". That makes custom metric cardinality, log indexes and exclusion filters, retention tiers, and the real difference between a metric, a log-based metric and a trace-derived metric the substance of the batch rather than an appendix.
The second group is the shared-services and captive support floors in Kharadi, Magarpatta and Hinjewadi, where a Pune team holds the India-hours leg of a follow-the-sun rota for a customer in the United States or Europe. Everything valuable there is handover-shaped: monitor design that survives a shift change, downtime scheduling aligned to a customer's release calendar rather than the local one, SLOs and error budgets that an overseas on-call inherits at 21:00 IST, and dashboards a partner team can read without a walkthrough. Because those deployments usually sit in the customer's own Datadog organisation, role-based access, restriction queries and tag governance across teams matter more here than they would in a single-tenant product estate. Pune listings for production-support and SRE roles name Datadog beside an ITSM tool and a paging platform more often than beside a self-hosted metrics stack.
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.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| 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.