Splunk® Enterprise

Knowledge Manager Manual

Download manual as PDF

This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Design data models and objects

In Splunk Web, you use the Data Model Editor to design new data models and edit existing models. This topic shows you how to use the Data Model Editor to create and edit:

  • Data model object hierarchies
  • Root event objects
  • Root search objects
  • Root transaction objects
  • Child objects
  • The five types of object attributes:
    • Auto-extract
    • Eval expression
    • Lookup
    • Regular expression
    • Geo IP

Note: This topic will not spend much time explaining data model concepts. If you have not worked with data models in Splunk Enterprise before you may find it helpful to review the topic "About data models," in this manual. It provides a lot of background detail around what data models and data model objects actually are and how they work.

For information about creating and managing new data models, see "Manage data models," in this manual. Aside from creating new data models via the Data Models management page, this topic will also show you how to manage data model permissions and acceleration.

The Data Model Editor

Data models are collections of data model objects arranged in hierarchical structures. To design a new data model or redesign an existing data model, you go to the Data Model Editor. In the Data Model Editor, you can create objects for your data model, define their constraints and attributes, arrange them in logical object hierarchies, and maintain them.

Bubbles dm editobjpage.png

Manage objects in an existing data model

There are five ways to access the Data Model Editor for an existing data model:

  • In Pivot, on the Select a Data Model page, expand the row for a data model to reveal detail information for that model. Click Edit Objects to access the Data Model Editor for that data model.
  • In Pivot, select a data model. On the Select an Object page for that data model, click Edit Objects.
  • In Pivot, select a data model and then select an object from that data model. On the New Pivot page, click Data Source and select Edit Object.
  • Navigate to System > Data Models, click the Edit dropdown for the data model you want to edit, and select Edit Objects.
    • Alternatively, navigate to System > Data Models, expand the row for the data model you want to edit, and select Edit for the listed objects.

Note: You can only edit a specific data model if your permissions enable you to do so.

Add a root event object to a data model

Data models are typically composed chiefly of object hierarchies built on root event objects. Each root event object represents a set of data that is defined by a constraint: a simple search that filters out events that aren't relevant to the object. Constraints look like the first part of a search, before pipe characters and additional search commands are added.

Constraints for root event objects are usually designed to return a fairly wide range of data. A large dataset gives you something to work with when you associate child event objects with the root event object, as each child event object adds an additional constraint to the ones it inherits from its ancestor objects, narrowing down the dataset that it represents.

Note: For more information on how constraints work to narrow down datasets in an object hierarchy, see the section on object constraints in the "About data models" topic, in this manual.

To add an root event object to your data model, click Add Object in the Data Model Editor and select Root Event. This takes you to the Add Event Object page.

Bubb dm addeventobject.png

Give the root event object an Object Name, Object ID, and one or more Constraints.

The Object Name field can accept any character, as well as spaces. It's what you'll see on the Choose an Object page and other places where data model objects are listed.

The Object ID must be a unique identifier for the object. It cannot contain spaces or any characters that aren't alphanumeric, underscores, or hyphens (a-z, A-Z, 0-9, _, or -). Spaces between characters are also not allowed. Once you save the Object ID, value you can't edit it.

After you provide Constraints for the root event object you can click Preview to test whether the constraints you've supplied return the kinds of events you want.

Add a root transaction object to a data model

Root transaction objects enable you to create object hierarchies that are based on a dataset made up of transaction events. A transaction event is actually a collection of conceptually-related events that spans time, such as all website access events related to a single customer hotel reservation session, or all events related to a firewall intrusion incident. When you define a root transaction object, you define the transaction that pulls out a set of transaction events.

Read up on transactions and the transaction command if you're unfamiliar with how they work. Get started at About transactions, in the Search Manual. Get detail information on the transaction command at its entry in the Search Reference.

Note: Root transaction objects and their children do not benefit from data model acceleration.

To add a root transaction object to your data model, click Add Object in the Data Model Editor and select Root Transaction. This takes you to the Add Transaction Object page.

Bubbles dm addtransobj.png

Root transaction object definitions require an Object Name and Object ID and at least one Group Object. The Group by, Max Pause, and Max Span fields are optional, but the transaction definition is incomplete until at least one of those three fields is defined.

The Object ID must be a unique identifier for the object. It cannot contain spaces or any characters that aren't alphanumeric, underscores, or hyphens (a-z, A-Z, 0-9, _, or -). Spaces between characters are also not allowed. Once you save the Object ID value you can't edit it.

