Private corporate batches, live online cohorts and 1-on-1 mentoring in metric-centric monitoring at estate scale — templates, trigger expressions, low-level discovery and proxies — 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 Zabbix around the two things that decide whether a deployment scales: templates and trigger expressions. Sessions cover item types across agent passive and active checks, SNMP, IPMI, JMX, ODBC, HTTP agent and external scripts, then calculated and dependent items, macros and context macros, and low-level discovery with item, trigger and graph prototypes so that hosts configure themselves. Trigger work is taught as expression design — function selection, time windows, hysteresis, dependencies and severity — because alert quality is where most deployments fail. The operational half covers actions and multi-step escalations, maintenance windows and remote commands, permissions by user and host group, proxy topology for distributed and DMZ collection, database sizing and housekeeping, backup, upgrades and the API, all against a running server.
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 Zabbix that means a trainer who has run it in production — metric-centric monitoring at estate scale — templates, trigger expressions, low-level discovery and proxies — 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 Zabbix batchZabbix is an open-source monitoring system for servers, networks, applications, databases, cloud services and everything else with an address. What distinguishes it from check-and-alert tools in the Nagios lineage is that Zabbix is metric-centric rather than state-centric: every monitored host has items, each item collects a value on its own interval, and every value is written to the Zabbix database as history and then aggregated into trends. A problem is not the exit code of a script — it is a trigger expression evaluated over that stored data, using functions such as last, avg, min, max, change, nodata and forecast.
Collection is deliberately broad because real estates are not homogeneous. The Zabbix agent works in passive mode, where the server polls it, and in active mode, where the agent opens the connection outward — which is what makes monitoring through firewalls and NAT practical. Beyond the agent there is SNMP v1, v2c and v3 with trap handling, IPMI for out-of-band hardware, JMX through the Java gateway, ODBC for databases, HTTP agent items for REST endpoints, external scripts, and script items. Calculated and dependent items derive new values from collected ones without touching the host at all.
The scale story is templates and discovery. A template carries items, triggers, graphs, dashboards, discovery rules and macros, and links to hosts, so configuration effort is spent per class of host rather than per host. Low-level discovery goes further: a discovery rule returns a JSON list, and item, trigger and graph prototypes are instantiated automatically for every filesystem, network interface, service, database or container found. Around that sit events and actions with multi-step escalations, media types for email, webhooks and scripts, maintenance windows, remote commands for automatic recovery, auto-registration for onboarding, permissions by user and host group, proxies for distributed collection, and an API that does everything the frontend can.
Infrastructure monitoring did not disappear when Prometheus arrived; it moved out of fashion while remaining load-bearing. The estates that actually need it — network gear, storage arrays, hypervisors, Windows servers, appliances, IPMI-managed hardware, databases and the long tail of things that will never expose a metrics endpoint — are not Kubernetes-shaped, and a pull-based, label-oriented, short-retention time-series system is a poor fit for them. Zabbix covers that entire surface in one product with no per-node licence.
Cost is the second driver. Organisations re-examining a six- or seven-figure commercial monitoring renewal look hard at what they would lose by moving to Zabbix, and the honest answer is usually less than expected — provided they have engineers who can template properly. That proviso is the whole point. A Zabbix deployment configured host by host through the frontend becomes unmaintainable at a few hundred hosts; the same deployment built on templates, macros and low-level discovery scales to tens of thousands and is largely self-configuring as infrastructure changes.
So the demand is specifically for depth. Writing a trigger expression that fires once on a real problem rather than fifty times on a transient spike, sizing a database and its housekeeping for a stated retention, designing proxy topology across sites, and building templates other teams can reuse — those are the skills organisations hire for, and they are not learned by clicking through the interface.
The model before the interface. Why a metric-centric system behaves differently from a check-centric one, then Zabbix's own architecture: server, database, frontend, agent, proxy and Java gateway, the poller and preprocessing pipeline, and where each component becomes a bottleneck. An honest comparison against Nagios, Icinga, Prometheus and commercial platforms.
Topics: A short history of Zabbix and its release model · Metric-centric monitoring versus check-and-state monitoring · Architecture: server, database, frontend, agent, proxy, Java gateway · The path of a value: collection, preprocessing, storage, trigger evaluation · Pollers, trappers, preprocessing workers and the value cache · Zabbix compared with Nagios, Icinga, Prometheus and commercial platforms · Where Zabbix is the wrong tool · Sizing the components for a stated host and item count
A working server you can build again from documentation. Installing the server, frontend and agent from packages and containers, the database choice including TimescaleDB, the configuration files that matter, and the initial setup work — administration settings, housekeeping, time zones and the first host.
Topics: Installing the server, frontend and agent from packages and containers · Database selection: MySQL, PostgreSQL and TimescaleDB · zabbix_server.conf and zabbix_agentd.conf: the settings that matter · Frontend configuration, PHP requirements and reverse proxy · TLS between agent, proxy and server · First login, administration settings and time zone handling · Adding a first host and interface · Verifying collection and reading the server log · Upgrading the agent to Zabbix agent 2 and what changes
The vocabulary everything else uses. Hosts, host groups, interfaces, items, triggers, events, problems, actions, templates, macros and value maps — with precise definitions, because most Zabbix confusion is terminology confusion. Then a working tour of the frontend so attendees can find anything.
Topics: Hosts, host groups, host interfaces and host inventory · Items, item keys, value types and units · Triggers, events, problems and their relationship · Templates, linkage and inheritance · Macros: global, template, host and user macros, and macro context · Value maps, units and preprocessing at a glance · Frontend navigation: Monitoring, Data collection, Alerts, Reports, Administration · Filters, saved filters and the problem view · Permissions preview: what a non-admin user actually sees
The most common collection path, in depth. Passive versus active checks and why active mode solves firewall and NAT problems, the built-in agent item keys, user parameters for anything not built in, item preprocessing, and the update-interval and scheduling behaviour that determines load.
Topics: Passive checks: server polls agent · Active checks: agent connects to server, and the active check refresh · Built-in agent keys for CPU, memory, disk, network, processes and services · Windows-specific keys, performance counters and services · User parameters and flexible user parameters · Zabbix agent 2 plugins · Item preprocessing: regex, JSONPath, XPath, change per second, throttling, JavaScript · Update intervals, flexible intervals and scheduling intervals · Log file monitoring, log rotation handling and log item keys · Unsupported items: causes and diagnosis · zabbix_get for testing a check from the command line
Everything you cannot install an agent on. SNMP for network and appliance monitoring including v3 authentication and trap handling, IPMI for hardware out of band, JMX through the Java gateway, ODBC for database metrics, HTTP agent items for REST APIs, and simple checks. Then calculated, dependent and aggregate items that derive values with no collection at all.
Topics: SNMP v1, v2c and v3: OIDs, MIBs, walking a device and dynamic indexes · SNMP traps and the trap receiver · SNMP bulk requests and polling efficiency · IPMI monitoring for out-of-band hardware health · JMX monitoring through the Java gateway · ODBC items for database metrics · HTTP agent items for REST endpoints, including headers and authentication · Simple checks: ICMP ping, port checks and service availability · External checks and script items · Calculated items and their expression syntax · Dependent items and master-item preprocessing chains · Aggregate calculations across host groups
The single decision that determines whether a Zabbix deployment survives growth. Template design and linkage, nested templates, macros as the parameterisation mechanism, overriding at host level, and the discipline that keeps a template library reusable. Then host inventory, populated manually and automatically.
Topics: Template structure: items, triggers, graphs, dashboards, discovery rules, macros · Linking, unlinking and unlinking-and-clearing · Nested templates and template composition · Macros as template parameters, and macro precedence · Overriding thresholds per host without editing the template · Official templates: what to reuse and what to rewrite · Template versioning and change management · Host inventory: manual, automatic and inventory-linked items · Using inventory fields in filters and actions · Exporting and importing templates as YAML, XML or JSON
Where alert quality is decided. Trigger expression syntax and its function library, choosing a time window that reflects the failure, hysteresis and recovery expressions to stop flapping, dependencies so one root cause does not produce fifty alerts, severity as a real classification, and the event lifecycle through acknowledgement and closure.
Topics: Trigger expression syntax and operators · Function library: last, avg, min, max, count, change, nodata, forecast, timeleft · Choosing evaluation windows that match the failure mode · Recovery expressions and hysteresis · Trigger dependencies and root-cause suppression · Severity levels and using them consistently · Manual close, acknowledgement and problem suppression · Event correlation: global and trigger-level · The event lifecycle: PROBLEM, acknowledged, suppressed, RESOLVED · Diagnosing a trigger that never fires, or fires constantly · Baselines and anomaly-style triggers with trend functions
Turning collected data into something a human uses. Simple and custom graphs, aggregated views, dashboards and widgets, network maps built from real topology, geographical maps, slide shows for wall displays, scheduled reports, and the Grafana integration for teams that already standardised there.
Topics: Simple graphs, custom graphs and graph prototypes · Dashboards and widgets, including host and problem widgets · Dashboard templating and host-level dashboards · Network maps: elements, links, link indicators and automatic status · Map hierarchies and drill-down · Geographical maps and location-based views · Slide shows and wall-display considerations · Scheduled PDF reports and their delivery · Top hosts, aggregated and overview widgets · The Grafana Zabbix data source and when to use it · Data export for external analysis
Getting the right message to the right person, once. Actions with conditions and operations, multi-step escalations with delays and repeat counts, media types including webhooks to chat and incident tools, message templates and the macro vocabulary available in them, then remote commands that let Zabbix repair a problem before anyone is paged.
Topics: Actions: conditions, condition types and calculation · Operations, recovery operations and update operations · Escalation steps, delays, repeat counts and cancelling escalation · Media types: email, SMS, script and webhook · Webhook media types with JavaScript, and integrating chat or incident tools · Message templates and the macro vocabulary · User media, severity filtering and time period restrictions · Remote commands for automatic recovery, and their risks · Running commands on the agent, the server or a proxy · Maintenance windows at host and host-group level, with and without data collection · Suppression, and why suppressed is not the same as acknowledged · Auditing what was sent, to whom, and whether it was delivered
Configuration that maintains itself. Network discovery for finding hosts, active-agent auto-registration for hosts that announce themselves, and low-level discovery for everything inside a host — filesystems, interfaces, services, databases, containers — with prototypes, filters and overrides. Then web scenario monitoring for end-user transactions.
Topics: Network discovery rules, checks and discovery actions · Active agent auto-registration and registration actions · Automatically assigning templates, groups and macros on registration · Low-level discovery: the JSON contract and discovery keys · Built-in discovery for filesystems, interfaces, services and processes · Item, trigger, graph and host prototypes · LLD macros, filters and regular expressions · LLD overrides for exceptions to a prototype · Custom discovery from a script or HTTP source · Lost resources: keep-lost period and cleanup · Web monitoring: scenarios, steps, variables and authentication · Monitoring a login journey as a transaction
Running Zabbix for an organisation rather than for its administrator. User roles and their granular permissions, user groups and host-group permissions, frontend access restrictions, authentication against LDAP or SAML, the audit log, and the administration settings that quietly determine behaviour — working time, housekeeping, and frontend scripts.
Topics: Users, user groups and user roles · Permission model: read, read-write and deny across host groups · Role-based UI element and API method restrictions · Internal, LDAP, Active Directory and SAML authentication · Multi-factor authentication and session settings · The audit log and what it captures · Working time and its effect on graphs and reports · Housekeeping settings and their performance impact · Global macros and global regular expressions · Frontend scripts and manual host actions · Value maps, icon maps and administration housekeeping · Delegating configuration to application teams safely
Everything that keeps a large deployment healthy for years. Proxies for distributed, DMZ and high-latency collection with buffering; database sizing, partitioning and housekeeping; backup and restore; upgrade path and version policy; the API and configuration as code; command-line utilities; and business-level reporting with IT services and SLA.
Topics: Proxy architecture: active and passive proxies, buffering and failover · When a proxy is required, and how many · Zabbix high availability for the server · Database sizing: history, trends and events growth · Partitioning, TimescaleDB compression and housekeeping strategy · Performance tuning: cache sizes, pollers, preprocessing workers, queue analysis · Reading the Zabbix queue and diagnosing collection delay · Backup procedures for database and configuration · Upgrades, LTS releases and the development and release policy · Configuration export and import in YAML, XML and JSON · The Zabbix API: authentication, objects and configuration as code · Command-line utilities: zabbix_get and zabbix_sender · Sending data from applications and CI with zabbix_sender · IT services, SLA definition and business-level reporting
We rebuild the agenda around the tools you actually run.
Request a custom agendaBring a network device, an IPMI-managed server, a database and a REST API into monitoring using SNMPv3, IPMI, ODBC and HTTP agent items — with no agent installed anywhere.
Convert a hand-built host into a template driven by macros, then apply it across dev, staging and production with different thresholds and no template edits.
Take a genuinely noisy trigger set, rebuild it with correct evaluation windows, hysteresis and dependencies, and demonstrate a single alert for a single root cause.
Configure active-agent auto-registration with automatic templating, then add a custom low-level discovery rule so new filesystems and services appear without human action.
Build an action that runs a remote recovery command, waits, and only escalates to a human if the problem persists — then prove both paths.
Deliver a proxy topology, template library, discovery-driven onboarding, delegated permissions, escalation policy, dashboards, database sizing and an upgrade 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.
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.