3.1 Running Basic Searches

3.1 Running Basic Searches

Quick Answer: Type keywords or simple SPL into the Search bar, set a time range, then click Search (or press Enter). Splunk starts a search job that returns matching events in the Events tab—or statistics when you use transforming commands.

Basic Searching is the largest domain on the Splunk Core Certified User exam (22%). Topic 2.1 Run basic searches is the entry point: you must know how to launch a search, what happens when the job starts, and how to read the primary result views. Everything later in Domain 2—time ranges, result fields, refining, timeline, events, job control, and saving—builds on this workflow.

Why this matters on the exam

Splunk is not a spreadsheet you open and scroll. Data lives in indexes as events. To see anything useful, you run a search. Exam questions often describe a UI action (“You click Search…”) or ask which tab shows raw events versus aggregated counts. If you confuse starting a job with saving a report, or Events with Statistics, you will lose easy points.

The Search & Reporting workspace

Most User-level work happens in the Search & Reporting app (often called the Search app). After you open it, the dominant control is the Search bar at the top of the page—the text box where you type what you want Splunk to find.

You do not need admin privileges to run searches in indexes your role can read. User exam scenarios assume you are a search user with access to sample or production indexes such as main or a training index—not that you configure inputs or indexes.

Keywords versus SPL (at the User level)

A basic search can be as simple as one or more keywords:

error

failed login

"connection refused"

Splunk treats space-separated terms as an implied AND against event text unless you use Boolean operators (topic 2.4). Quoted phrases match that exact phrase in _raw.

You can also write explicit SPL starting with search (often omitted) and filters:

index=web sourcetype=access_combined status=500

For Domain 2.1, focus on the run path: enter terms → start job → inspect results. Pipeline commands after a pipe (| stats, | top, and so on) belong to later domains; know only that once you add a transforming command, the primary result surface shifts from Events to Statistics.

Starting the job: Search button and keyboard

After you type in the Search bar:

1. Confirm the time range (never leave an accidental “All time” on a busy index in real life; exams still test that the picker matters).
2. Click the green Search button, or press Enter/Return in the Search bar.
3. Splunk creates a search job with an ID and begins scanning buckets that fall inside the time window.

While the job runs, the UI typically shows:

• Progress (percentage or activity indicator)
• Events found so far (matching events)
• Scanned events or similar counters (how much data was examined)
• Options to pause, stop/finalize, or open Job details (deeper job control is topic 2.7)

A finished historical search settles into a completed state. A real-time search keeps updating until you stop it (time-range types are topic 2.2).

Exam trap: typing is not searching

Draft text in the Search bar does nothing until you submit it. Closing the browser tab cancels an unfinished interactive session. Saving as a report or dashboard panel is a different action from simply running an ad-hoc search (Domain 6 and 2.8).

What “matching events” means

For keyword searches, Splunk looks for your terms in indexed event data—primarily the raw text (_raw) and searchable fields—within the selected time range and indexes your role can access. Each match is an event: one timestamped record (often one log line or multiline message).

Typical event list columns / attributes you will see immediately:

Clicking into an event expands details. Field inventory on the left sidebar is covered in topic 2.3 and Domain 3; for 2.1, know that Events is where individual matches appear.

Events tab versus Statistics tab (basics)

User exam rule of thumb:

• error OR fail → primarily Events
• ... | stats count by host → Statistics (Events may be empty or not the focus)
• ... | timechart count → Statistics + Visualization

Do not invent Power User concepts here (data models, Pivot as a substitute for SPL, macros). Core User Basic Searching is about the Search bar workflow and these result tabs.

Search modes (awareness only)

The Search app offers Fast, Smart, and Verbose modes that affect field discovery and event inspection detail. Smart is the usual default for interactive work. Deep mode trade-offs show up more in fields and performance discussions; for 2.1, remember that mode can change how much field/event detail you see without changing the fact that you still start the job the same way.

Worked scenario

Goal: Find failed authentication messages from the last hour on web servers.

1. Open Search & Reporting.
2. Set time range to Last 60 minutes (or equivalent preset).
3. In the Search bar type: failed login or index=main "failed login".
4. Click Search.
5. Watch the job progress; open the Events tab and skim highlighted matches.
6. Note host / sourcetype on events to confirm you are looking at the right data before refining (2.4).

If you instead run index=main "failed login" | stats count by host, the same keywords feed a transforming pipeline and you study the Statistics table of counts per host—not a long event list.

Common mistakes to avoid

Checklist before you click Search

1. Keywords or SPL are spelled as you intend (case can matter for field values; keywords in _raw are generally case-insensitive for search terms—follow product behavior you practice in the UI).
2. Time range matches the investigation window.
3. You know whether you expect Events or Statistics.
4. You are ready to refine with more terms or field filters if the first pass is too noisy.

Master this launch-and-read loop, and the rest of Domain 2 becomes incremental skill rather than a new product.