Private corporate batches, live online cohorts and 1-on-1 mentoring in expression-based alerting with rules you can back-test against historical data before you deploy them — 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 Bosun as an alerting discipline rather than a UI tour — the expression language and its type system, reduction functions, band and shiftBand comparisons against historical windows, alias and joins across tag sets, and the depends and squelch mechanisms that stop one failure producing forty pages. Sessions cover the operational reality of an inherited deployment: scollector configuration and custom collectors, the incident lifecycle and notification chains, unknown-state handling, back-testing rules against real historical data before they ship, and a documented migration path from a Bosun rule set to Prometheus recording rules and Alertmanager routing.
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 Bosun that means a trainer who has run it in production — expression-based alerting with rules you can back-test against historical data before you deploy them — 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 Bosun batchBosun is an open-source monitoring and alerting system written in Go and originally built by the Stack Exchange infrastructure team. It is not a metrics store: it sits on top of one and does the alerting. Bosun queries a time-series backend — OpenTSDB, Graphite, InfluxDB, Elasticsearch or Prometheus — evaluates alert rules written in its own expression language, and manages the resulting incidents through open, acknowledged and closed states with notification chains and escalations attached.
Two design decisions distinguish it. The first is the expression language, which treats a query as a typed value that can be reduced, aliased, joined and combined — so a rule can compare the last five minutes against the same window a week ago, or suppress an alert when a dependency is already firing, without shelling out to a script. The second is rule testing: Bosun's web interface lets you run an alert definition against historical data and see exactly which hosts would have paged and when, before the rule ever reaches production. Very few alerting systems let you back-test a threshold that way, and it is the reason teams still cite Bosun as an influence on how alerts should be authored.
Alongside the server, Bosun ships scollector, a metrics collection agent with built-in collectors for hosts, processes and common services, plus a metadata channel that tags metrics with descriptions and units. Bosun is a niche tool with a small installed base, and its upstream development has largely stopped — most engineers who need it today are maintaining an inherited deployment or planning a move off it, and this training is built around both of those realities.
Bosun's practical relevance is honest and narrow. It is not a growth technology, and nobody should adopt it for a greenfield estate today — Prometheus with Alertmanager, or a commercial platform, is the sensible default. But a real number of infrastructure teams inherited a working Bosun installation, and it usually sits on the alerting path for systems that matter, which means somebody has to be able to read the rules, change a threshold safely, and keep scollector and the backend healthy.
There is a second reason to learn it, and it outlives the tool. Bosun's model — typed expressions over time series, dependency-aware suppression, unknown-state handling, and back-testing a rule against history before deploying it — is a more rigorous way of thinking about alerting than most teams practise. Engineers who learn it write better Prometheus rules afterwards, because they stop treating a threshold as a guess.
So this training serves two outcomes: operate and safely modify an existing Bosun deployment, and, where the decision has been made, migrate its rule set to a supported stack without losing coverage.
What Bosun is and, just as importantly, what it is not. The separation between metric storage and alerting, how Bosun compares to Nagios, Prometheus with Alertmanager and commercial platforms, and a frank assessment of its upstream maintenance status so decisions about keeping or replacing it are informed.
Topics: Monitoring, alerting and the difference between them · Bosun architecture: server, backend and collection agent · Supported backends: OpenTSDB, Graphite, InfluxDB, Elasticsearch, Prometheus · Bosun compared with Nagios, Icinga and Prometheus/Alertmanager · Upstream maintenance status and what it means operationally · Deciding to keep, freeze or migrate an existing deployment
Standing up a working environment from nothing so the rest of the course has somewhere to run. Installing the Bosun binary, choosing and configuring a time-series backend, the layout of bosun.conf and the rule configuration, and the state store that holds incidents and silences.
Topics: Installing Bosun and running it under systemd or Docker · Configuring OpenTSDB, Graphite, InfluxDB or Elasticsearch as a backend · bosun.conf structure: backend, SMTP, authentication, paths · Rule configuration files and reloading them safely · The internal state store, and what is lost if it is lost · Web interface tour: dashboard, expression editor, rule editor, items
Getting data in. scollector's built-in collectors for host, process, disk and service metrics, how tags and metric metadata work, writing external collectors in any language, and the practical questions of collection interval, cardinality and what not to collect.
Topics: scollector installation, configuration and service management · Built-in collectors: host, process, disk, network and service checks · Tags, tag cardinality and naming conventions · Metric metadata: descriptions, rate types and units · External collectors and the collector output format · Process monitoring and custom application metrics · Collection interval, batching and backend load
The heart of the tool and the reason to learn it. Bosun expressions are typed — series, number sets, scalars — and most confusion comes from mixing them. This module works through the type system, querying, reduction, and the operations that let one expression compare now against last week.
Topics: The type system: seriesSet, numberSet, scalar and how they convert · Querying with q, and duration syntax · Reduction functions: avg, min, max, median, percentile, dev, last, first · band, shiftBand and over for historical comparison · alias, rename and t for tag-set manipulation · Joins and operators across differing tag sets · ungroup, nv and handling missing data · Working iteratively in the expression editor
Turning expressions into alerts people can act on. Alert blocks with warn and crit conditions, the variables that feed a notification, Go templates that render context rather than a bare metric name, and macros and lookup tables that keep a large rule set from repeating itself.
Topics: Alert definition structure: warn, crit, and their thresholds · Template blocks: subject, body and the Go template context · Including graphs, tables and links in notifications · Macros for shared alert boilerplate · Lookup tables for per-host and per-service thresholds · Alert variables and computed values · Writing an alert that tells the responder what to do next
The difference between a monitoring system and a pager that gets ignored. Dependency-aware suppression so a failed switch does not page for fifty hosts, correct handling of the unknown state when data stops arriving, squelch rules, and silences during planned work.
Topics: The depends keyword and dependency-aware suppression · Unknown state: what it means and why ignoring it hides outages · unknownIsNormal and per-alert unknown handling · Squelch rules for excluding known-noisy tag sets · Silences: scope, duration and the audit trail · Flapping, hysteresis and choosing evaluation windows · Auditing an existing rule set for alerts nobody acts on
How an alert becomes an incident and reaches a human. Notification definitions, email and HTTP POST targets, chained notifications with escalation timeouts, the acknowledge, close and forget lifecycle — then the feature that sets Bosun apart, testing a rule against historical data before it ships.
Topics: Notification blocks: email, HTTP POST and chained notifications · Escalation with timeout and next · Incident lifecycle: open, acknowledged, closed, forgotten · The dashboard and item views for on-call use · Integrating with paging and chat systems over HTTP · Rule testing against historical data with the rule editor · Choosing thresholds from back-tested evidence · Reviewing what a rule change would have done last month
Keeping an inherited deployment healthy, and planning the exit when that is the right call. Backup and restore of rule and state data, upgrades, capacity and backend health, common failure modes — then a structured migration of the rule set to Prometheus recording and alerting rules with Alertmanager routing.
Topics: Backup and restore of configuration and incident state · Upgrades, configuration validation and safe rollback · Backend health, retention and query cost · Common failure modes: backend unreachable, rule evaluation lag, stuck unknowns · Access control and authentication options · Mapping Bosun expressions to PromQL · Mapping depends, squelch and templates to Alertmanager inhibition, silences and templates · Running both systems in parallel during cutover
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Bosun against a time-series backend, wire in scollector across three hosts, and confirm queries return live data from the expression editor.
Work through querying, reduction, banding and tag-set joins until the seriesSet-to-numberSet-to-scalar conversions are automatic, fixing deliberately broken expressions along the way.
Author an alert with warn and crit thresholds from lookup tables and a template that renders cause, affected tag sets, a graph and a runbook link rather than a metric name.
Audit a deliberately noisy rule set, add dependencies, fix unknown handling, apply squelches, and demonstrate a large drop in notifications with no loss of real coverage.
Use the rule editor to replay a proposed alert over a month of historical data, count the pages it would have produced, and tune the threshold from that evidence.
Translate a complete Bosun rule set to PromQL and Alertmanager routing, map dependencies to inhibition rules, and run both systems in parallel to prove no coverage was lost.
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| 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.