Private corporate batches, live online cohorts and 1-on-1 mentoring in the unified logging layer — tag-based routing, pluggable inputs and outputs, buffering and delivery guarantees — 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 Fluentd as a delivery system rather than a configuration file: the event model of tag, time and record, then routing through source, filter, match and label directives so a large configuration stays readable. Sessions go deep on the part that decides reliability — memory versus file buffers, chunk and queue sizing, flush intervals, retry and exponential backoff, secondary outputs, and what at-least-once delivery means for duplicates downstream. Around that: tail input with position files and multiline parsing, forward input and output with load balancing and failover into an aggregator tier, record transformation and enrichment including Kubernetes metadata, and the Kubernetes deployment shape most estates use — Fluent Bit on each node with Fluentd aggregating behind it — plus self-monitoring, worker tuning and volume reduction before the data reaches a priced destination.
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 Fluentd that means a trainer who has run it in production — the unified logging layer — tag-based routing, pluggable inputs and outputs, buffering and delivery guarantees — 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 Fluentd batchFluentd is an open-source data collector that sits between the things producing logs and the systems that store them. It is a CNCF graduated project, and it describes itself as a unified logging layer: rather than every application learning to write to every backend, applications and hosts emit to Fluentd, which parses, filters, transforms and routes to wherever the data needs to go. Adding a destination becomes a configuration change instead of a redeployment of every service.
The internal model is small and worth learning precisely. Every event has three parts — a tag, a timestamp and a record — and the tag is what drives routing. Configuration is a set of directives: source blocks define inputs, filter blocks transform matching events, match blocks send them to outputs, and label blocks group processing into named paths so a complex configuration stays readable instead of becoming a chain of re-tagging tricks. Everything beyond the core is a plugin, of which there are over a thousand, and events move internally in MessagePack rather than as text.
The part that decides whether a pipeline is dependable is buffering. Output plugins write into memory or file buffers organised as chunks, flushed on interval or size, retried with exponential backoff, and optionally diverted to a secondary output when retries are exhausted. Those settings — chunk limits, queue length, flush thread count, retry policy — determine what happens when a destination is slow or down, and they are the difference between a log pipeline that absorbs a backend outage and one that quietly drops a morning's data. Fluent Bit, the lighter sibling written in C, is commonly deployed as the per-node collector with Fluentd as the aggregation tier behind it, which is the shape most Kubernetes logging architectures take.
Log destinations have multiplied. The same event stream now feeds a search platform for engineers, an object store for cheap long retention, a security information system for the compliance team, and sometimes a data warehouse for analytics. Writing that fan-out into every application is unworkable, and a dedicated collection and routing layer is now standard architecture rather than an optimisation.
Fluentd is the vendor-neutral option in that layer, and its plugin catalogue is the reason it stays chosen — whatever the source and whatever the destination, something already exists to connect them. In Kubernetes it is close to ubiquitous, usually paired with Fluent Bit as the node agent, and it is the piece that adds pod, namespace and label metadata to container logs that would otherwise be anonymous lines in a file.
The skill organisations need is reliability engineering, not configuration syntax. A minimal Fluentd configuration takes ten minutes. Sizing buffers so a two-hour backend outage does not lose data, understanding what at-least-once delivery means for duplicate records downstream, parsing multiline stack traces without merging two unrelated exceptions, keeping CPU in check when a single regex meets a hundred thousand events per second, and reducing volume before it reaches a per-gigabyte-priced destination — that is what a production log pipeline actually demands.
Why a collection tier exists at all, and what Fluentd is inside it. The event model of tag, timestamp and record, the plugin architecture that makes the catalogue possible, MessagePack as the internal representation, and an honest comparison of Fluentd, Fluent Bit and the other collectors in this space.
Topics: The unified logging layer: decoupling producers from destinations · The event model: tag, time and record · Plugin architecture: input, parser, filter, output, formatter, buffer, storage · MessagePack and why events are not passed around as text · Fluentd versus Fluent Bit: resource use, plugin coverage and where each belongs · Comparison with other collectors and shippers · Installation: packages, gems, containers and the calyptia and td-agent distributions · Running Fluentd as a service, in a container and in the foreground for debugging · Where a collection tier is unnecessary complexity
The configuration language and the discipline that keeps it maintainable. Source, filter, match, label and system directives, tag matching patterns and their precedence, labels as named processing paths, includes for modular configuration, and the re-tagging patterns that make an unfamiliar configuration impossible to follow.
Topics: Configuration file structure and the main directives · Tag design and match patterns: wildcards, alternation and precedence · Filter and match ordering, and why the first match wins · Labels: named processing paths and the @ERROR label · The system directive: log level, workers, process naming · Include files and building modular configuration · Re-tagging with relabel and rewrite_tag_filter, and when to avoid both · Environment variables and templating configuration across environments · Validating configuration and dry runs before restart · Reading someone else's configuration: a systematic method
Getting events in and giving them structure. The tail input with position files and rotation handling, forward for receiving from other Fluentd or Fluent Bit instances, HTTP, syslog, systemd and Windows event log, then parsers — regexp, JSON, LTSV, grok, multiline — and the parsing problems that bite in production.
Topics: in_tail: path patterns, position files, rotation and truncation handling · Multiline parsing for stack traces, and keeping two exceptions from merging · in_forward: receiving from other collectors, with TLS and shared keys · in_http, in_syslog, in_exec and in_tcp · systemd journal and Windows event log inputs · Parsers: regexp, JSON, LTSV, CSV, apache, nginx and grok · Custom parsers and named capture groups · Timestamp parsing, time zones and events that arrive with the wrong time · Encoding problems and unparseable lines: the @ERROR path · Measuring parser cost: what a bad regex does at high event rates
Reshaping records between input and output. Record transformation, field addition and removal, grep-style inclusion and exclusion, parsing a field within an already structured record, throttling noisy sources, masking sensitive values, and enriching with host, environment and Kubernetes metadata.
Topics: filter_record_transformer: adding, renaming and removing fields · filter_parser: parsing a field inside an already structured record · filter_grep: including and excluding by pattern · Ruby expressions in configuration, and their performance cost · Throttling noisy sources before they reach a priced destination · Masking and redacting sensitive fields · Enriching with hostname, environment, region and deployment metadata · Kubernetes metadata enrichment: pod, namespace, labels and annotations · Normalising field names across sources that will never agree · Dropping events deliberately, with a record of what was dropped
The module that separates a pipeline from a demo. Memory versus file buffers, chunks and queues, flush intervals and thread counts, retry with exponential backoff, secondary outputs when retries are exhausted, and the delivery guarantees Fluentd actually offers — with the duplicate handling that follows from at-least-once.
Topics: The buffer model: chunks, queues, keys and staging · Memory buffer versus file buffer, and when each is correct · chunk_limit_size, queue_limit_length and total buffer capacity arithmetic · flush_interval, flush_thread_count and flush_at_shutdown · Retry behaviour: exponential backoff, retry limits and retry_forever · Secondary output as a last resort for undeliverable chunks · Backpressure: what happens upstream when a buffer fills · At-least-once versus at-most-once, and the duplicates downstream must tolerate · Sizing a buffer for a stated outage window · Recovering after an outage: replay rate, thundering herd and rate limiting
Where the data ends up, and how to send it to several places without doubling the work. The forward output with load balancing and failover into an aggregator tier, then the common destinations — search platforms, object storage, message brokers, HTTP endpoints — plus copy and routing for fan-out and formatters that control the shape on the wire.
Topics: out_forward: load balancing, failover, weights and health checking · Aggregator topology: node agents forwarding into a central tier · out_elasticsearch and out_opensearch: index naming, templates and bulk behaviour · out_s3 and object storage for cheap long retention · out_kafka and out_http for brokers and generic endpoints · out_loki, out_file and out_stdout for other destinations and debugging · copy for fan-out, and independent buffering per destination · Formatters: JSON, LTSV, single value and custom output shapes · Destination-specific failure behaviour and what each does with a retry · Reducing volume before a per-gigabyte-priced destination
Running it where most of it runs, and keeping it healthy. DaemonSet deployment and CRI log format parsing, Fluent Bit as node agent with Fluentd aggregating, the Fluent Operator, then operations: self-monitoring, worker and thread tuning, systematic troubleshooting, upgrades, and controlling total pipeline cost.
Topics: Fluentd and Fluent Bit as a DaemonSet on Kubernetes · Container log formats: CRI and Docker, and parsing each correctly · Kubernetes metadata filter and enriching by pod, namespace and label · Fluent Bit as node collector with Fluentd as aggregator: dividing the work · The Fluent Operator and managing configuration as custom resources · Self-monitoring: the monitor agent, Prometheus metrics and what to alert on · Performance tuning: multi-worker, thread counts and CPU-bound plugins · Troubleshooting: events not arriving, buffer growth, retry loops, memory growth · Upgrades, plugin version management and configuration compatibility · Total cost of a log pipeline and where to cut it without losing signal
We rebuild the agenda around the tools you actually run.
Request a custom agendaRefactor a tangled re-tagging configuration into labelled processing paths, then design a tag scheme covering four sources and three destinations.
Tail a rotating application log containing stack traces, parse them correctly, handle unparseable lines through the error path, and measure parser CPU cost.
Size a file buffer against a measured event rate, kill the destination mid-load, restore it, and prove the data arrived with bounded duplication.
Send the same events to a search backend, object storage, a broker and a debug output, each with its own buffer, format and failure behaviour.
Deploy Fluent Bit as a DaemonSet parsing CRI logs with pod metadata, forward into a Fluentd aggregator tier, and fail one aggregator under load.
Instrument the pipeline with its own metrics, alert on buffer depth and retry rate, tune workers under sustained load, and write the failure runbook.
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.