Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs Nagios 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 Nagios where its behaviour is actually decided: the check scheduler and the interval, retry and max_check_attempts arithmetic; SOFT and HARD states driving notification; parent topology and dependencies that separate a real failure from its consequences; and template, group and macro structure that keeps a thousand-service configuration maintainable. Plugin development is taught as a first-class skill, with the exit-code and performance-data contract, timeouts and thresholds, so equipment nobody else monitors becomes monitorable. Sessions include distributed pollers, passive checks and an honest plan for running Nagios alongside Prometheus.
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 Nagios that means a trainer who has run it in production — Nagios for Bangalore operations teams — scheduling and state machine, custom plugins, dependencies, distributed checks and Prometheus coexistence — 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.
Onsite delivery is at your own office. Nagios sessions in Bangalore commonly run in Whitefield, Electronic City, along the Outer Ring Road, at Manyata Tech Park or in the industrial belt around Peenya and Yeshwanthpur, one site per day so cross-city travel does not eat into lab time. You provide the room, a screen and network access; attendees run their own Nagios instance plus two or three monitored hosts in virtual machines or containers, and we bring sample plugins, configurations and the assessment. Where the estate includes isolated networks or lab hardware we design the poller topology on paper and reproduce the behaviour with simulated passive checks. Sessions are scheduled in IST (UTC+5:30) and planned around change windows, which for teams supporting estates abroad often means avoiding weekend maintenance slots. Invoicing is in INR from our Indian entity with GST, against a purchase order where needed, and travel within Bangalore is included.
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 Nagios batchNagios is a scheduler wrapped around a state machine. The daemon decides when each check runs, executes a small program, and interprets a single exit code — 0, 1, 2 or 3 — plus one line of text. Everything else in the system is a consequence of that contract, which is why Nagios can monitor anything anyone is willing to write a script for, and why writing good plugins is a core skill rather than an advanced one.
The state machine is where operational behaviour is decided. A failing check first enters a SOFT state and is retried at the retry interval; only after max_check_attempts does it become HARD, and only a HARD state change generates a notification. That single mechanism prevents a transient failure from paging anyone. Layered on top are notification periods and escalations, acknowledgements, scheduled downtime, flap detection based on state change history, and freshness checking for results that are supposed to arrive but have not.
Configuration is object-based and inherited: hosts, services, hostgroups, servicegroups, contacts, contactgroups, commands, timeperiods and templates, with macros substituting values at execution time. Whether an estate stays maintainable at a thousand services depends almost entirely on how deliberately that template and group structure was designed. Two further mechanisms decide whether alerts stay useful — host parent relationships, which let Nagios distinguish a host that is DOWN from one that is merely UNREACHABLE behind a failed router, and explicit host and service dependencies that suppress alerts caused by something already known to be broken. Checks themselves may be active, run by the scheduler, or passive, submitted from elsewhere through the external command file or an NRDP or NSCA receiver — which is how distributed pollers, remote sites and event-driven sources feed one central view.
Monitoring split into two worlds and most organisations now live in both. Metrics-first systems took the workloads that emit metrics natively — containers, cloud services, modern applications — while an enormous installed base of hosts, appliances, network gear and physical equipment continued to be watched by check-based systems because nothing else asks a simple question and gets a simple answer. The skill that is now scarce is running that half competently instead of neglecting it until it becomes noise.
The noise problem is the real driver. A monitoring system that pages on every symptom of one underlying failure trains people to ignore it, and the fix is structural: correct parent topology, dependencies, sensible check and retry intervals, notification escalation, downtime discipline and flap detection. Those are Nagios features that exist and are widely unused, and turning them on properly is often the single largest improvement available to an operations team.
The third pressure is coexistence. Teams running both Nagios and Prometheus need a decision about which system owns which signal, how alerts converge on one escalation path, and how to migrate the parts that should move without losing the parts that should not. Doing that deliberately requires understanding both models — which is why demand here is for judgement about monitoring architecture rather than for installation instructions.
What Nagios actually does. The plugin contract of exit code plus output, how the scheduler spreads and executes checks, check latency versus execution time, the reaper, and how to tell an overloaded monitoring host from a genuinely slow check.
Topics: Exit codes, output format and performance data · Active check scheduling, spreading and interleaving · Check latency, execution time and what each indicates · The reaper and result processing · Core architecture, files and processes · Nagios Core and Nagios XI: what differs
The design decision that determines maintainability. Hosts, services, groups, contacts, commands and timeperiods; template inheritance and multiple inheritance; macros and custom variables; file organisation, and validating a configuration before it is reloaded.
Topics: Object types and their relationships · Template inheritance and overriding · Hostgroups, servicegroups and applying services by group · Macros: standard, on-demand and custom variables · Directory layout and configuration file organisation · Validating configuration and safe reloads · Refactoring a sprawling configuration without an outage
The module that decides how many pages the night shift receives. SOFT and HARD states, check and retry intervals, notification options and intervals, contacts and escalations, acknowledgements, scheduled downtime, and flap detection.
Topics: SOFT and HARD states and max_check_attempts arithmetic · Notification options, intervals and first_notification_delay · Contacts, contactgroups and notification timeperiods · Escalations and who gets woken at 03:00 · Acknowledgements and their effect on notification · Scheduled and flexible downtime around change windows · Flap detection and state change thresholds
Stopping one failure from generating four hundred alerts. Host parent relationships and the DOWN versus UNREACHABLE distinction, reachability logic, host and service dependencies with execution and notification suppression, and modelling a real network topology.
Topics: Host parents and the reachability algorithm · DOWN versus UNREACHABLE and why the difference matters · Host dependencies: notification and execution failure criteria · Service dependencies within and across hosts · Modelling a multi-site network topology · Dependency loops and configuration mistakes · Verifying suppression behaviour before you need it
The plugin library in practice. Standard plugins for TCP, HTTP, DNS, SMTP, disk, load and processes; NRPE for Linux remote checks and NSClient++ for Windows; SNMP for network gear and appliances; check_by_ssh; and certificate, log and database checks.
Topics: Standard plugin set and threshold syntax · NRPE: configuration, arguments and its security posture · NSClient++ and Windows monitoring · SNMP checks, MIBs, OIDs and traps · check_by_ssh as an alternative to an agent · TLS certificate expiry and web transaction checks · Database, log file and process checks
The skill that makes Nagios monitor anything. The plugin development guidelines, argument handling, warning and critical threshold ranges, timeouts, performance data format, and packaging plugins so they are testable, reviewable and reusable across an estate.
Topics: Plugin guidelines: exit codes, output and multiline text · Threshold and range syntax done correctly · Argument parsing and sane defaults · Timeouts and never hanging the scheduler · Performance data format for graphing · Writing plugins in shell, Python or Perl · Testing, packaging and distributing plugins
Monitoring what the poller cannot reach. Passive check results and the external command file, NRDP and NSCA receivers, freshness checking so silence becomes an alert, distributed pollers reporting to a central instance, and event handlers that act on a state change rather than only reporting it.
Topics: Passive check results and submission mechanisms · NRDP and NSCA receivers · Freshness checking and stale result detection · Distributed monitoring topologies and central aggregation · Monitoring across isolated or firewalled networks · Event handlers for automatic remediation · Obsessive checks and forwarding results upstream
Living with the system. Performance data to graphing back-ends, reporting and availability figures, tuning and scaling a busy instance, backup and upgrade, then an honest architecture decision about running Nagios alongside Prometheus and where each should own the signal.
Topics: Performance data processing and graphing back-ends · Availability reporting and what the numbers mean · Tuning: check spreading, worker processes, large installation tweaks · Scaling one instance versus splitting the estate · Backup, configuration in version control and change review · Upgrades and plugin compatibility · Nagios and Prometheus: signal ownership and one escalation path · Planning a partial migration without losing coverage
We rebuild the agenda around the tools you actually run.
Request a custom agendaOverload a monitoring host deliberately, then use latency and execution time to prove whether the problem is scheduling capacity or a slow plugin, and correct it.
Refactor a flat configuration into templates, hostgroups and macros, then add a new service to eighty hosts with a single edit and a validated reload.
Take a noisy service set, tune check and retry intervals, set escalation and downtime correctly, enable flap detection, and prove genuine failures still notify.
Model parent relationships and dependencies for a three-tier network, fail the upstream device, and prove only one actionable alert is raised.
Write a plugin for a device or API with no existing check: correct exit codes, threshold ranges, timeout handling and performance data, then package and deploy it.
Build a distributed topology with remote pollers, passive result submission, freshness checking and an event handler, aggregating into a single central instance.
Nagios survives in Bangalore for reasons that are specific rather than sentimental. Telecom and networking R&D, embedded and hardware engineering, aerospace and avionics work, and the manufacturing and industrial estate towards Peenya and Yeshwanthpur all monitor equipment that a modern metrics agent does not speak to: test rigs, environmental and power systems, instruments on a lab bench, appliances with nothing but SNMP, and hosts on networks that are deliberately isolated. Nagios monitors any of those the moment somebody writes a script that exits with the right code, and that plugin contract is why it is still the system of record in those places long after web estates moved on.
The second reason is operational geography. A significant number of round-the-clock operations desks staffed in Bangalore watch estates that are physically somewhere else, which makes the parts of Nagios most courses gloss over the parts that matter: host and service dependencies so one failed router does not produce four hundred alerts, parent-child topology for correct unreachable versus down classification, scheduled downtime around change windows in other timezones, flap detection, freshness checking for passive results arriving over a slow link, and distributed pollers reporting back to a central instance. The practical question in almost every Bangalore engagement is not how to install Nagios; it is how to reduce the number of pages an overnight shift receives while keeping genuine failures visible. Alongside that, most of these teams now run Prometheus for their newer workloads, so an honest coexistence plan — which system owns which signal, and how one escalation path is preserved — is part of the brief rather than a footnote.
The checks themselves are also more physical here than in a purely cloud estate. Around the industrial belt at Peenya, Bommasandra and Jigani, and in the equipment areas of engineering sites across Bengaluru, what gets monitored includes uninterruptible power supplies, diesel generator changeover, precision cooling, temperature and humidity probes and door contacts — signals that arrive over SNMP from a controller nobody has documented, and that matter because a monsoon-season power event is a genuine operational risk rather than a hypothetical one. Writing a plugin for a device whose vendor shipped a MIB and no examples is a normal Tuesday. Hiring reflects the shift-based reality too: monitoring configuration usually belongs to two or three engineers while thirty people on rotating shifts act on its output, so the skill actually being bought is the ability to make the configuration explainable and safe to change by someone who was not there when it was written.
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.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| 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.