Private corporate batches, live online cohorts and 1-on-1 mentoring in centralised log management — inputs, extractors, processing pipelines, streams, alerts and index lifecycle — 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 Graylog as an operator: the full path a message takes from an input, through extractors and pipeline stages, into a stream and an index set with its own retention and permissions — because that path is where every real design decision lives. Sessions cover installation and cluster architecture across Graylog, OpenSearch or Elasticsearch and MongoDB; ingestion with GELF, Syslog, Beats and Sidecar-managed collectors; pipeline rules for parsing, blacklisting, normalising and enriching with lookup tables and geolocation; streams for routing and access control; search, aggregation and dashboards; event definitions and notifications; and the operations most deployments only learn under pressure — indexer failures, index rotation and retention, sizing, scaling out, and securing an installation that carries regulated data.
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 Graylog that means a trainer who has run it in production — centralised log management — inputs, extractors, processing pipelines, streams, alerts and index lifecycle — 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 Graylog batchGraylog is a centralised log management platform: it receives log messages from across an estate, parses and enriches them, routes them into streams, indexes them for search, and raises alerts when something matches. It is a complete application rather than a library — a server that owns the ingestion and processing path, a web interface for search, dashboards and administration, an OpenSearch or Elasticsearch cluster holding the indexed messages, and MongoDB storing the configuration and metadata.
The processing chain is what distinguishes it from simply pointing an agent at a search index. Messages arrive through inputs — GELF, Syslog, Beats, raw TCP or UDP, or the Graylog Sidecar managing collectors on remote hosts. Extractors and processing pipelines then transform them: pipeline rules run in ordered stages, parsing unstructured text, dropping noise, normalising field names, enriching from lookup tables and geolocation databases, and routing messages into streams. Streams are the central routing abstraction — a stream is a live subset of messages matching rules, and it carries its own permissions, its own alerts, and optionally its own index set with its own retention.
That combination is why Graylog is often chosen for security and compliance work as much as for operations. Access is controlled per stream through users and roles, retention is set per index set so audit data can be kept for years while debug logs expire in days, and alerting is expressed as event definitions with notifications. Around the core sit dashboards and widgets, the search syntax and aggregation views, plugins and the Graylog Marketplace for extensions, and an architecture that scales by adding Graylog nodes in front of an appropriately sized search cluster.
Logs remain the signal engineers reach for first, and they are the one most estates have least control over. Volume grows with every service, the useful lines are buried in noise nobody has filtered, and retention is usually set by whoever ran out of disk first. Centralised log management is not optional at any real scale — the only question is what runs it.
Graylog occupies a specific position: an open-core platform you operate yourself, with the parsing, routing, role-based access and retention controls that compliance work demands, without per-gigabyte pricing that makes retention a budget conversation. That combination keeps it in demand across regulated industries, managed service providers and organisations that will not send logs to a hosted vendor.
And it rewards operators over users. Getting messages into Graylog is easy. Writing pipeline rules that parse a decade of inconsistent log formats, designing streams and index sets so retention and permissions match the actual compliance requirement, sizing an OpenSearch cluster against real daily volume, keeping index rotation from silently failing, and building alerts specific enough to act on — that is the work, and it is where an unmanaged deployment quietly becomes a very expensive search engine full of noise.
The problem before the product, then how Graylog is put together. Why centralised logging exists, the three moving parts and what each is responsible for, architectural considerations for single-node and clustered deployments, and an honest comparison with the other options in this space.
Topics: Centralised log management: what it solves and what it costs · Introduction to Graylog and the message lifecycle · Architecture: Graylog server, OpenSearch or Elasticsearch, MongoDB · Architectural considerations for single-node, multi-node and multi-site · Sizing: daily volume, retention, indexing rate and node count · Journal, buffers and what happens when the indexer falls behind · Graylog compared with other log platforms, open source and commercial · Where a self-operated log platform is the wrong choice
Standing it up properly. Choosing an installation method, installing and configuring each component, the settings in server.conf that matter, securing the installation with TLS and authentication, and the upgrade path — including the parts of an upgrade that break if index sets and plugins are ignored.
Topics: Choosing an installation method: packages, containers, virtual appliance · Installing Graylog, OpenSearch or Elasticsearch, and MongoDB · Getting started: first login, initial configuration and health checks · Configuring Graylog: server.conf, journal settings, buffers and processors · Securing Graylog: TLS, password secrets, and hardening the interface · Authentication: local users, LDAP and Active Directory integration · Upgrading Graylog and the search backend safely · Backup of configuration, MongoDB and index data · Verifying a healthy installation before any load is applied
Inputs and collection, which is where volume and quality are both decided. GELF and Syslog, Beats inputs, raw TCP and UDP, HTTP intake, and the Graylog Sidecar for managing collector configuration centrally across a fleet — plus what to do about sources that will only emit a format nobody designed.
Topics: Inputs: creation, binding, global versus node-local · GELF: structure, transports and why it avoids Syslog's limits · Syslog inputs and handling non-compliant Syslog senders · Beats inputs: Filebeat, Winlogbeat and Metricbeat · Raw TCP, UDP and HTTP inputs · The Graylog Sidecar: managing remote collector configuration centrally · Migrating from the deprecated Graylog Collector · Collecting from containers and Kubernetes · Sending application logs directly with GELF libraries · Input troubleshooting: nothing arriving, partial messages, encoding problems
Turning raw text into structured, queryable events. Extractors for straightforward field extraction, then processing pipelines properly — rules, stages, ordering and the message processor chain — plus enrichment with lookup tables and geolocation, blacklisting, and normalising field names across sources that will never agree.
Topics: Extractors: types, creation and where they stop being sufficient · Processing pipelines: rules, stages, connections and evaluation order · The pipeline rule language and its functions · Parsing with grok, regex, JSON and key-value functions · Normalising field names across inconsistent sources · Lookup tables and data adapters for enrichment · Geolocation of IP addresses · Blacklisting and dropping messages before indexing · Message rewriting and the legacy Drools-based approach · The message processor order and why it changes results · Testing and debugging pipeline rules against real messages
The routing and lifecycle layer, and the one most deployments underuse. Streams as live routed subsets of messages, stream rules and their evaluation, attaching a stream to its own index set, and using index sets to give different data different retention, sharding and permissions.
Topics: Streams: what they are and how routing actually works · Stream rules, matching and the effect on processing cost · Assigning a stream to its own index set · Index sets: shards, replicas, rotation strategy and retention strategy · Retention by time, size or index count, and choosing between them · Separating audit, security and debug data by retention requirement · Stream permissions and per-stream access control · Stream-based alerting and dashboards · Index aliases, the write index and how rotation works internally
The daily skill. Search syntax and the operators that matter, scoping searches by stream and time, building aggregations and views, saved searches for recurring investigations, and the field analysis techniques that turn a wall of messages into a distribution you can reason about.
Topics: Search syntax: terms, phrases, wildcards, ranges and boolean logic · Scoping by stream, time range and relative windows · Field analysis, value distributions and quick statistics · Aggregations: grouping, metrics and building a view · Saved searches and reusable investigation starting points · Search performance: what makes a query slow across large index sets · Exporting results and using the search API · Investigating an incident: a repeatable search workflow · Common search mistakes that return convincing but wrong answers
Making the platform tell you things rather than waiting to be asked. Dashboards and the widget library, designing a dashboard around one question, then event definitions and alert conditions — aggregation-based, correlation-based and filter-based — with notifications routed to the systems people actually watch.
Topics: Dashboards: creating, organising and sharing · Enhancing dashboards and adding widgets · Widget types and choosing one that answers a question · Parameterised dashboards and reusable views · Event definitions: filter, aggregation and correlation conditions · Alert conditions, thresholds and evaluation windows · Notifications: email, HTTP, script and integration endpoints · Reducing alert noise: grouping, backlog and repeat-notification control · Alerts for security and compliance events versus operational events · External dashboards and embedding Graylog data elsewhere
Keeping it healthy under real load. Scaling out Graylog nodes and the search cluster, building resilient multi-node environments, diagnosing indexer failures and journal growth, managing users and roles, and extending the platform with plugins from the Marketplace or your own.
Topics: Scaling and building resilient environments · Adding Graylog nodes, load balancing inputs and the API · Scaling the OpenSearch or Elasticsearch cluster behind Graylog · Indexer failures: causes, diagnosis and recovery · Journal growth, buffer saturation and processing backpressure · Monitoring Graylog itself: node metrics, throughput and cluster health · Users, roles, teams and permission design at organisation scale · Plugins: installing, managing and the Graylog Marketplace · Writing or adapting a plugin when nothing existing fits · Disaster recovery: what to back up and how to prove a restore works
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy Graylog Sidecar to several hosts, manage collector configuration centrally, and bring in GELF, Syslog and Beats sources side by side.
Write pipeline rules that parse three inconsistent log formats into a single normalised field schema, enrich with a lookup table, and drop the noise.
Route audit, security and debug logs into separate streams with their own index sets, retention strategies and per-team permissions.
Work a seeded incident using search syntax, field analysis and aggregations, then turn the investigation into a saved search and a view.
Build aggregation and correlation event definitions, validate them against historical data, and route notifications without creating a repeat-alert storm.
Run a multi-node deployment under load, trigger and recover an indexer failure, drain the journal, and produce the runbook and tested restore.
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.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
| 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.