Splunk Online Tutorial: Installation, Log Collection, Search, Reports, and Alerts

Learn Splunk fundamentals: install the platform, collect local and remote logs, search with SPL, analyze fields, build reports, and configure alerts.

Splunk is a platform for ingesting, indexing, searching, monitoring, and analyzing machine-generated data. This tutorial covers a beginner-friendly workflow: install Splunk, collect logs, verify events, investigate them with Search Processing Language (SPL), and turn useful searches into reports and alerts.

You should be comfortable with files and folders, browser-based sign-in, basic logs, and general computer administration. Linux examples assume familiarity with a terminal; Windows examples assume basic service and file-system administration.

What Splunk Does

Machine data is information produced by operating systems, applications, network devices, services, and other computers. Splunk turns this data into searchable events. An event is one time-associated record indexed by Splunk.

Common sources include:

Linux system logs and Windows Event Logs
Web server access and error logs
Application logs, audit trails, and database messages
Network device events, firewall records, and DNS activity
Authentication, endpoint, and other security events

Data may be structured, with a predictable schema such as JSON or CSV; semi-structured, with recognizable key-value pairs but variable content; or unstructured, such as free-form text messages. Splunk can index all three, but reliable field extraction and useful analysis depend on consistent formats and correct data onboarding.

Splunk supports both historical searches and real-time searches. A historical search examines events already indexed during a defined past period. A real-time search evaluates arriving events or a continuously moving time window. Search results help teams troubleshoot failures, monitor operations, investigate security activity, create recurring reports, and trigger alerts.

For an additional overview, see What Is Splunk and Splunk data sources.

Splunk Architecture and Data Flow

A small laboratory installation can perform several roles on one computer. A production deployment commonly separates those roles for scale, resilience, and access control.

Component | Primary role | Typical location | Relationship to data flow

Forwarder | Collects and sends data | Source system | Reads files or events and forwards them

Indexer | Processes, indexes, stores, and returns matching events | Splunk data tier | Receives events and serves search results

Search head | Provides search, reporting, visualization, and user access | Splunk user-facing tier | Sends searches to indexers and presents results

A typical flow is:

A system, application, or device produces a log record.
A local Splunk input or a forwarder reads the record.
Splunk assigns metadata and sends the event to an indexer.
The indexer processes and stores the event in an index, a logical searchable data store.
A search head runs SPL against one or more indexers.
The results appear as events, statistics, or visualizations and may be saved as reports or alerts.

At index time, Splunk receives, parses, timestamps, routes, and stores incoming events. At search time, Splunk extracts or calculates fields while a search runs. This distinction matters: changing a search-time field extraction can improve searches without re-ingesting data, while incorrect event breaking, timestamps, or index routing may require onboarding changes.

Important Event Metadata

Metadata field | What it identifies | Example value | Typical search use

index | Logical data store | main | Limit the search to the correct dataset

host | System that originated the event | web01 | Investigate one server or compare hosts

source | Specific input origin, often a path | /var/log/auth.log | Select one file or input

sourcetype | Event format or data type | access_combined | Apply appropriate parsing and searches

Local ingestion reads data on the Splunk host itself. Remote collection normally uses a forwarder on the source computer and a receiving indexer or Splunk instance. A universal forwarder is a lightweight agent commonly used for endpoint log collection; it collects and forwards data but does not provide the full search experience.

Learn more about forwarders, creating an index, and setting up a receiver.

Installing Splunk

Choose a Splunk distribution suitable for your operating system and learning goal, such as an evaluation or trial edition where available. Review its license, resource requirements, supported operating system versions, data limits, and retention behavior before using it for a lab or production workload.

Windows Installation

Obtain the Windows installer from your authorized Splunk download source.
Run the installer with an account permitted to install software and services.
Choose the installation directory and accept the license terms.
Create the initial administrator account when prompted. Store the credentials securely.
Allow the installer to configure the Splunk service and web interface.
Open the local Splunk Web address shown by the installer and sign in.

For a dedicated procedure, see Install Splunk on Windows. Windows log collection may also require Windows inputs or local Windows Event Log collection.

Linux Installation

