Private corporate batches, live online cohorts and 1-on-1 mentoring in wide events, high-cardinality querying and BubbleUp — debugging failures nobody built a dashboard for — 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 Honeycomb as a debugging practice rather than a dashboard tool — instrumenting with OpenTelemetry so events are genuinely wide, attaching the request-scoped attributes that make a query answerable, and driving the query-BubbleUp-refine loop live against a system that is actually misbehaving. Sessions cover the parts teams get wrong after the trial: derived columns and SLI definitions, burn alerts sized to a real error budget, trigger design that does not recreate metric alerting, and Refinery sampling with head and tail rules plus correct SampleRate accounting so cost falls without counts becoming fiction.
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 Honeycomb that means a trainer who has run it in production — wide events, high-cardinality querying and BubbleUp — debugging failures nobody built a dashboard for — 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 Honeycomb batchHoneycomb is a commercial observability platform built around a single idea: store arbitrarily wide, structured events rather than pre-aggregated metrics, and let engineers query them across any dimension afterwards. One event carries hundreds of fields — user ID, tenant, build SHA, feature flag state, database shard, region, endpoint, error class — and none of those dimensions has to be chosen in advance. That is what makes high-cardinality analysis possible, and it is the difference between a dashboard that answers questions you anticipated and a tool that answers the question you have at 03:00.
Data reaches Honeycomb through OpenTelemetry. Spans from instrumented services carry trace and span identifiers, duration and attributes; Honeycomb stores each span as an event and reconstructs traces on read. The query surface is a small grammar — VISUALIZE with counts, heatmaps and percentiles, WHERE, GROUP BY, HAVING and ORDER — over which sits BubbleUp, the feature Honeycomb is best known for. Select an anomalous region of a heatmap and BubbleUp compares the distribution of every field inside that selection against everything outside it, ranking the dimensions that differ. That turns 'some requests are slow' into 'these requests are slow, and they all share this build, this tenant and this shard' without anybody guessing first.
Around that core sit derived columns for computed fields, triggers for threshold alerting, service level objectives with error-budget burn alerts, boards for shared views, and Refinery, Honeycomb's trace-aware sampling proxy. Refinery matters commercially as well as technically: pricing is volume-based, so head and tail sampling with correct SampleRate accounting is what keeps a high-traffic estate affordable while preserving the interesting traces.
Distributed systems broke the monitoring model that most teams still run. When a request crosses eight services, three of them serverless and one a third-party API, a CPU graph and a per-service error rate cannot tell you which customers are affected or why. The failures that matter are the ones nobody predicted, and pre-aggregated metrics discard exactly the dimensions needed to find them.
Honeycomb was the tool that made the argument for high-cardinality, event-based observability, and the rest of the market followed — the wide-event model now shows up across the vendor landscape. Learning it therefore teaches a method as well as a product, and because ingestion is standard OpenTelemetry, the instrumentation work carries over if the platform ever changes.
There is a commercial dimension too. Observability spend is now a line item large enough for finance to ask about, and the answer is almost always sampling done properly. Engineers who can design a Refinery rule set that keeps every error and slow trace while dropping the bulk of uninteresting successes — with sample rates recorded so counts stay accurate — deliver a measurable saving alongside better debugging.
Why dashboards stop working. Pre-aggregation and the dimensions it throws away, cardinality and dimensionality defined precisely, known-unknowns against unknown-unknowns, and where Honeycomb sits against Prometheus, Datadog and an ELK stack — including where those remain the better answer.
Topics: Monitoring versus observability, stated concretely · Wide structured events against pre-aggregated metrics · Cardinality, dimensionality and why both matter · Known-unknowns and unknown-unknowns · Honeycomb compared with Prometheus, Datadog, Grafana and ELK · Environments, services and datasets in Honeycomb · The commercial model and why event volume drives everything
The ingestion path, end to end. OpenTelemetry SDKs and auto-instrumentation, the Collector as a pipeline with receivers, processors and exporters, resource and span attributes, and the Honeycomb-specific configuration — ingest keys, datasets, environments and the classic model where it is still in use.
Topics: OpenTelemetry data model: traces, spans, attributes, resources · Auto-instrumentation for common frameworks and languages · The OpenTelemetry Collector: receivers, processors, exporters · Exporting to Honeycomb over OTLP · Ingest keys, configuration keys and environment separation · Datasets, services and the Environments and Services model · Instrumenting a Kubernetes workload · Verifying ingest and debugging events that never arrive
The single largest determinant of whether Honeycomb is useful. Which attributes belong on a span, how to carry request-scoped context so every span in a trace can be filtered by tenant or build, recording errors properly, and the anti-patterns that produce thousands of narrow, useless spans.
Topics: Choosing span attributes: identity, dependency, decision and outcome fields · Request-scoped context and propagating it across spans · Semantic conventions and when to depart from them · Recording errors, exceptions and status correctly · Span events and span links · Instrumenting business context: tenant, plan, feature flag, experiment · Manual spans around meaningful work, not every function · Anti-patterns: narrow spans, unbounded attribute values, log-shaped events
The query grammar and how to think in it. Visualisations from COUNT and heatmaps to percentiles and concurrency, filtering and grouping, HAVING for group-level conditions, then moving between an aggregate view and the individual trace waterfall that explains it.
Topics: VISUALIZE: COUNT, heatmaps, P50/P95/P99, AVG, MAX, RATE and CONCURRENCY · WHERE filters and operator behaviour · GROUP BY, ORDER and LIMIT · HAVING for filtering groups rather than events · Reading a heatmap and what its shape tells you · The trace waterfall: critical path, gaps and parallelism · Moving between aggregate and individual trace · Query history, saved queries and boards
The workflow the platform exists for. Selecting an anomalous population, letting BubbleUp rank the dimensions that differ, forming a hypothesis and narrowing — repeated until the cause is a specific build, tenant, shard or dependency. Then derived columns to make recurring questions one click instead of five.
Topics: Selecting a population on a heatmap · How BubbleUp compares inside against outside · Reading the ranked dimension output and dismissing correlations · Iterative narrowing: hypothesis, filter, re-run · Comparing time windows and deployments · Derived columns: the formula language and common patterns · Building SLI and classification columns · When BubbleUp finds nothing, and what that means
How a high-traffic estate stays affordable without losing the traces that matter. Head against tail sampling, why trace-aware sampling requires buffering whole traces, deterministic and dynamic samplers, rule-based sampling for errors and slow requests, and SampleRate accounting so counts stay true.
Topics: Head sampling versus tail sampling and their trade-offs · Why trace-aware sampling needs the full trace in hand · Refinery architecture, peer clustering and trace buffering · Deterministic sampling by trace ID · EMA dynamic sampling by key · Rules-based sampling: keep all errors, keep slow traces, drop health checks · SampleRate and preserving accurate counts and percentiles · Sizing Refinery and monitoring its own health · Measuring the cost effect of a sampling change
From tooling to practice. Defining SLIs as derived columns and SLOs on top of them, burn alerts sized to a real error budget, triggers where a threshold genuinely fits, integration with paging and chat — and the adoption work of moving a team off a metrics-first habit.
Topics: SLI definition as a derived column · SLOs, error budgets and burn alerts · Triggers: thresholds, frequency and alert fatigue · When a trigger is right and when an SLO is right · Integrations with PagerDuty, Slack and webhooks · Boards, collaborative queries and shared query history · Service maps and dependency views · Access control, API keys and environment separation · Migrating a team from dashboard-first to query-first debugging
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument two services, deploy an OpenTelemetry Collector, route spans through it into separate environments, then debug an event that never arrives.
Take a thinly instrumented service, add identity, dependency and decision attributes with request-scoped context, and reach the point where five specified questions each take one query.
Answer a set of production-style questions using only VISUALIZE, WHERE, GROUP BY and HAVING, then trace each aggregate answer down to the individual span that proves it.
Investigate a planted latency regression with BubbleUp, narrowing iteratively until the cause is a specific build, tenant and dependency, and record the query path taken.
Deploy Refinery, write rules that retain every error and slow trace while dropping routine successes, and verify that counts and percentiles survive via SampleRate accounting.
Define an SLI and SLO, configure a burn alert, trigger it with a real fault, and run the whole path from alert to root cause using traces and BubbleUp under time pressure.
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.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| 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.