Private corporate batches delivered onsite across Pune, 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 from the plugin contract and the object model outward, because those two things decide everything an estate later becomes: exit codes, thresholds and performance data on one side; templates, groups, timeperiods and parent-child topology on the other. Sessions go deep on the areas that matter most where an agent is not permitted — SNMP versions and credentials, MIBs and OID selection, polling intervals a small device will survive, trap reception, and passive results with freshness checking for hosts that can only report outward — and on the operational habits that make an inherited installation safe to change at all: configuration under version control, verification before every reload, downtime aligned to somebody else's change window, escalation that follows a shift roster, and an audit that classifies every existing check as keep, fix or retire before anyone proposes replacing the system.
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 Core and XI for Pune's plant-floor, network and legacy server estates — 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 covers Hinjewadi, Kharadi, Magarpatta, Talawade, Yerwada and Baner, and we travel out to Pimpri-Chinchwad, Chakan and the surrounding industrial belt for plant-side teams; you provide the room, a screen and network, we bring trainer, agenda, plugin repositories, assessments and certificates. Hours are 09:30 to 17:30 IST, and for plant teams we schedule around shift changeover rather than through it. Two things make the labs land: a handful of SNMP-capable devices or simulators the group can poll, and — if your monitoring server sits on a segmented network — a decision beforehand about whether we work on a lab instance or a read-only copy of your real configuration, because we will not push changes to a production monitoring host during a session. Attendees each need a monitoring host and two targets, which we walk them through provisioning. Invoicing is in INR with GST against your purchase order from the Indian entity; travel to the outer industrial belt is quoted separately.
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 very small contract. It runs an executable — a plugin — against a host or a service, reads the exit code it returns and the single line of text that comes with it, and feeds that result into a state machine which decides whether anything is genuinely wrong and who should hear about it. Because the contract is that small, anything you can express as a script becomes a check, which is exactly why Nagios still watches equipment no modern agent will ever run on: switches, firewalls and uninterruptible power supplies, environmental sensors, historian servers, and Windows hosts running plant applications nobody is permitted to touch.
The configuration is a set of text objects that inherit from one another — hosts, services, hostgroups, servicegroups, contacts, contactgroups, commands and timeperiods, assembled through templates. Two mechanics in that model do most of the work in a real estate. Parent-child host relationships let the engine mark everything behind a failed uplink as unreachable rather than down, so one dead switch produces one alert instead of ninety. And the distinction between soft and hard states means a check must fail repeatedly, up to max_check_attempts, before anyone is notified — which stops a single dropped poll from waking a shift engineer at 02:00.
Reach comes from three directions. Agents such as NRPE, NCPA and NSClient++ where installing software is permitted; SNMP polling and traps where it is not; and passive results submitted through NSCA or the external command file for hosts that sit behind a firewall and can only report outward. Nagios Core is the open-source engine; Nagios XI wraps the same scheduler in a configuration manager, dashboards, wizards, auto-discovery, reporting and user administration. Neither is a time-series database, and knowing where that boundary falls is what lets a team run Nagios and a metrics platform alongside each other on purpose rather than by accident.
The reason Nagios keeps being booked in Pune is structural rather than nostalgic. The manufacturing belt from Pimpri-Chinchwad through Chakan, Talegaon and Ranjangaon runs on equipment that speaks SNMP and nothing else, sits on segmented networks with no outbound route, and in many cases cannot have software installed on it at all without voiding a vendor support contract. A check-and-notify engine is the correct architecture for that estate, and enthusiasm for pull-based metrics does not change the constraint.
The second driver is inheritance. Shared-services and captive operations floors in Hinjewadi, Kharadi, Talawade and Magarpatta took on large Core or XI installations along with the contracts they support, usually without the engineer who built them. Somebody now has to read eleven hundred service definitions and say which still matter, which are duplicated under three different names, and which have been sitting in a scheduled downtime since a migration two years ago. That is a reading skill before it is a migration skill, and very few people are taught it.
The market for it is also not shrinking as fast as people assume. Pune postings that name Nagios pair it with SNMP, Linux administration and an ITSM platform, and increasingly with a brief to run it beside Prometheus or a hosted platform rather than instead of one. The engineers who can hold both models in their head are the ones who get to make that call rather than execute somebody else's.
Monitoring architecture before any configuration is written. What a check-and-notify engine does that a metrics platform does not, the plugin contract that everything else rests on, the Nagios process and the files it reads and writes, and an honest map of which parts of a mixed estate belong here and which belong somewhere else.
Topics: Availability checks and time-series metrics answer two different questions · The plugin contract: exit codes, status line and performance data · Core architecture: scheduler, plugins, status file, external command file, logs · Core versus XI — what the licence actually buys you · Agent, agentless and passive collection paths · Segmented and disconnected networks, and what they rule out immediately · Building the estate inventory before writing a single object
Building an installation you understand rather than inheriting one you are afraid of. Dependencies and prerequisites, source versus package installation and the layout each produces, web interface authentication, installing where there is no outbound route, and putting the whole configuration under version control with verification before every reload.
Topics: Nagios dependencies and prerequisites · Manual installation from source, and what it teaches you about the layout · Package-based installation and the differences it introduces · Directory layout: etc, objects, libexec, var and the external command file · Web interface setup and authentication · Installing and updating with staged packages on a disconnected host · Upgrading an existing installation without losing local modifications · Configuration in version control, pre-flight verification and a safe reload
The structure that decides whether an estate stays maintainable past a few hundred devices. Every object type and the directives that actually matter, then templates and inheritance, custom object variables and macros, and splitting configuration across directories so two engineers can work on it in the same week without colliding.
Topics: Nagios terminology and the object types · Host and service definitions and their load-bearing directives · Hostgroups and servicegroups, and choosing what to group by · Contacts, contactgroups and their notification directives · Command definitions and macro expansion · Timeperiods, exclusions and holiday handling · Templates, inheritance and multiple inheritance · Custom object variables and user macros · Splitting configuration across files and directories for concurrent editing
How Nagios decides something is broken, and how to stop it deciding too quickly. Host versus service checks, soft and hard state types with max_check_attempts, check and retry intervals, active and passive execution, freshness checking, scheduler interleaving and load spreading, then modifying a running instance through the external command file.
Topics: Host checks versus service checks, and the difference that surprises everyone once · State types: soft, hard and max_check_attempts · check_interval, retry_interval and notification_interval in combination · Active checks, passive checks and freshness thresholds · Scheduling, interleaving and spreading polling across the cycle · Flap detection and setting its thresholds honestly · Runtime modification through the external command file · Reading nagios.log and the status file while an incident is running
Where the system gets its reach. The standard plugin set and what each member covers, the threshold range syntax that trips up nearly everyone, performance data and what consumes it, then writing plugins in Bash and Python for the devices and applications nobody has published a check for — with argument handling, timeouts and packaging for fleet deployment.
Topics: The standard plugin set and its real coverage · Threshold and range syntax, including the inclusive and negated forms · Performance data format and the graphing addons that read it · Writing a plugin in Bash: arguments, timeouts, exit codes · Writing a plugin in Python and handling library dependencies offline · Testing a plugin from the command line before wiring it into an object · Packaging and distributing plugins with configuration management · Event handlers that take corrective action instead of only reporting
Getting inside a machine when you are allowed to, and reporting outward when you are not. NRPE configuration and the argument-passing decision, NCPA as the cross-platform alternative, NSClient++ on Windows servers and desktops, SSH and WMI as agentless options, and passive submission through NSCA for hosts that can only talk out through a firewall.
Topics: NRPE: installation, nrpe.cfg, allowed_hosts and command definitions · check_nrpe and the argument-passing security trade-off · NCPA: agent and agentless modes, API tokens, cross-platform coverage · NSClient++ on Windows: services, event log, performance counters, disks · Agentless checks over SSH and WMI · Passive results with NSCA and the external command file · Freshness thresholds for passive services that simply go quiet · Deploying and versioning agents across a fleet you do not log into daily
The output of the whole system, and the part inherited estates get worst. Every filter a notification must pass before it is sent, contact and timeperiod configuration, notification options per state transition, message content that is actionable without opening a console, delivery by mail, gateway and webhook, and escalations that follow a shift roster rather than one distribution list.
Topics: Notification logic: every filter a notification must survive to be delivered · Notification preferences on contacts, hosts and services · notification_options and which state transitions actually notify · Customising message content with macros so it stands alone · Delivery: e-mail, SMS gateway, chat and webhook · Escalation definitions: first and last notification, escalation periods · Timeperiod-based routing, quiet hours and shift boundaries · Routing into a ticketing system instead of a shared mailbox · Measuring notification volume and reducing it deliberately
Turning an alert storm into one actionable alert. Parent-child host relationships and the unreachable state, host and service dependencies with their separate execution and notification effects, scheduled downtime aligned to somebody else's change window, acknowledgements, and the discipline that keeps a console meaningful rather than permanently amber.
Topics: Parent-child host relationships and suppressing a downstream flood · Unreachable versus down, and why the distinction exists at all · Host dependencies and service dependencies · Execution dependencies versus notification dependencies · Scheduled downtime: fixed, flexible and recurring · Aligning downtime with a customer change window or a plant shutdown · Acknowledgements, comments and handover notes · Auditing what is currently suppressed, by whom, and since when
The core of any estate where the target cannot run your code. SNMP versions and credentials, MIBs and choosing the right OIDs, check_snmp and the interface checks that matter, bandwidth and error counters, trap reception and translation, and polling intervals that will not overwhelm a small device or an already busy link.
Topics: SNMP v1, v2c and v3: credentials, security levels and what to use where · MIBs, OIDs and finding the right object for the value you want · check_snmp thresholds, multi-OID checks and string comparisons · Interface status, bandwidth, errors and discards · Routers, switches, firewalls and uninterruptible power supplies · Environmental and sensor monitoring on plant equipment · Traps: snmptrapd, snmptt and converting a trap into a passive result · Polling intervals, timeouts and the load a small device can tolerate · ICMP, TCP and UDP port checks, DNS, HTTP, FTP and certificate expiry
Growing an estate without growing the manual work. Auto-discovery and what to do with its output, generating configuration from an inventory source, distributed monitoring with worker pollers, poller placement across segmented networks, and tuning a large installation when check latency starts climbing and nobody can say why.
Topics: Running auto-discovery jobs and reviewing the results critically · Generating host and service definitions from an inventory or CMDB · Bulk onboarding, and naming conventions that survive it · Distributed monitoring with NSCA workers and mod_gearman · Placing pollers across segmented or plant networks · Performance tuning: check latency, reaper interval, concurrent checks · Sizing the monitoring host, its storage and its retention · Backup, restore and configuration change control at scale
Running the platform for an organisation, and being honest about its boundaries. The Core Config Manager and its apply workflow, dashboards per audience, availability and SLA reporting, user administration, integration with ticketing and chat — then a structured method for deciding which checks should move to a metrics platform and which should stay exactly where they are.
Topics: Core Config Manager: creating objects, applying configuration, rollback · Dashboards and views built for a specific audience · Availability, SLA, state history and alert histogram reports · Users, roles, account cloning and support masquerading · Managing components and managing plugins in XI · Integration with ITSM, ticketing and chat tooling · Exporting performance data to a graphing or metrics stack · Auditing an inherited configuration: keep, fix or retire · Running Nagios alongside Prometheus, Zabbix or a hosted platform · Planning a partial migration with a parallel-run period and a stop condition
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a sprawling copy-pasted configuration, restructure it into templates, groups and dependencies, and keep going until a new device is described by its template plus two lines of its own.
Walk a switch or a simulator, pick the OIDs that carry real information, build interface and environment checks with survivable polling intervals, then convert an incoming trap into a passive result.
Assemble a plugin, its interpreter dependencies and its object configuration into one offline bundle, install it on an isolated monitoring host, and verify the check end to end without any external download.
Model parent-child relationships and service dependencies across a site, then pull the uplink and count what arrives — before and after the change.
Build contacts, timeperiods and escalations that reach the engineer genuinely on shift, rewrite the message so it stands alone, and deliver it into a ticket rather than a mailbox.
Work through a configuration nobody in the room wrote, decide the fate of every check with a stated reason, and turn the result into a coexistence plan naming what moves to a metrics platform and what stays.
Nagios survives in Pune for reasons that have nothing to do with fashion. Along the manufacturing belt from Pimpri-Chinchwad through Chakan, Talegaon and Ranjangaon, the things that need watching are switches, uninterruptible power supplies, environmental sensors, historian servers and Windows hosts running plant applications — devices that speak SNMP and little else, sit on segmented networks with no outbound path, and cannot host a modern agent even if someone wanted to install one. A check-and-notify engine that runs a plugin locally, understands parent and child dependencies so a failed uplink does not generate ninety separate alerts, and escalates against a shift roster is genuinely the right tool for that estate, and a pull-based metrics system is not a drop-in replacement.
The second Pune population is the shared-services operations floor. Captive and outsourced teams in Hinjewadi, Kharadi, Talawade and Magarpatta inherited large Nagios Core or XI installations along with the contracts they support, and the work is keeping them honest: custom plugins in Bash and Python, NRPE against NCPA, passive checks for hosts behind a firewall, flap detection, scheduled downtime tied to a customer's change window rather than a local calendar, and getting alerts into a ticketing tool instead of a mailbox nobody reads. Pune postings that mention Nagios almost always pair it with SNMP, Linux administration and an ITSM platform, and increasingly with a coexistence or migration brief toward a metrics-based stack — which is the honest conversation these batches are built to end on.
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.