Private corporate batches, live online cohorts and 1-on-1 mentoring in indexing, searching and modelling machine data with SPL, from forwarders to dashboards — 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 Splunk as a data pipeline rather than a search box — how sourcetype, timestamp recognition and index selection at ingest decide what SPL can do later, and why search-time schema is the platform's most useful property. Sessions cover SPL in depth from base searches through eval, stats and transforming commands to the Search Job Inspector, then the knowledge layer that makes a deployment usable by other people: field extractions, calculated fields, tags, event types, macros, lookups and accelerated data models feeding Pivot. Distributed architecture — forwarders, indexers, search heads — and the DevOps and security use cases are covered against a running deployment.
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 Splunk that means a trainer who has run it in production — indexing, searching and modelling machine data with SPL, from forwarders to dashboards — 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 Splunk batchSplunk is a platform for indexing and searching machine data — the logs, metrics, events and traces that systems emit as a by-product of running. Data is ingested from files, network inputs, scripted inputs, APIs and forwarders, broken into events, assigned a timestamp, host, source and sourcetype, and written to an index. Crucially, Splunk applies schema at search time rather than at write time, so fields can be extracted, renamed and recalculated long after the data landed, without reindexing.
The interface to all of it is SPL, the Splunk Processing Language. An SPL search is a pipeline: a base search selects events, and each subsequent command transforms the result set — eval to compute, stats and timechart to aggregate, lookup to enrich, rex to extract, and transforming commands to produce the tables that visualisations render from. Reports, alerts and dashboards are all saved searches, which means anything you can search you can schedule, alert on and publish.
Around the search layer sits a knowledge layer that decides whether a deployment is usable at scale: field extractions and calculated fields, event types and tags, lookups, macros, workflow actions and data models. Data models plus acceleration power the Pivot interface, which lets non-SPL users build reports safely. In production, Splunk is deployed as forwarders feeding indexers with search heads on top, clustered for availability, and it is used across IT operations, DevOps and security, where it is the substrate for Enterprise Security as a SIEM.
Machine data is the largest and least-used dataset most organisations hold. It arrives continuously, it answers questions nothing else can — what actually happened, in what order, to which user — and it is usually spread across hundreds of hosts in formats nobody standardised. Splunk exists because searching that data as data, rather than grepping files host by host, changes what an operations or security team is capable of.
The demand for Splunk skills is unusually durable because the platform sits in two budgets at once. IT operations uses it for troubleshooting, service monitoring and reporting; security uses the same indexes for detection, investigation and compliance evidence. That dual role is why Splunk survives cost-optimisation reviews that remove other tools, and why engineers who can write good SPL are valuable in both organisations.
Depth is what employers actually want. Anyone can type a search and get results. Writing SPL that is fast rather than merely correct, designing sourcetypes and field extractions so the data is usable by others, building data models that let analysts self-serve, and controlling licence volume through index and ingest decisions — that is the part that takes deliberate teaching.
The problem before the product. What counts as machine data, why it is hard to use in its raw form, and how Splunk's index-and-search-time-schema model differs from a database or a traditional log aggregator. The architecture at a glance, the roles a Splunk deployment contains, and where Splunk is the wrong answer.
Topics: Machine data: what it is and what it can answer · Splunk overview: indexing, search-time schema and the search pipeline · Splunk architecture: forwarder, indexer, search head · Events, timestamps, host, source and sourcetype · Indexes, buckets and the data lifecycle · Splunk Enterprise, Splunk Cloud and the free tier · Careers and role types around Splunk · Where Splunk is the wrong tool
A working deployment and clean data. Licensing and volume, installation, then the part that determines everything downstream: inputs. Files and directories, network inputs, scripted inputs and HTTP Event Collector, plus sourcetype assignment, timestamp recognition and line breaking — the three settings that cause most ingest problems.
Topics: Splunk licensing and volume model · Getting and installing Splunk on Linux and Windows · Adding data: files, directories, network inputs, scripted inputs · HTTP Event Collector · Sourcetypes: assignment, overriding and why it matters · Timestamp recognition and time zone handling · Line breaking and event boundaries · props.conf and transforms.conf at ingest time · Index selection and routing · Verifying a new data source before anyone builds on it
The core skill. The search pipeline model, base search discipline and why filtering early is the single biggest performance lever, time range selection, the search modes, and the command families that cover most day-to-day work. Then the Search Job Inspector, which is how you find out why a search is slow.
Topics: The search pipeline and the pipe operator · Base searches: index, sourcetype, source and free-text terms · Time ranges and the effect on search cost · Fast, smart and verbose modes · Filtering commands: search, where, dedup, head, tail · Field commands: fields, table, rename, sort · Reporting commands: stats, chart, timechart, top, rare · eval and the function library · fillnull, coalesce and null handling · The Search Job Inspector: reading cost and finding the bottleneck
The commands that separate a Splunk user from a Splunk engineer. Subsearches and their limits, transaction versus stats for grouping, rex and regular extraction inline, lookups for enrichment, streaming versus transforming commands and what that distinction costs, and macros for reusing search logic across a team.
Topics: Streaming, transforming and centralised commands — and why the difference matters · Subsearches: syntax, limits and when to avoid them · transaction vs stats for session grouping · rex and erex for inline field extraction · lookup, inputlookup and outputlookup for enrichment · eventstats and streamstats · append, join and their performance profile · Search macros: definition, arguments and reuse · Working with multivalue fields · Advanced eval: case, if, match, time functions
Making data usable by people who did not onboard it. What a field is and when it is extracted, the field extractor and manual regex extraction, calculated fields, tags and event types for classification, and the naming and permission conventions that keep a knowledge layer from becoming an unmanaged sprawl.
Topics: Introduction to knowledge objects and their categories · What fields are: index-time vs search-time extraction · The field extractor: interactive and regex modes · Manual extractions in props.conf and transforms.conf · Calculated fields · Tags: creating and searching by them · Event types: definition and use in searches · Lookups as knowledge objects: file, external and KV Store · Workflow actions · Naming conventions for knowledge objects · Managing knowledge objects: permissions, sharing, ownership and orphans
Letting people who do not write SPL get answers. What a data model is and how it differs from a saved search, datasets and field categories, building a model that satisfies a stated business requirement, acceleration and its storage cost, the configuration files behind it, and the Pivot interface on top.
Topics: Who a Splunk knowledge manager is and what the role owns · What a data model is and what problem it solves · The ingredients of a data model: datasets, objects, constraints · Data model datasets and dataset field categories · Field extractions inside a model · Exploring and extending an existing data model · Data model acceleration: how it works and what it costs · Data model configuration files · The Pivot tool: elements and workflow · Common Information Model and why security content depends on it
Turning searches into things people rely on. Saved searches as the common substrate, scheduled reports, alerts with throttling and trigger conditions, alert actions, then visualisations: the data structures each chart type requires, single value, maps and gauges, and dashboard construction with inputs, tokens and drilldown.
Topics: Saved searches: reports, alerts and dashboard panels · Scheduling reports and the scheduler's constraints · Alerts: real-time vs scheduled, trigger conditions and throttling · Alert actions: email, webhook, script, ticketing integration · Visualisation data structures: what each chart type needs · Chart types and choosing the honest one · Single value, maps and gauges · Transforming commands for visualisation · Building dashboards: panels, layout and inputs · Tokens, form inputs and drilldown · Simple XML and when to reach for it · Dashboard performance: base searches and post-processing
How Splunk is actually deployed. Universal and heavy forwarders and the difference that matters, forwarder installation and management at scale, the deployment server, indexer and search head clustering, index and storage design, and the troubleshooting path when data is not arriving.
Topics: Distributed architecture: forwarders, indexers, search heads · Universal forwarder vs heavy forwarder · Installing and configuring forwarders · The deployment server and deployment apps · Load balancing and indexer discovery · Indexer clustering and replication · Search head clustering and the captain · Index design: sizing, retention, hot/warm/cold/frozen · Role-based access control and index-level permissions · Troubleshooting forwarder installation and data-arrival problems · Monitoring Console and monitoring Splunk itself · Licence usage and controlling ingest volume
The two places Splunk earns its budget. DevOps use cases: build and deployment visibility, application error triage, release comparison and service-level reporting. Security use cases: correlation searches, notable events, the investigation workflow, compliance evidence, and how Enterprise Security builds on the data models from module 06.
Topics: Splunk in DevOps: pipeline, deployment and release visibility · Application error triage and log-driven troubleshooting · Service-level reporting from log data · Splunk in security: detection, investigation and evidence · Correlation searches and notable events · The investigation workflow and timeline · Enterprise Security and the Common Information Model dependency · Compliance reporting from indexed data · Enterprise use cases across IT, security and business analytics · Choosing between Splunk and a metrics platform for a given question
Packaging work so it travels. What a Splunk app actually is, navigating Splunkbase and evaluating a third-party app before installing it, building your own app with its directory structure and permissions, add-ons versus apps, and integrating Splunk with external systems through the REST API and SDKs.
Topics: What Splunkbase is and how to evaluate an app before installing it · App vs add-on: the distinction and why it matters · App directory structure: default, local, metadata, appserver · Creating an app and packaging knowledge objects inside it · Permissions, sharing and app-level scoping · Benefits of building in Splunkbase · The Splunk REST API and SDKs · Automating Splunk configuration and deployment · Ingesting from big data sources and archival platforms · Keeping apps upgradable: never editing default
We rebuild the agenda around the tools you actually run.
Request a custom agendaBring in a multi-line format with the wrong timestamps and no sourcetype, then fix event breaking, timestamp recognition and field extraction so it is usable by anyone.
Answer ten operational questions in SPL, then use the Search Job Inspector to cut the cost of the three slowest by restructuring the base search.
Create field extractions, calculated fields, event types, tags, lookups and macros for one data source under an agreed naming convention, then share them at app level.
Build a data model against real data to satisfy a stated business requirement, accelerate it, and hand a Pivot report to someone who cannot write SPL.
Deploy universal forwarders through a deployment server, then diagnose one that connects successfully but indexes nothing.
Package inputs, extractions, a data model, dashboards and alerts into an installable Splunk app that survives an upgrade because nothing edits default.
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.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| 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.