Obtain the package appropriate for the Linux distribution and processor architecture.
Install it in a controlled directory, commonly under /opt or another administration location.
Change to the Splunk binary directory.
Start Splunk and accept the license.
Create the initial administrator account.
Open Splunk Web in a browser and sign in.

cd /opt/splunk/bin
./splunk start
./splunk status
./splunk stop
./splunk enable boot-start

The exact service configuration depends on the installation method and operating system. Use status to confirm that the service is running, and enable boot-start only after verifying that the installation behaves correctly. See Install Splunk on Linux for a focused installation guide.

Initial Setup and Licensing

After signing in, confirm the administrator identity, review the selected license or trial limits, and set an appropriate password policy. Trial and free configurations can impose limits on daily ingestion, features, or duration. Do not assume that a lab license is suitable for a production deployment.

If Splunk Web does not open, confirm that the service is running, check that the configured web port is reachable locally, review firewall rules, and inspect Splunk service logs for startup errors. The Splunk Web interface and Splunk Home provide orientation after installation.

Adding and Collecting Data

Use the Add Data workflow to choose an input, assign metadata, and validate the resulting events. The key decisions are the input location, index, sourcetype, host value, and source value.

Monitor a Local File or Directory

Open the data-input workflow in Splunk Web.
Choose a local file or directory to monitor.
For a directory, define which files or patterns should be included. Avoid unintentionally ingesting temporary files, rotated archives, or sensitive files.
Select an existing index or create an appropriate one.
Choose or verify the sourcetype. It should describe the event format, not merely the team that owns the data.
Confirm the host and source values.
Save the input and generate or wait for new log entries.
Search the selected index and verify the expected metadata and event timestamps.

For example, a Linux authentication log can be monitored as a file input, assigned to a security or operational index, and given a sourcetype that accurately represents its format. The Splunk process must have permission to read the file.

See Add Data to Splunk for the workflow and Create an Index when a separate data store is needed.

Collect Data from Remote Computers

For remote collection, install and configure a forwarder on the source system. The forwarder reads permitted inputs and sends events to a receiving Splunk instance. The receiver must accept the connection, and network connectivity, ports, certificates, and credentials must be configured correctly.

Install a universal forwarder on the remote host.
Configure the files, Windows event channels, or other inputs it should collect.
Configure the forwarder's output to point to the receiving Splunk instance.
Configure the receiver to accept the forwarder's connection.
Start or restart the forwarder.
Search by the remote host value and verify that new events arrive.

See Install a Splunk Forwarder on Linux, Configure a Splunk Forwarder on Linux, Install a Splunk Forwarder on Windows, and Monitor Logs Using Forwarders.

Method | Suitable data source | Local or remote | Key considerations

Single-file monitor | Application or system log | Usually local | Check permissions, rotation, timestamp format, and file pattern

Directory monitor | Several similarly formatted logs | Usually local | Include only intended files and avoid duplicate inputs

Windows event input | Security, System, or application channels | Local or forwarder-based | Select channels and account permissions carefully

Universal forwarder | Endpoint files and event logs | Remote to receiver | Configure outputs, receiver settings, network access, and certificates

Validate Ingestion

Start with a broad search in the expected index and a recent time range. Confirm that events have sensible timestamps, the expected host, source, and sourcetype, and the correct raw text. If no events appear, expand the time range, verify the index permissions, check the input path, and create a new test event if the input only collects future writes.

Navigating Splunk Web

Splunk Home provides access to installed apps and common workflows. The Search and Reporting workspace is the main place to write SPL and inspect results. Apps can provide context-specific navigation, dashboards, inputs, and saved searches.

Search bar: enter SPL and submit a search.
Time range picker: choose the event period to search.
Job controls: pause, stop, inspect, or share a running or completed search where permitted.
Events view: inspect raw matching events and timestamps.
Statistics view: inspect tabular results from transforming commands.
Visualization view: display charts or other visual forms of tabular results.
Fields sidebar: review selected, interesting, and available fields.
Save controls and history: save searches as reports or alerts and revisit previous searches.

The time range is a search constraint, not merely a display preference. A narrow, appropriate range generally improves relevance and performance. See Launch the Search app and Time Range Picker.

Foundational SPL Searching