All root transaction object definitions require one or more Group Object names to define the pool of data from which the transaction object will derive its transactions. There are restrictions on what you can add under Group Object, however. Group Object can contain one of the following three options:

  • One or more event objects (either root event objects or child event objects)
  • One transaction object (either root or child)
  • One search object (either root or child)

In addition, you are restricted to objects that exist within the currently selected data model.

If you're familiar with how the transaction command works, you can think of the Group Objects as the way we provide the portion of the search string that appears before the transaction command. Take the example presented in the preceding screenshot, where we've added the Apache Access Search object to the definition of the root transaction object Web Session. Apache Access Search represents a set of successful webserver access events--its two constraints are status < 600 and sourcetype = access_* OR source = *.log. So the start of the transaction search that this root transaction object represents would be:

status<600 sourcetype=access_* OR source=*.log | transaction...

Now we only have to define the rest of the transaction argument.

Group by is where you can list fields for the root transaction object. If you choose two or more fields you're saying that the transaction will find events that share the same values for the chosen fields. The Group by dropdown does not appear until you identify at least one Group Object, and it only allows you to choose attributes that belong to the group object or objects that you have listed. When you have multiple objects selected, Group by only allows you to select from the set of attributes that are shared by all of the selected objects.

Note: While the Group by fields are attributes that belong to the Group Object(s) selected for the root transaction object, selecting them does not add them to the root transaction object as attributes. They are used to define the transaction.

You can change the list order of Group by fields. In edge cases where you have events within a transaction with the same timestamp, field reordering can affect how Splunk Enterprise sorts those events.

The duration-based options, Max Pause and Max Span, have the same function as the maxpause and maxspan arguments in the transaction search command. Both of these settings help you to ensure that the transactions found by your transaction object do not contain erroneous events.

The Max Pause field enables you to set a limit to the amount of time that can separate the events that make up a single transaction. For example, you may know that a certain transaction shouldn't contain any events with timestamps that are more than 20 seconds apart--if a matching event does come in more than 20 seconds after the last one, it might signal the start of a new transaction event, or it could just be an outlying event. To ensure that your transaction object returns transactions that follow this rule, set the value of Max Pause to 20 seconds.

The Max Span field enables you to control the overall span of time that a particular transaction encompasses. For example, if you know that the transactions you're looking for never span more than 5 minutes, you could set 5 minutes as the Max Span value for the corresponding transaction object.

So to return to our example in the screenshot, if we were to represent transaction object as a search string, it would look like this:

status<600 sourcetype=access_* OR source=*.log | transaction clientip useragent maxspan=1m

This looks through the data returned by the status<600 sourcetype=access_* OR source=*.log and seeks out "web session" transactions: transactional groupings of events with identical values for clientip and useragent where the duration of the transaction as a whole does not exceed one minute.

After you define your root transaction object's Group by you can click Preview to test whether the constraints you've supplied return the kinds of events you want.

Add a root search object to a data model

Root search objects enable you to create object hierarchies where the base dataset is the result of an arbitrary transforming search--a search that uses statistical commands to define a base dataset where one or more fields aggregate over the entire dataset.

The results returned by root search objects and their children are essentially table rows (unless the search is not a transforming search, in which case events are returned, just as they are for root event objects and their children).

Note: We suggest that whenever possible, you avoid using root search objects to create an object hierarchy, because root search objects and their children do not benefit from data model acceleration. There are many kinds of searches that can be set up as root event objects. For more information, see "When not to create root search objects," below.

To add a root search object to your data model, click Add Object in the Data Model Editor and select Root Search. This takes you to the Add Search Object page.

Bubbles dm addsearchobj.png

Give the root search object an Object Name, Object ID, and search string. To preview the results of the search in the section at the bottom of the page, click the magnifying glass icon to run the search, or just hit return on your keyboard while your cursor is in the search bar.

The Object Name field can accept any character, as well as spaces. It's what you'll see on the Choose an Object page and other places where data model objects are listed.

The Object ID must be a unique identifier for the object. It cannot contain spaces or any characters that aren't alphanumeric, underscores, or hyphens (a-z, A-Z, 0-9, _, or -). Spaces between characters are also not allowed. Once you save the Object ID, value you can't edit it.

For more information about designing search strings, see the Search Manual.

When not to create root search objects

