0.1 What SPL Is and Where It Runs

Introduction

SPL, the Search Processing Language, is how you ask Splunk questions about the data it holds: which accounts failed to sign in, which machine talked to which address, what a compromised account did next. A search starts with a base search that says which events to read, and continues with commands joined by pipes, each doing one thing to what the step before it produced.

The answer is either the events themselves or a table built from them. This module orients you before the course begins, and this first section shows what the language is, how a search is put together, and where it runs.

You will look at three sign-in events, turn a question into a four-part search, run SPL that reads no events at all, count a month of sign-ins and its failures, and see a field name in the wrong case find nothing. By the end you should be able to read the shape of any SPL search, say what each part does, and run your first searches in the lab.

The diagram is the whole idea of the language: a question becomes a search, and the search becomes an answer. The places in the bottom row all run the same language, so a search written in the search bar can become a report, an alert, a dashboard panel or a detection without being rewritten.

The source for the card is Splunk's Search Manual. Wherever this course states how Splunk behaves, it names the page and the date it was read, so a statement can be rechecked against a later release.

The card's last line is the one most people learn the hard way. Splunk is forgiving about the case of almost everything a search contains, and strict about one thing, the names of fields, which is why a search that looks right can match nothing.

The card names the parts of a search, from the base search to the case rule. Every search in this course is made from them, and the rest of this section shows each one at work on the sample month's sign-ins.

Splunk stores events: one record for each thing that happened anywhere it collects data from, in time order, a sign-in, a connection, a process starting. A search's first job is to say which events to read.

index=azuread category=SignInLogs
| head 3
| table _time user src_ip action

The _time field is the event's timestamp, which Splunk keeps for every event and shows here in the lab's format. The other three fields come from the sign-in itself.

The second sign-in's account ends in #EXT#@ne.com, the form Entra ID gives a guest from another organization. Account names like this are common in sign-in data and come up again in Module 6, where the course takes text fields apart.

head 3 kept the first three events the search returned. Splunk returns events newest first by default, so a head on raw events shows the most recent ones, here from the last minutes of the month.

Three sign-ins, the newest first, each with a time, an account, an address and an outcome. table chose which fields to show; the events have many more, as Section 0.2 will show. Every source in this course, firewalls, servers, mail, endpoints, comes as events of this kind.

Events carry far more than four fields. A sign-in records the application, the device, the location, the authentication method and more; table is how a search chooses which to show, and Section 0.2 lists the ones every event has.

A question such as "which accounts failed to sign in most?" has a direct translation into SPL.

index=azuread category=SignInLogs action=failure
| stats count by user
| sort - count
| head 3

sort - count orders the rows by count, largest first; the minus sign means descending. Without it, the smallest counts would come first and head 3 would keep accounts with a single failure.

r.scott's 89 failures stand far above the next account's 14. A number that large next to others this small is the kind of thing the course teaches you to notice and then explain, and Module 4 begins that explanation.

The question and the search have the same parts in the same order: failed sign-ins, per account, most first, three of them. That correspondence is what makes SPL learnable; most searches are a question written down step by step.

r.scott with 89, d.foster with 14, d.thompson with 10. Read the search left to right: the base search reads failed interactive sign-ins, stats counts them per account, sort puts the largest first, and head keeps three. Each pipe hands one step's output to the next, which is why order matters in SPL.

head 5 at the end keeps the five rows with most failures, because the sort before it put them first. Section 0.5 builds a first search of your own the same way, one step at a time.

The search reads in the order of its question, failed sign-ins, per account, most first, five, and that order is the one SPL runs it in.

The five accounts are r.scott, d.foster, d.thompson, r.okafor and n.taylor, from 89 failures down to 9. r.scott's 89 is the month's largest by far, and later modules find out why.

The write exercise is the same question with five accounts. Most searches in this course start this way: a base search that narrows the events, then a few commands that turn them into an answer.

Writing the question down first, in a sentence, and then translating each part is the method this course uses throughout. When a search gives a surprising answer, the sentence is what it is checked against.

The base search returns events. A transforming command such as stats turns events into results: a table with one row per group and only the fields the command made.

