What does a data model search?

Splunk data models are really a group or set of specific information (referred to as objects) pulled together to create specific Splunk search strings, each used to generate a search that returns a particular dataset. That dataset, returned by the object you select, is governed by particular object constraints and attributes.

Data model objects

As I mentioned, data models are constructed of a series of objects and these objects will be one of four types – Event, Search, Transaction, or Child. They are arranged hierarchically with child objects inheriting from the parent objects that they are associated with.

• Event objects are the most common data model object, broadly representing a type of event. Event objects are typically defined by a constraint (which we will discuss next).
• Transaction objects enable you to create data models that represent transactions (groups of related events that span time) using fields that have already been added to the model via an event or search object, which means that you can't create data models that are composed only of transaction objects and their child objects. Before you create a transaction object, you must already have some event or search object trees in your model.
• Search objects use an arbitrary Splunk search that includes transforming commands to define the dataset that they represent.
• The most top-level objects in a data model are referred to as root objects, and each can be a parent object to many child objects. Splunk calls the relationship of a parent and child object an object tree. The data that this object tree represents is first selected by the root and then refined by each of its child objects.

Object constraining

All data model objects are defined by sets of constraints that will filter out information that is not pertinent to the object. A constraint may be a simple Splunk search (with no pipes or additional commands), a more complex search, or even a transaction. Constraints are inherited by child objects. Constraint inheritance ensures that each child object represents a subset of the data represented by its parent objects. So, for example, a data model may have a root object which defines a particular indexed source (sourcetype=speciallogs_*), while a child object of that root might narrow down that search to only the errors that appear in that datasource (error*). You might use this data model if you know that you only want to report on errors within the events that belong to the speciallogs sourcetype.

Attributes

Data model objects also include attributes, which are simply fields (exposed for use in reporting) associated with the dataset that the object represents. There are five types of object attributes: Auto-extracted (fields that Splunk derives at search time), eval expressions (field derived from an eval expression that you enter in the attribute definition), lookups (lookups add fields from external data sources such as CSV files and scripts), Regular Expressions (a field that is extracted from the object event data using a regular expression) and Geo IP (of lookup that adds geographical attributes, such as latitude, longitude, country, and city to events in the object dataset).

Attributes fall into one of three categories: inherited attributes (from the object's parent), extracted attributes (that you add to an object), or calculated (attributes that are the result of a calculation or a lookup).

When you define data model attributes, you can define (for each object in the data model) whether it is visible or hidden. Attributes are visible by default. This is particularly important if each object in your data model has many attributes but only a few are essential for your user's needs. Determining what attributes to include in a Splunk data model, and which attributes to expose, is a critical part of the overall design of the model. Typically, it's often helpful if each object exposes only the data that is relevant to that object, making it easier to understand and use for your average Splunk user.

In addition to attribute visibility, it is also possible to make any attribute either, required or optional. Indicating that an attribute is required means that every event represented by the object must have that attribute. When you define an attribute as optional, it means that the object may have events that do not have that attribute at all.