As we stated above, you should avoid creating root search objects if you can design an root event object that will do the job. Root event objects have a major advantage over root search objects: Event object hierarchies can be accelerated, while search object hierarchies cannot. If you accelerate your data model and then select an object from that model to run a Pivot operation with (such as the generation of a chart visualization), the operation will complete much faster if you can use an object from an event object hierarchy than it would if you used an object from a search object hierarchy.

Don't create a root search object for your search if:

  • The search only involves the eval, rex, or lookup commands (or some combination of those three commands). You can set this sort of search up as an root event search with the help of the Eval Expression, Regular Expression, and Lookup attributes.
For example, say you have this search:

sourcetype=access_* | eval userid=clientip+useragent

You can utilize this search in a root event object by first defining its constraint as sourcetype=access_*. Save the object, and then, in the Data Model Editor for that object, add an Eval Expression attribute to the object using userid=clientip+useragent as the attribute definition.
  • You would like to get the benefits of data model acceleration but you want to use commands that can be configured in .conf files, so they run automatically as events are indexed. Many commands that extract fields can be configured in this way, meaning that the fields they extract will be available as auto-extracted attributes when you define the data model.
    • Many commands can be set up in props.conf and transforms.conf to aid in field extraction.
    • Additionally, if you typically use the multikv command to extract fields from .csv files and the like, you can configure multikv.conf to extract fields as the .csv file is indexed.
    • If you do not need to accelerate the underlying root-level object, you can create a root search object that uses these commands in its defining search.
  • You want to create line or area charts in Pivot. These chart types require that _time be an auto-extracted attribute. Because root search objects are designed to return table rows for transforming searches, they do not auto-extract _time as an attribute.
  • The search is a simple transaction search. Set it up as a root transaction object.

You should create root search objects for any searches that do not map directly to Splunk events. In other words, searches that involve input or output that is not in the format of an event. This includes searches that:

  • Make use of transforming commands such as stats, chart, and timechart. Transforming commands organize the data they return into tables rather than event lists.
  • Use other commands that do not return events.
  • Pull in data from external non-Splunk sources using a command other than lookup. This data cannot be guaranteed to have default fields like host, source, sourcetype, or _time and therefore might not be event-mappable. An example would be using the inputcsv command to get information from an external .csv file.

Add a child object to a data model

You can add child objects to root objects and other child objects. A child object inherits all of the constraints and attributes that belong to its parent object. A single object can be associated with multiple child objects

When you define a new child object, you give it one or more additional constraints, to further focus the dataset that the object represents. For example, if your Web Intelligence data model has a root event object called HTTP Request that captures all webserver access events, you could give it three child event objects: HTTP Success, HTTP Error, and HTTP Redirect. Each child event object focuses on a specific subset of the HTTP Request dataset:

  • The child event object HTTP Success uses the additional constraint status = 2* to focus on successful webserver access events.
  • HTTP Error uses the additional constraint status = 4* to focus on failed webserver access events.
  • HTTP Redirect uses the additional constraint status = 3* to focus on redirected webserver access events.

The addition of attributes beyond those that are inherited from the parent object is optional. For more information about attribute definition, see "Manage Object attributes with the Data Model Editor," below.

To add a child object to your data model, select the parent object in the left-hand object hierarchy, click Add Object in the Data Model Editor, and select Child. This takes you to the Add Child Object page.

Bubbles dm addchildobj.png

Give the child object an Object Name and Object ID. The Object ID must be a unique identifier for the object. It cannot contain spaces or any characters that aren't alphanumeric, underscores, or hyphens (a-z, A-Z, 0-9, _, or -). Spaces between characters are also not allowed. Once you save the Object ID value you can't edit it.

After you define a Constraint for the child object you can click Preview to test whether the constraints you've supplied return the kinds of events you want.

Manage object attributes with the Data Model Editor

The Data Model Editor enables you to update any part of an object's definition that isn't inherited from a parent object. The Data Model Editor is also where you'll go to add attributes to an object and edit or remove those added attributes (you can't change attributes that have been inherited).

