Private corporate batches, live online cohorts and 1-on-1 mentoring in pull-based metrics collection, PromQL and alerting for cloud-native infrastructure — 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 Prometheus around its data model rather than its dashboards — how counters, gauges and histograms differ in what queries they permit, why rate() must wrap a counter before aggregation, and how label cardinality decides whether a server survives. Sessions cover the operational half most courses skip: relabelling in service discovery, recording rules for expensive queries, Alertmanager routing with grouping, inhibition and silences, TLS and mutual TLS between server and targets, and what to do when local storage is no longer the right answer.
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 Prometheus that means a trainer who has run it in production — pull-based metrics collection, PromQL and alerting for cloud-native infrastructure — 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 Prometheus batchPrometheus is an open-source monitoring system and time-series database built around a pull model. Rather than having applications ship metrics to a collector, a Prometheus server scrapes HTTP endpoints on a schedule, parses a plain-text exposition format, and stores each sample locally in its own TSDB. That inversion is deliberate: the monitoring system decides what it watches and how often, so a target that stops responding is itself a signal rather than silence.
The data model is what everything else is built on. A time series is identified by a metric name plus a set of key-value labels, and every query in PromQL selects series by matching on those labels. Counters, gauges, histograms and summaries are the four metric types, and the difference between them decides which functions are legal — rate() over a counter, quantiles over a histogram, and the aggregation operators that collapse label dimensions. Getting label cardinality right is the difference between a Prometheus that runs on one node and one that falls over.
Around the server sits the rest of the stack: exporters that translate existing systems into the exposition format, client libraries for instrumenting your own code, service discovery against Kubernetes, EC2, Consul and file-based sources with relabelling to shape what gets scraped, recording rules for expensive queries, and Alertmanager for routing, grouping, inhibition and silences. Prometheus is intentionally not a clustered long-term store; remote write and federation exist precisely because that boundary is drawn on purpose.
Metrics stopped being an operations afterthought when systems became too dynamic to watch by hand. Containers come and go in minutes, autoscaling groups replace hosts continuously, and any monitoring model that assumes a fixed inventory of named machines fails on contact with that reality. Prometheus was designed for exactly this: targets are discovered, not enumerated, and series are identified by labels rather than by hostname.
Its position is also structural. Prometheus is the graduated CNCF project that the Kubernetes ecosystem standardised on, which means the exposition format has become the de facto interface for metrics across the cloud-native stack — kubelet, node exporter, Envoy, etcd, Istio and thousands of third-party services all speak it. OpenTelemetry interoperates with it rather than replacing it.
What organisations hire for is the second half of the skill. Standing up a server and scraping node exporter is a morning's work. Writing PromQL that answers a real production question, designing labels that do not explode cardinality, building alerts that fire on symptoms rather than causes, and running the storage and retention story at scale — that is the part that takes deliberate practice.
What monitoring is actually for, and the vocabulary that makes the rest of the course coherent. White-box versus black-box signals, the four golden signals, SLIs and SLOs, and where Prometheus sits against Nagios-style check systems and hosted APM platforms — including the workloads where it is the wrong tool.
Topics: Introduction to monitoring: what a signal is and what it is for · White-box vs black-box monitoring · The four golden signals; SLIs, SLOs and error budgets · Push vs pull collection models · Prometheus architecture: server, exporters, Alertmanager, Pushgateway · Where Prometheus is the wrong answer — logs, traces, long-term analytics
Getting a real server running and understanding every line of its configuration. Binary and container installation, prometheus.yml structure, global settings, scrape jobs and intervals, the expression browser and targets page, and reloading configuration without dropping data.
Topics: Installing Prometheus from binary, package and container · prometheus.yml: global, scrape_configs, rule_files, alerting · scrape_interval, scrape_timeout, evaluation_interval · Running Prometheus as a systemd service · The expression browser, /targets and /service-discovery pages · Hot reload via SIGHUP and the lifecycle API · Installing Grafana alongside and wiring it to Prometheus
The core abstraction: a time series is a metric name plus a label set. The four metric types and what each one legitimately supports, how the text exposition format is structured, and why cardinality is the single most important design constraint in a Prometheus deployment.
Topics: Metric names, labels and the identity of a time series · Counter, gauge, histogram and summary — and when each is correct · The text exposition format: HELP, TYPE, samples · Buckets, quantiles and the histogram/summary trade-off · Label cardinality: budgets, offenders and how to measure yours · Naming conventions and base units · Staleness handling and the lookback delta
Adding metrics to software you own. Client library patterns across Go, Python and Java, registering collectors, choosing metric types deliberately, instrumenting request paths, and the pitfalls of instrumenting inside hot loops. Then Pushgateway — what it is for, and the far more common case where it is misused.
Topics: Client libraries: Go, Python, Java, Node · Registries, collectors and the default metrics · Instrumenting HTTP handlers, latency histograms and error counters · Custom collectors for state you cannot count directly · Multiprocess and forked-worker instrumentation · Pushing metrics: Pushgateway and its correct use case · Batch job monitoring patterns
The query language, taught properly rather than by copying snippets. Instant and range vectors, selectors and matchers, the rate family, aggregation over labels, binary operators and vector matching, functions, and the subquery and offset modifiers that answer comparative questions.
Topics: Instant vectors, range vectors and scalars · Label matchers, regex matching and metric selection · rate, irate, increase and the counter-reset problem · Aggregation operators: sum, avg, max, topk, count and by/without · Binary operators and vector matching: on, ignoring, group_left, group_right · histogram_quantile and latency percentiles · offset, @ modifier and subqueries · predict_linear, absent and alert-shaped expressions
How Prometheus finds what to scrape in an environment where hosts are ephemeral. Static configs, file-based discovery, and the cloud and orchestrator discoveries — Kubernetes, EC2, Consul, DNS. Then relabel_configs, which is where most real Prometheus configuration complexity lives.
Topics: static_configs and file_sd for the simple cases · Kubernetes service discovery: node, pod, endpoints, service, ingress roles · EC2 auto-discovery and instance tagging · Consul integration and service catalogues · DNS and Docker Swarm discovery · relabel_configs: replace, keep, drop, labelmap, hashmod · metric_relabel_configs for dropping expensive series at ingest · Sharding scrapes across servers with hashmod
Monitoring systems you cannot instrument. The exporter pattern, the exporters worth knowing in depth, and how to write one when nothing exists. Blackbox probing for endpoints you only see from outside, and the CloudWatch exporter for AWS services with no scrape endpoint of their own.
Topics: The exporter pattern and its contract · node_exporter: collectors, textfile collector, tuning what is enabled · blackbox_exporter: HTTP, TCP, ICMP and DNS probes with the multi-target pattern · Database and middleware exporters: MySQL, Postgres, Redis, JMX · CloudWatch exporter for AWS-managed services · SNMP exporter for network devices · Writing a custom exporter
Turning queries into pages people trust. Recording rules and why they exist, alerting rules and the for-clause, then Alertmanager as a separate system: the routing tree, grouping, inhibition, silences, receivers and templates. The theme throughout is alerting on symptoms rather than causes.
Topics: Introduction to alerting: symptoms vs causes, and alert fatigue · Recording rules: naming conventions and when to precompute · Alerting rules, the for clause, labels and annotations · Alertmanager configuration: route trees, matchers, continue · Grouping, group_wait, group_interval and repeat_interval · Inhibition rules and silences · Receivers: email, Slack, PagerDuty, webhook · Notification templating · Alertmanager high availability with gossip
What Prometheus is doing on disk, and what to do when one server is no longer enough. The TSDB: head block, WAL, block compaction, retention. Then the scaling options and their honest trade-offs — federation, remote write, and the long-term storage projects built on top.
Topics: TSDB internals: head block, WAL, chunks and compaction · Retention by time and by size; disk sizing arithmetic · Memory usage and the relationship to active series · Federation: hierarchical and cross-service · remote_write and remote_read: protocol, queue tuning, backpressure · Long-term storage options: Thanos, Cortex, Mimir — what each solves · Backups, snapshots and the admin API · Capacity planning and performance troubleshooting
Locking down the scrape path and then putting the whole stack to work. TLS and authentication on the server, mutual TLS to targets, and reverse-proxy patterns. Then the visualisation layer with Grafana provisioning, and complete worked scenarios: monitoring a web application, calculating an Apdex score, and reporting on SLO burn.
Topics: TLS and basic authentication on the Prometheus server · Mutual TLS between server and scrape targets · Reverse proxy and authenticating proxy patterns · Grafana data source configuration and dashboard provisioning as code · Monitoring a web application end to end · Calculating an Apdex score in PromQL · SLO and error-budget burn-rate alerting · Prometheus Operator and ServiceMonitor on Kubernetes
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a server whose memory is climbing, identify the offending metrics and label dimensions, then cut the series count with metric_relabel_configs without losing the signal.
Answer ten real operational questions against live data — error rates, p99 latency, saturation, week-over-week comparison — using rate, aggregation, vector matching and subqueries.
Configure EC2 and Kubernetes service discovery, then use relabel_configs to keep only the right targets and attach correct environment and team labels automatically.
Write symptom-based alerting rules, route them through Alertmanager with grouping and inhibition, then deliberately trigger a cascading failure and observe how many pages fire.
Bring a database, a network device and three external endpoints under monitoring using node, SNMP and blackbox exporters, including certificate expiry alerting.
Take one application from zero monitoring to a secured, discovered, instrumented service with provisioned Grafana dashboards and SLO burn-rate alerts.
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.