SPL, or Search Processing Language, uses a pipeline. The first part selects events, and a pipe character sends those results to another command for filtering, grouping, sorting, or visualization.

index=main
index=main host=web01
index=main sourcetype=access_combined
index=main error OR failed
index=main "connection refused"
index=main status=500
index=main | stats count by host
index=main | top limit=10 user
index=main | timechart count by status

Use metadata constraints early when you know them. Parentheses make Boolean intent explicit, and exact phrases match a sequence of words. Wildcards are useful for controlled variations but can broaden a search significantly. Avoid beginning with a very broad wildcard across all indexes and all time.

Command or pattern | Purpose | Typical input | Expected output

keyword | Find matching event text | error | Events containing the term

field=value | Filter by a field | host=web01 | Events whose field matches

AND, OR, NOT with parentheses | Combine conditions | (error OR failed) NOT test | More precise event set

stats | Aggregate events | stats count by host | Statistics table

top | Rank frequent values | top user | Frequency table with top values

timechart | Build time buckets | timechart count by status | Time-series table or chart

For more practice, review example searches, Boolean expressions, pipes, and search rules.

Fields and Event Investigation

A field is a named value associated with an event, such as user, src_ip, status, or severity. Default metadata fields include index, host, source, and sourcetype. Other fields may be automatically extracted from structured data or defined through search-time extraction.

The raw event is the original indexed text. A field is a searchable interpretation of part of that text. A value visible in raw text is not necessarily available as a field until Splunk can extract it. Use the fields sidebar to select useful fields, inspect field summaries, and add field-value filters. If extraction is wrong, inspect the raw format and assigned sourcetype before designing complex searches.

Example investigation workflow:

Start with a recent time range and an index.
Search for authentication terms such as login, failure, or denied.
Add a host, source, or sourcetype constraint.
Inspect timestamps and raw events.
Use available user and source-address fields to group failures.
Correct onboarding or field extraction if important values are missing.

See Splunk fields for field-oriented techniques.

Statistics and Search-Time Analysis

A transforming command converts matching events into statistics, tables, or charts. Common aggregations include count, sum, avg, min, and max.

index=main | stats count by host
index=main | stats count by user
index=main status=500 | stats count by host
index=main | stats avg(response_time) min(response_time) max(response_time) by host
index=main | top limit=10 user
index=main | timechart count by status

The resulting table should be interpreted in context. A high count may mean high traffic rather than a problem; a missing value may indicate an extraction issue; and a time trend depends on the selected bucket size and time range. Group by the field that answers the operational question: host for infrastructure comparison, user or source address for authentication investigation, status for web behavior, and severity for prioritization.

Useful commands include stats, top, sort, and where.

Reports and Visualizations

A report is a saved search that produces reusable analytical results. Reports are useful for recurring operational summaries, even when no immediate notification is needed.

Complete and test the search.
Choose a meaningful time range and confirm that the result is useful.
Save the search with a clear name and description.
Choose a table for detailed categories, a bar or column chart for categorical comparisons, or a line chart for time-based trends.
If appropriate, schedule the report and define its execution interval and time window.
Set permissions according to who should be able to run or view it.
Run it manually and verify the output after scheduling.

For example, an operations report might count errors by host:

index=main (error OR failed) | stats count by host

Results may be exported or shared only when organizational permissions and data-handling rules allow it. Avoid distributing logs containing credentials, personal information, tokens, or sensitive infrastructure details. See Reports Overview, Create a Report, and Share a Report.

Alerts

An alert is a saved search that triggers an action when a condition is met. A report tells people what the data says on a recurring basis; an alert is designed to prompt action when a threshold or other condition indicates a noteworthy event.

Capability | Report | Alert

Primary purpose | Reusable analysis | Notification or response when a condition occurs

Trigger | Runs on demand or on a schedule | Runs on a schedule or in real time and evaluates a condition

Output | Table, chart, or search result | Email, webhook, log event, or another permitted action

Design focus | Clarity and recurring visibility | Actionability, threshold accuracy, and duplicate control

Build a Threshold Alert