index=azuread category=SignInLogs
| stats count

The count is of events, not of people or days: 8,203 sign-in events, made by about a hundred accounts over a month. Saying what a count counts is a habit worth forming from the first search.

The base search named the index, azuread, and a field value, category=SignInLogs. Without the category term the count would include three other kinds of Entra ID event, 23,843 in all, which Section 0.3 introduces.

The answer's field is called count, the name stats gives a count unless told otherwise. Naming results, with as, is a habit Module 4 builds; here the default is enough.

One row, one number: 8,203. stats count turned eight thousand events into a single result. Counting first is a habit worth forming, because it says how much data a question touches before any other work is done.

The exercise's blank is the whole transforming step. Everything before it chose the events; this command decided what the answer would be made of.

The exercise's answer, 8,203, appears throughout the course. Knowing a few figures like it by heart makes a wrong answer easy to spot: a search that claims 4,000 interactive sign-ins for the month has dropped something.

stats is a transforming command: it reads events and returns results. The other transforming commands this course uses, chart, timechart, top and rare, follow the same pattern with different shapes of table.

The completion exercise is stats count. It is the most-used command in this course and usually the first one worth running on any new data.

Events keep every field they had; results keep only what the transforming command produced. A search can do more with events after a stats only by keeping what it needs in the stats itself, a rule Module 4 and Module 10 both return to.

A search never changes the events it reads. Adding a term changes which events the search reads and what it reports.

index=azuread category=SignInLogs action=failure
| stats count

The two counts, 8,203 and 338, came from two searches that differ by one term. Changing one thing and counting again is the simplest experiment in SPL, and the one this course asks for most often.

338 of 8,203 is about four per cent. A failure rate like this is ordinary for a company's sign-ins; the question the course keeps asking is which of those failures are not ordinary.

action=failure is a field=value term: the field named action, with the value failure. Terms like this in the base search are the main way a search says what it wants, and Module 2 is about writing them well.

338 failures. The month still holds 8,203 sign-ins; the search simply asked about fewer of them. Because searches only read, anyone running the same search over the same data gets the same answer, which is what makes the numbers in this course reproducible.

| makeresults
| eval answer=6*7
| table answer

table answer chose the one field to show. Without it, makeresults would also show the _time it gave the result, the moment the search ran.

eval created a field called answer and gave it the value of an expression. eval is how SPL computes new values from existing ones, and Module 3 uses it on every kind of field.

The search begins with a pipe because there is no base search; makeresults is itself the start. Searches that build test values this way are a quick way to try an expression without waiting for real data.

makeresults produced one result from nothing, and eval computed 42 into it. Searches that start with a pipe, like this one, begin with a command that generates results rather than a base search that reads events; later modules use several.

Reading-only also means the lab's data is the same for everyone, however many searches have been run against it. The figures in this course, 8,203 sign-ins and 338 failures among them, can be reproduced exactly by anyone who runs the same search.

Most of SPL ignores case: command names, the values in a base search, words in the text of an event. Field names do not.

index=azuread CATEGORY=SignInLogs
| stats count

Case-insensitive values are a convenience in the base search: SignInLogs, signinlogs and SIGNINLOGS all match. The where command compares values exactly, a difference Module 2 explains.

The case rule applies to field names in every command, not only the base search. A stats count by User, with a capital U, produces no groups at all here, because no event has a field called User.

The search ran, read events, and found none with the field it named. Splunk does not warn about a field name that no event has, because fields differ between sources and a name missing from one may be present in another.

0 sign-ins, and no error. The events have a field called category; CATEGORY is a different name that no event carries, so nothing matches. The same search with STATS in capitals, or SignInLogs in lower case, gives 8,203, because commands and values are not case-sensitive.

Copying a field name means taking it from an event, a field list, or a search that already works. Section 0.2 shows where Splunk lists the fields of the events a search returns.

In the lab and in Splunk, an empty result from a field name that does not exist looks exactly like an empty result from a real absence. The course's habit of counting before filtering is how the two are told apart.

The broken search's field, Category, differs only in its first letter. Splunk treats it as a different field entirely, which is the rule in one example.

The fix writes the field name exactly as the data does. Field names come from the data's own format, and the safest habit is to copy them from an event rather than type them from memory.

The first mistake has a quick check: a stats count of the field name on its own, count(category), shows how many events carry it. A count of zero means the name is wrong, or the field belongs to another source.

The third mistake is the subtlest. A where after stats on a field stats did not keep finds nothing, because the field no longer exists at that step; Module 1 shows it in detail.

The second mistake costs time rather than correctness: a search with no index reads every index the user can see. In a large deployment that can be many terabytes, and naming the index is the cheapest improvement any search can have.

All three mistakes are among the commonest in a first week of SPL. Each produces a result without an error, which is why the course checks results against the events, not only against expectations.

Different sources name the same idea differently: one calls the account user, another UserName, another TargetUserName. Module 1 shows how to learn a sourcetype's names, and Module 9 shows how data models give many sources one shared set of names.

Splunk Enterprise, installed and run by an organization itself, and Splunk Cloud Platform, run by Splunk as a service, both run SPL.

Searches are typed in the Search & Reporting app's search bar; saved, they become reports and alerts on a schedule; placed on dashboards, they draw panels; in Splunk Enterprise Security, they are the detections that raise findings. The language is the same in each place, and a search that works in the search bar works in all of them.

The first rung is the cheapest: everything before the first pipe is the base search. Reading it first says which events the rest of the search ever sees, which is most of what a search means.

The fourth rung is the one beginners skip and experienced analysts never do. A count at each step shows how much the search is carrying and where the answer came from, and it is the first thing to look at when a result surprises.

The ladder is the reading habit this course builds. The first two rungs are mechanical, the third is understanding, and the fourth, counting, is the check that runs through every module.

Splunk also has a second language, SPL2, which Section 0.4 compares with SPL. This course teaches SPL, the default in the Search & Reporting app and the language of almost all the searches an analyst meets, and its last lesson shows how searches convert to SPL2.

Splunk is a product of Cisco, which acquired it in 2024, and its documentation lives at help.splunk.com. This course cites that documentation by page and date wherever it states how Splunk behaves, because product behavior changes between releases and a dated statement can be rechecked.

Every search in this course runs in the practice lab, in your browser, against a fixed month of data from a fictional engineering company. Each search on the page has a Run button and, where it helps, a prediction to make before the result appears. The lab runs the SPL this course teaches, and Section 0.6 sets out the few places where it differs from Splunk itself.

| tstats count where index=* by index sourcetype

Sysmon's 22,842 events are process starts, network connections, file and registry changes on the company's computers. They are the busiest source after Entra ID and the one Modules 6 and 8 rely on for the endpoint attacks.

The network index holds two sourcetypes, the firewall and the VPN gateway, so an index and a sourcetype are not the same thing. Section 0.2 explains how the two relate and why most searches name both.

The search starts with a pipe and tstats, a generating command like makeresults. It reads counts from the indexes rather than events, which is why it can count tens of thousands of events at once without reading any of them.

These seven are the sources the course leans on most, and they are the seven this search box loads: in the lab, index=* reads only the sources a box loads, where in Splunk it reads every index you are allowed to search.

The whole month holds a little over two hundred thousand events from eleven indexes, with mail, cloud services and DNS among the rest, and several real attacks are in it, which the course finds one by one.

The lab also has a query console, opened from any search's console button, where a search can be edited and run freely. The searches on each page are starting points; changing them and predicting what the change will do is how the language becomes familiar.

Section 0.2 shows how Splunk stores events and the fields every event carries. Section 0.3 introduces the sourcetypes this course searches. Module 1 begins the language properly, with the structure of a search and the fields it reads.

The habits are four, and they are the ladder above. Find the base search first. Read the commands in the order they run. Say what each row of the answer is, in a sentence. And count at each step, before trusting the answer.

Practice

Three questions about the month's sign-ins and how SPL reads them.

The third question is the case rule in one number. Run it, then run the same search with category in lower case, and keep the pair in mind for the first time a search of yours returns nothing.

Next, Section 0.2 covers how Splunk stores events: indexes, sourcetypes, and the fields every event carries.