Private corporate batches, live online cohorts and 1-on-1 mentoring in time-series storage, schema and cardinality design, Flux and InfluxQL, retention and downsampling — 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 InfluxDB around the two decisions that determine whether a deployment survives contact with production: schema design and data lifecycle. Sessions work through the data model in detail — measurements, tags, fields and timestamps — and treat series cardinality as a budget to be designed against rather than a metric to be discovered later. From there: ingestion with line protocol, the HTTP API and Telegraf plugins; querying with InfluxQL and Flux, including windowing, joins and pivots; retention policies, buckets, continuous queries and tasks for downsampling; Grafana dashboards on top; and the operational half — storage engine tuning, compaction behaviour, backup and restore, authentication and tokens, TLS, alerting through Kapacitor or native checks, and diagnosing an instance that has slowed because of a cardinality explosion.
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 InfluxDB that means a trainer who has run it in production — time-series storage, schema and cardinality design, Flux and InfluxQL, retention and downsampling — 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 InfluxDB batchInfluxDB is a database purpose-built for time series data — measurements written with a timestamp, queried over ranges, aggregated into windows and eventually thrown away. That workload is different enough from general-purpose OLTP that a specialised engine wins decisively: writes are append-heavy and arrive in timestamp order, queries almost always carry a time range, and old data is far less valuable than recent data, which makes compression, downsampling and retention first-class features rather than afterthoughts.
The InfluxDB data model is deliberately small. A point consists of a measurement name, a set of tags, a set of fields and a timestamp. Tags are indexed strings used for filtering and grouping; fields hold the actual values and are not indexed. The combination of measurement and tag set defines a series, and series cardinality — the total number of distinct combinations — is the single number that governs memory use, query speed and whether an instance stays healthy. Almost every InfluxDB production problem is a schema decision that put something high-cardinality, such as a request identifier, into a tag.
Around the engine sits a working ecosystem. Telegraf is the plugin-driven collection agent that covers hundreds of input sources and writes line protocol. Queries are expressed in InfluxQL, in Flux for pipeline-style transformation and joins, or in SQL in the newer engine. Retention policies and buckets expire old data automatically, while continuous queries and tasks downsample high-resolution data into coarser long-term series. Grafana is the usual visualisation front end, and Kapacitor or native checks and notification rules handle alerting. Versions differ substantially — 1.x, 2.x and 3.x have different storage engines, query languages and clustering stories — so knowing which one you are running matters more with InfluxDB than with most databases.
Every system that runs now emits a stream of numbers over time: infrastructure metrics, application telemetry, IoT sensor readings, financial ticks, industrial process data. Storing that in a relational database works until it does not, usually somewhere between a few million and a few hundred million points, and the migration to a purpose-built time-series store is one of the more common data infrastructure projects going on right now.
InfluxDB sits in that market as the option teams reach for when they want a dedicated time-series engine with collection, retention and downsampling built in, rather than assembling those from parts. It is heavily used in monitoring stacks, in industrial and IoT telemetry where sensor volume is enormous, and increasingly as the storage layer behind custom analytics products.
The skill that gets hired for is schema and lifecycle design, not query syntax. Anyone can write a SELECT with a time range. Designing tag sets that keep cardinality bounded, choosing retention and downsampling so a year of history costs a fraction of a week of raw data, sizing hardware against a measured write rate, and diagnosing an instance that has become slow because someone tagged by user identifier — that is what separates an InfluxDB deployment that lasts from one that gets rebuilt in eighteen months.
The workload before the product. What makes time-series data different from relational data, why that difference justifies a specialised engine, the use cases InfluxDB is genuinely good at, and the version landscape — because 1.x, 2.x and 3.x differ in storage engine, query language and clustering enough to change the whole answer.
Topics: Overview of time series databases and why the workload is distinct · Introduction to InfluxDB and its core features · Use cases: infrastructure monitoring, IoT and sensor data, application telemetry, financial series · The version landscape: 1.x, 2.x and 3.x compared · Storage engines and how data is physically laid out · Open source, Enterprise and Cloud editions and what each includes · Where InfluxDB is the wrong choice, and what to use instead
Getting a working instance and knowing the settings that matter. Installation on Linux, Windows and Docker, the configuration file section by section, initial setup of organisations, buckets and tokens, and the interfaces you will use daily — the user interface, the command line client and the HTTP API.
Topics: Installing InfluxDB on Linux, Windows and Docker · Configuration file structure and the options that actually matter · Data directories, WAL, shard layout and disk planning · Initial setup: organisations, buckets, users and tokens · Exploring the user interface: data explorer, buckets, tasks and settings · The command line client and scripting against it · The HTTP API surface · Running InfluxDB in containers and under an init system · Upgrading, and what changes between major versions
The module that determines whether everything later works. Measurements, tags, fields and timestamps; what belongs in a tag versus a field and why the answer is not stylistic; series cardinality as a hard design budget; and schema patterns for the workloads that most often get this wrong.
Topics: The InfluxDB data model: measurements, tags, fields, timestamps · Tags versus fields — indexing, filtering and the cost of getting it wrong · Series, series keys and how cardinality is counted · Cardinality budgets: estimating before you write, not after · Schema patterns for infrastructure metrics, IoT sensors and application telemetry · Naming conventions that stay queryable as the estate grows · Wide versus narrow schemas and their query consequences · Designing for efficient storage and retrieval · Diagnosing and remediating an existing high-cardinality schema
Getting data in, at rate, without losing it. Line protocol in detail including timestamp precision, writing through the HTTP API and the command line, then Telegraf — the collection agent that covers most real ingestion — with its input, processor, aggregator and output plugin model, batching and buffering behaviour.
Topics: Line protocol syntax, escaping and timestamp precision · Writing through the HTTP API: batching, compression and error handling · Writing from the command line and from client libraries · Telegraf architecture: inputs, processors, aggregators, outputs · Common Telegraf input plugins and configuring them · Telegraf buffering, batching and behaviour when the database is unavailable · Scrapers and pulling from Prometheus-format endpoints · Write performance: batch size, precision, concurrency and their effects · Handling duplicate points, out-of-order writes and late arrivals · Backfilling historical data safely
Both query languages, and when each is the right tool. InfluxQL for familiar SQL-like selection and aggregation; Flux for pipeline-style transformation, joins across measurements, pivots and custom logic. Windowing and aggregation semantics are treated carefully, because most wrong answers come from misunderstanding them.
Topics: InfluxQL: SELECT, WHERE, GROUP BY time, and its limits · Flux fundamentals: pipeline syntax, from, range, filter, yield · Aggregation and windowing: aggregateWindow, and the boundary semantics that trip people up · Transformations: map, pivot, group, sort, limit · Joins and unions across measurements and buckets · Working with SQL in the newer engine · Selecting the right function: mean, median, percentile, derivative, rate, difference · Handling gaps, nulls and irregular sampling · Query performance: what makes a query slow and how to see why · Parameterising and reusing queries
The lifecycle machinery that keeps storage bounded and long-range queries fast. Retention policies and bucket retention, continuous queries in 1.x and tasks in 2.x, designing a downsampling ladder from raw to hourly to daily, and the arithmetic showing what each tier costs to keep.
Topics: Retention policies, buckets and automatic expiry · Shard groups, shard duration and why it affects deletion · Continuous queries: syntax, scheduling and backfill behaviour · Tasks in InfluxDB 2.x: writing, scheduling and monitoring them · Designing a downsampling ladder: raw, minute, hour, day · Choosing aggregations that remain meaningful after downsampling · Storage arithmetic per retention tier · Deleting and correcting data, and why deletion is expensive · Monitoring that retention and downsampling are actually running
Turning stored series into something people read. Connecting Grafana to InfluxDB, building dashboards and panels for time-series data, template variables so one dashboard serves every host or sensor, plus the native dashboarding and data explorer, and the visualisation choices that mislead when data is downsampled.
Topics: Connecting Grafana to InfluxDB and choosing the query language per data source · Building dashboards and panels for time-series data · Template variables and repeating panels instead of hard-coded filters · Native InfluxDB dashboards and the data explorer · Visualisation types and when each misrepresents the data · Downsampling, interval alignment and misleading graphs · Annotations and correlating events with series · Sharing, permissions and dashboard version control
What happens when one node is not enough — and an honest account of what is and is not available in the open-source edition. Clustering in Enterprise, replication factors, sharding and data distribution, horizontal scaling patterns, and the alternatives teams use when clustering is not on the table.
Topics: Scaling limits of a single node and how to recognise them · InfluxDB Enterprise clustering: meta nodes, data nodes and topology · Replication factors, sharding and data distribution across a cluster · Query routing and consistency in a clustered deployment · Scaling for write throughput versus for query concurrency · Edge data replication and hub-and-spoke topologies · Federating multiple independent instances when clustering is unavailable · Capacity planning as series count and write rate grow · Failure modes and what a node loss actually costs you
Diagnosing an instance that has gone wrong, and preventing the next one. Storage engine and configuration tuning, memory behaviour and its relationship to cardinality, compaction and shard behaviour, slow query analysis, and the internal statistics that tell you what the database is actually doing.
Topics: Best practices for InfluxDB performance · Tuning storage engine parameters and cache settings · Memory use and its direct relationship to series cardinality · Compaction: what it does, when it hurts, and how to observe it · Shard duration and its effect on query and deletion cost · Diagnosing slow queries and unbounded time ranges · Internal monitoring statistics and self-monitoring the database · Disk, filesystem and hardware considerations · Systematic triage: a runbook for an instance that has become slow
Running it as production infrastructure. Authentication, tokens and role-based access, TLS for client and inter-node traffic, then alerting through native checks and notification rules or through Kapacitor, monitoring InfluxDB's own health, backup and restore, and a closing project applying the whole chain.
Topics: Authentication and authorisation: users, tokens, roles and scopes · Securing the API and enabling TLS encryption · Network exposure, firewalling and multi-tenant separation · Native checks, thresholds and deadman alerts · Notification endpoints and notification rules · Kapacitor: TICKscripts, stream and batch tasks, alert handlers · Anomaly-style alerting and its practical limits · Monitoring InfluxDB health with built-in tools and external collectors · Backup, restore and disaster recovery testing · Applying the full chain end to end and reviewing open questions
We rebuild the agenda around the tools you actually run.
Request a custom agendaDesign a schema for a real dataset, estimate its series cardinality on paper, then load it and compare the estimate to reality.
Collect from three input plugin types, tune batch size and buffering, then restart the database mid-load and prove no points were lost.
Answer five operational questions in both languages, measure the difference, then rewrite the slowest query and prove the improvement.
Build a raw, hourly and daily downsampling ladder with tasks and retention tiers, and reduce storage by an order of magnitude without losing usable history.
Diagnose a deliberately degraded instance from internal statistics — cardinality growth, compaction pressure or an unbounded query — and fix the actual cause.
Deliver schema, Telegraf ingestion, retention and downsampling, Grafana dashboards, deadman alerting, scoped tokens with TLS, and a tested backup restore.
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 advisorPrefer to call or email?
More ways to reach us on the contact page.