Write and test a search that returns the relevant events.
Transform the results if necessary, for example with stats count.
Choose scheduled or real-time behavior. Scheduled searches are often easier to control and less expensive than continuously running searches.
Define the evaluation window, schedule, trigger condition, and threshold.
Choose a permitted notification action such as email, webhook, or logging an event.
Add throttling or suppression so repeated matches do not create duplicate notifications.
Test the logic with known sample events before enabling production notifications.

index=main sourcetype=web_error earliest=-15m latest=now
| stats count
| where count > 20

The exact alert condition can be configured through the alert editor rather than appended as shown. The important design is that the search measures a defined interval and the threshold represents an actionable condition. Review Alerts Overview and Create an Alert.

Alert Lifecycle

The scheduled or real-time search evaluates incoming or indexed data.
The result is compared with the trigger condition.
Throttle rules suppress duplicate triggers during the configured interval.
The selected action sends a notification or records the result.
An operator investigates the underlying events and adjusts the search if necessary.

Alerts that trigger too often usually need a better threshold, a narrower search, a more appropriate evaluation interval, or throttling. Test with known events before connecting notifications to operational workflows.

Practical Beginner Workflows

Investigate Authentication Activity

index=main host=linux01 (login OR authentication OR failed)
| stats count by user

Begin with the index and host, restrict the time range, inspect raw events, and then group by user or source address. A high-frequency value may indicate a misconfigured service, a normal automated process, or an attack; validate it against the original events.

Analyze Web Server Errors

index=main sourcetype=access_combined
| stats count by status

index=main sourcetype=access_combined
| timechart count by status

Use the statistics view to compare status codes and the visualization view to identify trends. HTTP 500 results may indicate server-side failures, while increased 404 results may indicate broken links, scans, or deployment issues. Interpret the values with traffic volume and application context.

Operational Search Practices

Start broad enough to confirm that data exists, then narrow with index, host, source, sourcetype, and fields.
Use a relevant time boundary. Searching years of data for a recent incident wastes resources and obscures the answer.
Check event volume and timestamp correctness before trusting a trend.
Name saved searches clearly, including their purpose, data source, and scope.
Use least-privilege roles and restrict access to sensitive indexes and saved results.
Do not expose passwords, tokens, personal data, or confidential content in reports and notifications.
Treat missing fields, inconsistent timestamps, duplicate events, and incorrect sourcetypes as data-onboarding problems rather than merely search problems.

Troubleshooting Checklist

No Web Interface

Confirm that the Splunk service is running.
Verify the expected web port is reachable locally.
Check host firewall rules and browser address details.
Review service logs for startup, port, permission, or license errors.

No Events from a Monitored File

Confirm the file path, directory input, and file pattern.
Verify that the Splunk process can read the file.
Search the correct index and ensure the user's role can access it.
Generate or wait for a new entry if the monitor collects only future writes.
Expand the time range and check event timestamps.

Remote Logs Do Not Arrive

Confirm that the forwarder service is running.
Test network connectivity between the forwarder and receiver.
Verify forwarder output settings and receiver configuration.
Inspect forwarder logs for connection, certificate, or authentication errors.
After connectivity is restored, search using the remote host metadata.

Missing Fields or Incorrect Values

Inspect the raw event format.
Verify the assigned sourcetype.
Use field-extraction tools or search-time extraction methods where appropriate.
Check whether the same field changes format between applications or versions.
Use raw text searches temporarily while correcting extraction.

Search Returns No Results

Expand the time range.
Search the index without host, source, or sourcetype filters.
Remove overly restrictive keywords and Boolean conditions.
Check timestamp extraction and event time rather than ingestion time assumptions.
Confirm that role permissions include the index.

Summary

Splunk collects machine data, indexes it as events, and makes it searchable through SPL. Forwarders collect remote data, indexers store and serve it, and search heads provide the user-facing search and analysis experience. Successful work depends on accurate index, host, source, and sourcetype metadata; appropriate time ranges; usable fields; and tested searches.

A practical learning sequence is to install a local lab, monitor one Linux or Windows log, verify its events, search by metadata and text, summarize failures with statistics, save a report, and then create a carefully throttled threshold alert. Next steps include remote Windows event collection, advanced SPL, field extraction, dashboards, role-based access control, and data governance.