Splunk Enterprise Certified Admin key terms

The Splunk Enterprise component that receives and stores incoming data in indexes and processes search requests sent by search heads. Indexers perform the heavy work of parsing, indexing, and searching data.

The Splunk Enterprise component that handles user searches, distributes them to indexers, and merges the returned results. Search heads also host apps, dashboards, and knowledge objects such as saved searches.

The core Splunk Enterprise daemon that runs on every Splunk instance, handling indexing, searching, forwarding, and REST API requests. Almost all Splunk functionality depends on splunkd running properly.

The default network port used by splunkd for the REST API and for communication between Splunk components, such as deployment clients contacting a deployment server or search heads contacting peers.

The Splunk instance that holds the license and governs how much data all connected license slaves may index. It warns of violations and can restrict searching when the license is exceeded.

A grouping of license stack capacity allocated to specific license slaves or license groups. Pools let administrators divide a single license stack among teams, indexes, or environments.

A state triggered when the volume of data indexed in a rolling 30-day window exceeds the licensed daily quota. Violations produce warnings and, if persistent, can block new data ingestion.

A configuration file that defines where and how a Splunk instance collects data, including monitor stanzas for files and directories, network inputs, and Windows event log inputs.

A configuration file that controls where a Splunk instance sends collected data, such as forwarding to indexers, configuring load balancing, and setting TLS for forwarding connections.

A configuration file that sets per-sourcetype or per-host parsing behavior, including timestamp recognition, line breaking, character set, and search-time field extractions and field transformations.

A configuration file that defines data transformations such as regex-based field extractions, lookups, and routing of events to specific indexes, referenced from props.conf or inputs.conf.

The configuration file that defines indexes, including their storage paths, size limits, retention settings, and whether the index participates in an indexer cluster.

A command-line utility that prints the merged, effective configuration of a Splunk instance, showing which .conf file and stanza each setting comes from, which is useful for troubleshooting precedence.

The order in which Splunk applies settings when the same key appears in multiple .conf files: system local, app local, app default, and system default, with local directories overriding default ones.

A named collection of capabilities and index access rights that can be assigned to users. Roles determine what a user can do and which data they can see in Splunk.

A specific permission, such as search or edit_sourcetypes, that controls which actions a user can perform. Capabilities are granted to roles and inherited by the users assigned to those roles.

A configuration that lets Splunk validate user credentials against an external LDAP directory instead of its internal user database, optionally mapping LDAP groups to Splunk roles.

A single sign-on method where Splunk delegates user authentication to an external identity provider, receiving assertions about the user's identity and attributes after a successful login.

A directory on an indexer that holds a portion of an index's data, grouped by age into hot, warm, cold, and frozen states. Buckets roll from hot to warm to cold as they age.

Settings in indexes.conf that determine how long index data is kept, such as frozenTimePeriodInSecs and total size limits. Data that exceeds the policy is frozen and usually deleted.

A default field that identifies the format or type of incoming data, such as access_combined or WinEventLog. Sourcetypes drive parsing rules, timestamp recognition, and field extractions.

An inputs.conf stanza that tells Splunk to watch a file or directory, index new lines as they appear, and optionally follow renamed or rotated files.

A hidden index where Splunk records the files and read positions it has already processed, so forwarders do not re-index the same data after a restart.

An inputs.conf setting that changes the checksum Splunk uses to identify a file, forcing re-reading of a file that would otherwise be skipped as already indexed.

A lightweight Splunk agent that collects data and sends it to indexers or another forwarder. It performs minimal parsing and cannot run searches or host full apps.

A Splunk Enterprise instance that pushes apps and configuration bundles to deployment clients, such as universal forwarders, based on the server classes those clients match.

A deployment server grouping that matches clients by hostname, IP address, or other criteria, and determines which deployment apps those clients receive.

An app stored in the deployment server's deploymentapps directory that is pushed to deployment clients assigned to a matching server class.

An indexer that a search head is configured to send distributed searches to. Search peers return partial results that the search head merges into a final result set.

The default TCP port on which an indexer or forwarder listens for data sent by forwarders, enabled with the splunk enable listen command or an inputs.conf stanza.

A built-in Splunk app that provides dashboards for the health and performance of a distributed deployment, covering indexing throughput, search performance, license usage, and component status.

The default index that stores Splunk's own logs and metrics about splunkd, including errors, warnings, and search activity, which is used heavily for troubleshooting and monitoring.

A package of configurations, dashboards, saved searches, and knowledge objects that extends Splunk functionality, stored under the apps directory of a Splunk installation.

A type of app that provides inputs, field extractions, or other configuration for specific data sources, usually without a user interface, and is often deployed to forwarders and indexers.

In indexer clustering, the number of copies of each bucket kept across peer nodes. A replication factor of three keeps three copies so searches survive peer failures.

In indexer clustering, the number of searchable copies of each bucket maintained across peers. It must be less than or equal to the replication factor.

The clustering process of creating or restoring bucket copies after a peer fails or rejoins, so that the replication and search factors are met again.

The indexer cluster node that coordinates peers, manages bucket replication, and tells peers which buckets to copy. It does not index or search data itself.

A cluster state where a peer is temporarily taken offline so it stops receiving new buckets and the cluster does not attempt fixups, which is used for upgrades and repairs.