Splunk Architecture & Components
Indexers, search heads, forwarders, deployment server, license master
Learning Objectives
- ›Identify every component of a Splunk deployment
- ›Understand the data pipeline: input → parsing → indexing → search
- ›Differentiate Universal Forwarder vs Heavy Forwarder
- ›Plan a clustered deployment
Module 1 — Core Components
Indexer — stores events; performs search-side work in distributed search.
Search Head — runs SPL, renders dashboards, hosts apps. Clusters for HA.
Forwarder — collects logs from sources. Universal (light, parse-less) vs Heavy (parse-capable).
Deployment Server — pushes apps/configs to forwarders.
Cluster Master / License Master / Monitoring Console — operational glue.
Module 2 — Data Pipeline
Input → Parsing (line-break, timestamp, source/sourcetype/host) → Merging → Indexing → Search.
props.conf and transforms.conf control parsing — the analyst's superpower.
Module 3 — Indexes & Buckets
Index = directory of buckets. Buckets: hot → warm → cold → frozen.
Retention defined by maxDataSize and frozenTimePeriodInSecs in indexes.conf.
Module 4 — Distributed Search
Search head fans out to all indexers; each runs the search on its slice; results merged on SH.
Accelerated data models (CIM) materialize tstats summaries for 10-100× speedups.
Module 5 — Sizing & HA
Rule of thumb: 1 indexer per 100-300 GB/day ingest with 30% headroom.
Indexer Cluster = replication for resilience. Search Head Cluster = active/active for users.
Lab 8 — Architect a Splunk Deployment
- Plan a deployment for 500 GB/day ingest.
- Size indexers, search heads, forwarders.
- Decide: Indexer Cluster yes/no? Search Head Cluster yes/no?
- Document on which components Splunk ES would run.
Key Takeaways
- ✓Pipeline: input → parse → index → search
- ✓props/transforms is where parsing lives
- ✓Distributed search + accelerated DMs = speed