In the Data Model Editor you can select an object and:

  • Rename the object.
  • Update the object definition: the constraint (if you're working with a root event object or any kind of child object), the search (if you're working with a root search object), or the transaction details (if you're working with a root transaction object).
  • Add attributes that belong to the object and edit or delete existing attributes owned by the object.
  • Delete the object.

In this subtopic we'll focus on adding and editing object attributes. To learn more about editing constraints, searches, and transaction definitions, see the previous sections of this topic that deal with object addition and definition.

You use attributes to provide the set of fields that Pivot users work with to define and generate a pivot report. You can choose from these attribute types:

  • Auto-extracted: Fields that Splunk Enterprise extracts at search time. They can be default fields (fields that Splunk Enterprise automatically extracts) or manual field extractions (extractions that you have defined in Manager or configured in props.conf and--in some cases--transforms.conf).
    • Note: Auto-extracted attributes can only be added to root objects. Child objects can only inherit auto-extracted attributes from root objects; they cannot have auto-extracted attributes of their own.
  • Eval Expression: A field derived from a eval expression that you enter in the attribute definition. These expressions can use fields defined in attributes that are listed above the eval expression attribute (such as auto-extracted attributes or regular expression attributes).
  • Lookup: A field that is added to the events in the object dataset with the help of a lookup.
  • Regular Expression: A field that is extracted from the object event data using a regular expression that you provide. A regular expression attribute definition can use a regular expression that extracts multiple fields; each field will appear in the object attribute list as a separate regular expression attribute.
  • GeoIP: A specific type of lookup that adds geographical fields, such as latitude, longitude, country, and city to events in the object dataset that have valid ip address fields. Useful for map-related visualizations.

Attribute list order is important as Splunk Enterprise processes attributes in descending order from top to bottom. You can set up chained attributes where the values of auto-extracted Field attributes at the top of the attribute list figure in the definition of an eval expression attribute that appears later in the list. The field that this eval creates could in turn be used as input for a lookup attribute.

Note: Auto-extracted attributes are always listed first, and attributes of other types are added to the bottom of the attribute list initially in the order that they are created. You can rearrange the list order of those other attribute types so they chain properly. In the chained attribute example above, the eval expression attribute will work fine as-is because the auto-extracted attributes that chain to it are guaranteed to appear above it. But for the lookup attribute to work correctly you will need to ensure that the eval expression attribute that chains to it is listed above it. If necessary you can manually rearrange their list order.

For a broader overview of object attributes--what they are, how they work, and why you need them--read the subsection on them in "About data models," in this manual.

Options available for all attribute types

When you add or edit an Auto-extract, Eval Expression, Lookup, or Regular Expression attribute type you can optionally change its Name, redefine its Type, and set its Flag. (You can't set these values for fields added by the Geo IP attribute.)

Note: In the case of auto-extracted field attributes, changing the Name of the field won't change how the field is named in the Splunk Enterprise index--it just renames it in the context of this data model.

Splunk Enterprise will try to determine the attribute Type, but you can select a different Type value if Splunk Enterprise has misidentified it. For example, based on available values for an auto-extracted field attribute, Splunk Enterprise may decide it is a Number when you know that it is in fact a string type field. You can change the Type value to String if this is the case.

When you define or edit attributes, you can use the Flag drop-down to determine whether each attribute you add to an object is Required, Optional, Hidden, or Hidden & Required:

  • Required: Means that the attribute (the extracted field) must appear in every event represented by the object. This will filter out any event that does not have the attribute. In effect this is another type of constraint on top of any formal constraints you've associated with the object.
  • Optional: Means that the attribute doesn't have to appear in every event represented by the object. The attribute may appear in some of the object events and not others.
  • Hidden: Means that the attribute will not be displayed to Pivot users when they select the object in a Pivot context.
    • You can use this flag to ensure that each object in your data model exposes only a subset of its inherited and added attributes, so that your users only have to deal with attributes that apply to the dataset represented by the object. Parent objects and child objects can expose entirely different sets of attributes.
    • You may use this for field attributes that are only being added to the object because they're used to define another attribute, such as a an eval expression attribute (see below).
    • If you just choose Hidden, the attribute is Optional as well.
  • Hidden & Required: Means that the attribute is both hidden and required.

In the Data Model Editor you can also control whether the listed attributes are hidden or shown and required or optional by clicking the Hide/Show and Make Required/Make Optional toggles for each attribute.

In the Data Model Editor view, inherited attributes that are hidden and/or optional are automatically listed below attributes that are visible and optional.

Add an auto-extract attribute to your object

In the Data Model Editor, select the root object you'd like to add an attribute to and click Add Attribute. Select Auto-extract to define an auto-extract attribute.

Note: Child objects cannot have auto-extracted attributes of their own; they can only inherit them from root objects.

The Add Auto-extracted Field dialog opens. It provides a list of all of the fields that Splunk Enterprise has not already auto-extracted for this object. (In other words, auto-extracted fields that the object has inherited from its ancestor objects will not appear in the list.) Select each field that you'd like to add to your object as a "Field" attribute. You can select the checkbox in the header to select all available fields (and deselect to deselect all available fields).

When you select a field in the Add Auto-extracted field dialog, you are given the ability to rename it, identify its Type, and determine whether it is Optional, Required, Hidden, or Hidden and Required.

Expand a field row for a field to see its top 10 sample values.

Click Save to add the selected fields to your object as auto-extracted attributes.

Add an eval expression attribute to your object

In the Data Model Editor, select the object you'd like to add an attribute to and click Add Attribute. Select Eval Expression to define an eval expression attribute.

6.0 dm editor eval attribute.png

Enter the Eval Expression that defines the attribute value. The expression should be formatted in exactly the same way that you format eval expressions in search strings. For more information about the eval command and the formatting of eval expressions, see the eval page as well as the topic "Functions for eval and where" in the Search Reference.

Note: The Eval Expression text area should just contain the <eval-expression> portion of the eval syntax. There's no need to type the full syntax used in search (eval <eval-field>=<eval-expression>).

Under Attribute enter the attribute Field Name (the name of the attribute in your object data) and the attribute Display Name (the name of the attribute in the data model, and the attribute name that your Pivot users see when they create pivots).

Note: The attribute Field Name cannot include the following characters: "'{}.

Define the attribute Type and set its Flag.

You can chain eval expression attributes together in a manner similar to that of calculated fields, where an eval expression attribute definition makes use of attributes that have already been defined or calculated, including other eval expression attributes. You must place the prerequisite attributes above the final eval expression attribute in the object's attribute order, because Splunk Enterprise processes the attributes from top to bottom. In other words, if you have a calculation B that depends on another calculation A, make sure that calculation A comes before calculation B in the attribute order.

You can use attributes of any type in an eval expression attribute definition. For example, you could create an eval expression that uses the names of an auto-extracted attribute and another eval expression attribute (it'll work as long as those attributes are listed above the one you're creating).

When you create an eval expression attribute that uses the values of other attributes in its definition, you can optionally "hide" those other attributes (by setting Flag to Hidden) so that only the final eval expression value is available to your Pivot users.

Add a lookup attribute to your object

In the Data Model Editor, select the object you'd like to add an attribute to and click Add Attribute. Select Lookup to define a lookup attribute.

In order to create a lookup attribute, you must have at least one lookup definition defined in System > Lookups > Lookup definitions. The lookup definition tells Splunk Enterprise where the lookup table is and how to connect to it--it can either connect directly to a table-based CSV file that you upload via Splunk Web, or it can use a Python script to connect to an external lookup table. Once the lookup definition is in place, Splunk Enterprise can match the values of the attribute you choose to values of a field in the lookup table and then return corresponding field/value combinations and apply them to your object as lookup attributes.

Note: Any lookup table files and lookup definitions that you use in your lookup attribute must have the same permissions as the data model. If the data model's permissions are global (i.e., shared to "all apps"), but the lookup table file or definition is private, the attribute will be broken. (In general data models and their associated lookup table files and definitions should all be shared globally to all apps.)

6.0 dm editor lookup attribute.png

For more information about creating lookup definitions (as well as uploading CSV files), see "Use field lookups to add information to your events".

  1. Under Lookup Table, select the lookup table that you intend to match an input attribute to. All of the values in the Lookup Table list are lookup definitions that have been defined in Manager. Next, you'll define your lookup table input (matching an object attribute to a field in a lookup table).
  2. Under Input, select the object Attribute that you want to match to the field in the lookup table you've chosen.
  3. Under Field in Lookup provide the name of the field that you want to match your attribute to.
  4. Now you'll define your lookup table Output (identify the lookup table fields that you want to add to your object as a lookup attributes). Under Field in Lookup, provide the name of a field that exists in the lookup table that you want to add to the events in your object.
  5. Under Field Name, provide the field name that the lookup attribute should have in your data. The Field Name cannot include the following characters: "'{}.
  6. Under Display Name provide the display name for the lookup attribute in the data model and in Pivot.
  7. Lastly, for each lookup attribute you define, set the appropriate Type and Flags value as appropriate. See the subsection "Options available for all attribute types," above, for more information about these fields.

You must define at least one output Attribute in order for the lookup attribute definition to be valid.

Example of a lookup attribute setup

For example, you may have an ipv4-type attribute in your object named dest_IP. You'd like to create some lookup attributes that look at the dest_ip values in the object events and add the matching dest_city and dest_country fields to those events from an external DNS lookup table. You'll need to create lookup attributes named Destination City and Destination Country. Here's what you do:

  1. In Manager, set up a lookup definition that points at an external DNS table that contains the cities and countries for each possible IP address. Call this lookup definition dnslookup.
  2. Select the object you want to add the lookup attributes to, click Add Attribute and select Lookup.
  3. Under Lookup Table select dnslookup.
  4. For the input Attribute, select dest_ip.
  5. The field that corresponds to dest_ip in the DNS lookup table is ip_address. Enter ip_address for Field in Lookup.
  6. On the Output side, set up two lookup attributes. The first attribute should have a Field in Lookup value of ip_city, a Field Name value of dest_city, and a Display Name value of Destination City. The second attribute should have a Field in Lookup value of ip_country, a Field Name value of dest_country, and a Display Field name of Destination Country.
  7. Give both lookup attributes a Type value of String and a Flag value of Optional.

Add a regular expression attribute to your object

In the Data Model Editor, select the object you'd like to add an attribute to and click Add Attribute. Select Regular Expression to define a regular expression attribute.

The Add Attributes with a Regular Expression page enables you to set up field extractions with regular expressions. Each named group in the regular expression you provide will be extracted as a separate attribute.

6.0 dm editor regex attribute.png

Under Extract From select the attribute that you want to extract the fields from. Then provide a Regular Expression. The regular expression must have at least one named group.

Note: Regular expression attributes currently do not support sed mode or sed expressions.

After you provide a regular expression, the named group or groups will appear listed under Attribute(s). You can optionally provide different Display Name values for the attributes; this is how they'll appear in the data model attribute list and it's what Pivot users will see when they build a pivot. Correct the Type values for the attributes if necessary and set the attribute Flags to values that are appropriate for your needs.

Note: Attribute field names cannot include the following characters: "'{}.

For a primer on regular expression syntax and usage, see Regular-Expressions.info. You can test your regex by using it in a search with the rex search command. Splunk Enterprise also maintains a list of useful third-party tools for writing and testing regular expressions.

Add a Geo IP attribute to your object

Note: You can only define a Geo IP attribute for an object if there is an ipv4 type attribute already defined in the object's attribute list. The ipv4 attribute must appear above the location for the Geo IP attribute, and it cannot already be in use for a different Geo IP attribute calculation.

In the Data Model Editor, select the object you'd like to add an attribute to and click Add Attribute. Select Geo IP to define a Geo IP attribute.

The Geo IP attribute is a type of lookup. It reads the IP address values in your object's events and can add the related longitude, latitude, city, region, and country values to those events.

6.0 dm editor geoip attribute.png

On the "Add Geo Attributes with an IP Lookup" page choose the IP attribute that you want to match, if more than one exists for the selected object.

Then select the attributes that you want to add to your object (select the Include checkboxes). Under Display Name you can optionally rename them.

Note: Geo IP attributes are added to your object as required attributes, and their Type values are predetermined. You cannot change these values.

Some best practices for data model design

It can take some trial and error to determine the data model designs that work for you. Here are some tips that can get you off to a running start.

  • Use root event objects whenever possible to take advantage of the benefits of data model acceleration (and to benefit from their ease of optimization).
  • Minimize object hierarchy depth whenever possible. Constraint-based filtering is less efficient deeper down the tree.
  • Put the root event object with the deepest tree (and most matching results) first. Data model acceleration applies only to the first root event object and its children.
  • When defining constraints for a root event object that will be accelerated, when possible include the index or indexes it is selecting from. Data model acceleration efficiency is improved when the data model isn't searching across all of your indexes (this is what it does by default when indexes are not specified).
  • Use attribute flags to selectively expose small groups of attributes for each object. You can expose and hide different attributes for different objects. A child attribute can expose an entirely different set of attributes than those exposed by its parent. Your Pivot users will benefit from this selection by not having to deal with a bewildering array of attributes whenever they set out to make a pivot chart or table. Instead they'll see only those attributes that make sense in the context of the object they've chosen.
  • Reverse-engineer your existing dashboards and searches into data models. This can be a way to quickly get started with data models. Dashboards built with pivot-derived panels are easier to maintain.
  • When designing a new data model, first try to understand what your Pivot users hope to be able to do with it. Work backwards from there. The structure of your model should be determined by your users' needs and expectations.
PREVIOUS
Manage data models
  NEXT
Overview of summary-based search and pivot acceleration

This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters