Splunk: search, fields & evidence
Turn events into an explainable operational view with SPL.
GUIDE3 published lessons · Updated 2026-09-14
Before you begin
Use a local or authorized training Splunk environment with Search access. These first searches generate synthetic events, so no uploaded operational logs are needed. Start searches with the leading pipe shown.
Working toward: Build a dashboard whose counts, time bounds, fields and alerts can be explained and tested.
Read each explanation, work through the example, and attempt the exercise before opening its answer. Published lessons are ready to study; unfinished roadmap topics remain planned.
Validation: Based on upstream documentation. Platform-specific labs require the learner’s matching environment and are not execution-tested here.
1. An event is a record
SPL pipelines transform events step by step. makeresults creates a synthetic event; eval adds fields; table chooses visible columns. No index search occurs in this example.
| makeresults
| eval host="lab-01", status="ok", latency_ms=42
| table host status latency_msWhat to expect
One row: lab-01, ok, 42.
Your turn
Change status to degraded and latency_ms to 250. Does this modify a server?
Show answer and reasoning
No. You changed a generated search result, not a monitored machine. SPL output needs an understood data source.Watch for: A convincing dashboard is not evidence of real collection if its source is synthetic.
Link to this lesson2. Count a controlled fixture
A useful search can be checked against data with a known answer. split creates a multivalue field and mvexpand creates separate rows. stats count then aggregates those rows.
| makeresults
| eval status=split("ok,ok,error", ",")
| mvexpand status
| stats count BY statusWhat to expect
Two rows: error has count 1 and ok has count 2; ordering may differ.
Your turn
Add another error to the fixture and predict the counts before running it.
Show answer and reasoning
Use "ok,ok,error,error". Both groups have count 2. The total number of expanded events is four.Watch for: Aggregations can hide duplicate ingestion or missing events. Check the input count and data boundaries.
Link to this lesson3. Turn a count into a proportion
A percentage needs a denominator. Compute totals deliberately and protect against division by zero. Here the fixture represents six requests, two failed.
| makeresults
| eval requests=6, failures=2
| eval failure_percent=if(requests>0, round(100*failures/requests, 1), null())
| table requests failures failure_percentWhat to expect
6 requests, 2 failures, 33.3 percent.
Your turn
Why should an alert also consider sample size and time window?
Show answer and reasoning
One failure out of one request and one thousand failures out of one thousand requests both give 100%, but imply different volumes. Define the window, minimum count and operational action.Watch for: A zero denominator is not a healthy 0% failure rate; it may indicate no traffic or broken collection.
Link to this lessonPath to advanced
In-progress stages identify the lessons already published. All other listed topics remain planned. Each addition needs teaching, a reproducible lab, failure cases, and a checkpoint before the capstone.
Search real fixtures
Event time, source types, fields, time windows and ingestion boundaries.
PLANNEDBuild views
SPL transformations, dashboards, alert conditions and false-positive review.
PLANNEDOperate collection
Forwarders, indexing, retention, permissions and ingestion health.
PLANNED
References
Original AUWEN lessons, with upstream documentation for further study and version checks.
All learning paths and update notes →