Splunk Core Certified Power User Course Notes

Use `chart` when the result should be a transformed table organized by categorical fields rather than by time. Use `timechart` when the analysis is explicitly about change over time. It bins `_time`, applies a statistical function, and can split the metric into multiple series.

• 1.1 Use the chart command: Choosing `timechart` simply because a visualization is requested even though time is not the x-axis.

• 1.1 Use the chart command: Find the x-axis clue first. Category → think `chart`; time → think `timechart`.

`eval` creates or overwrites fields at search time by evaluating expressions against each result. The exam emphasizes expression syntax, conditions, string handling, multivalue helpers, and null-safe logic. Both `search` and `where` can filter results, but they use different expression styles. Choose based on whether the condition is a search-language predicate or an eval-style calculation/comparison. `fillnull` is a pipeline command that replaces null values with a specified value. The exam tests its syntax, default behavior, field-list behavior, and the result-schema caveat.

• 2.1 The eval command: Using `+` for string concatenation instead of `.`.

• 2.1 The eval command: Read the right-hand side as an expression: fields, literals, operators, functions.

A Splunk transaction is a group of related events treated as one logical unit. Use `transaction` when you need event-sequence grouping, raw member-event context, or transaction-specific boundary/timing semantics. When the requirement is one aggregate row per unique field combination, `stats ... BY <fields>` is usually the direct tool. This objective focuses on choosing grouping keys and aggregation functions correctly. Combine time bucketing with field grouping when the report needs aggregates per interval and per category. The key pattern is `bin _time` followed by `stats ... BY _time ...`. Build transaction searches by narrowing candidate events first, then applying transaction grouping and constraints. Know the transaction options and the special `searchtxn` command for configured transaction types. After `transaction` creates grouped meta-events, report on transaction-generated fields and other combined fields using normal SPL commands such as `where`, `stats`, `chart`, or `timechart`. The exam repeatedly asks you to choose the lowest-complexity command that satisfies the correlation requirement. `stats` is preferred for straightforward grouped aggregates; `transaction` is for event-sequence semantics and raw grouped context.

• 3.1 Identify transactions: Using `transaction` for simple counts or averages that `stats` can compute directly.

• 3.1 Identify transactions: Raw sequence/context needed → transaction.

Use the Field Extractor's Regular Expression method for unstructured events or event formats where a fixed positional delimiter is not reliable. The workflow is sample → highlight → preview → refine → validate → save. Use the Delimiters method when events are consistently structured and each field stays in the same position, separated by a common delimiter such as comma, pipe, tab, space, or semicolon.

• 4.1 Perform regex field extractions using the Field Extractor (FX): Using the delimiter method when the event is not consistently positional.

• 4.1 Perform regex field extractions using the Field Extractor (FX): Unstructured → regex. Structured + stable delimiter → delimiters.

Field aliases give an existing extracted field one or more alternate names at search time without removing or rewriting the original field. They are a core normalization tool. Calculated fields are reusable search-time fields defined by eval expressions, usually scoped to a host, source, or sourcetype. They make derived values available automatically without repeating ad-hoc `eval` logic in every search.

• 5.1 Describe, create, and use field aliases: Claiming aliases run after calculated fields or that calculated fields cannot use aliases.

• 5.1 Describe, create, and use field aliases: Memorize the order: extraction → alias → calculated field → lookup → event type → tag.

Tags are semantic labels associated with field/value pairs or event types. They let searches refer to a meaningful classification instead of hard-coding every underlying value. An event type is a named search definition that classifies events at search time. Events matching the definition receive the corresponding `eventtype` value, which can then be searched or tagged. Create an event type from a well-tested event-returning search, then optionally add tags, color, priority, app context, and sharing permissions.

• 6.1 Create and use tags: Saying tags can only be applied to event types.

• 6.1 Create and use tags: General semantic category → `tag=name`.

Search macros are reusable chunks of SPL that are expanded into a search at parse time. They reduce duplication, centralize logic, and can be parameterized. A basic macro is a named SPL definition, often with no arguments. Create it in Search Macros settings, then invoke it with backticks wherever its expansion is syntactically valid. Parameterized macros declare argument names and substitute caller-supplied values into `$argument

• 7.1 Describe macros: Calling a macro like a normal SPL command without backticks.

• 7.1 Describe macros: Keyword 'reusable SPL fragment' strongly points to a macro.

Workflow actions turn event context into a user-triggered next step. Choose GET for opening/retrieving an external web resource, POST for submitting data to an external endpoint, and Search for launching another Splunk search. GET workflow actions construct a browser URL from event field values. The exam focuses on the Settings path, `$field

• 8.1 Describe the function of GET, POST, and Search workflow actions: Using POST merely because several fields are involved even though the goal is to open a browser link.

• 8.1 Describe the function of GET, POST, and Search workflow actions: External link/retrieval → GET; external submission → POST; Splunk secondary search → Search.

A data model is a permissionable, hierarchical search-time mapping of semantic knowledge about datasets. Pivot uses those modeled datasets and exposed fields to generate searches, reports, and visualizations without requiring the Pivot user to write SPL directly. Know the Data Model Editor's dataset types, field categories, field types, required/optional and hidden/shown settings, inheritance, and field ordering behavior. Creating a data model means defining appropriate root/child datasets, constraints, fields, hierarchy, visibility/required settings, permissions, and—when justified—acceleration.

• 9.1 Describe the relationship between data models and pivot: Calling a data model a saved Pivot report.

• 9.1 Describe the relationship between data models and pivot: Model = semantic/hierarchical definition; Pivot = user interface/reporting consumer.

The Splunk Common Information Model (CIM) provides shared field names, event-category tags, and data-model conventions so heterogeneous source data can be searched and reported consistently. Normalization is primarily a search-time knowledge-management process. The CIM Add-On packages normalized-domain knowledge, especially preconfigured data models and supporting knowledge objects/tooling used to describe and validate common information-model semantics. CIM normalization is a repeatable search-time mapping process: choose the target dataset, satisfy its event-category constraints/tags, map/extract required fields, normalize values, then validate against the model.

• 10.1 Describe the Splunk CIM: Thinking CIM requires re-indexing every source into one canonical raw format.

• 10.1 Describe the Splunk CIM: Think 'shared search-time vocabulary + event categories.'