Splunk® Enterprise

Knowledge Manager Manual

Acrobat logo Download manual as PDF

Splunk Enterprise version 6.x is no longer supported as of October 23, 2019. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Acrobat logo Download topic as PDF

Define object attributes

In this topic we talk about adding and editing attributes of data model objects. Object attributes are fields that are associated with the dataset that an object represents. They provide the set of fields that your Pivot users work with when they define and generate pivot reports.

Attributes can be present within the object dataset, or they can be derived and added to the dataset through the use of lookups and eval expressions.

You use the Data Model Editor to create and manage object attributes. It enables you to:

  • Create new attributes.
  • Update or delete existing attributes that aren't inherited.
  • Override certain settings for inherited attributes.

Note: This topic will not cover the concepts behind object attributes in detail. If you have not worked with data model attributes up to this point, you should review the topic "About data models," in this manual.

You can also use the Data Model Editor to build out data model object hierarchies, define object datasets (by providing constraints, search strings, or transaction definitions), rename objects, and delete objects. For more information about using the Data Model Editor to perform these tasks, see "Design data models and objects."

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 also shows you how to manage data model permissions and acceleration.

Overview of object attributes

Object attributes provide the set of fields that Pivot users work with to define and generate a pivot report.

6.1 add attribute list opts.png

You can define five different types of attributes for the objects in your data model:

  • Auto-extracted: These represent fields that are extracted at index time and search time. You can only add auto-extracted attributes to root objects. Child objects can only inherit them, and they cannot add new auto-extracted attributes of their own. Auto-extracted attributes can include:
    • Fields that are extracted automatically, like uri or version. This includes fields indexed through structured data inputs for CSV, IIS, and JSON files.
    • Field extractions, lookups, or calculated fields that you have defined in Settings or configured in props.conf.
    • Fields that you have manually added to the attribute because they aren't currently in the object dataset, but should be in the future. Can include fields that are added to the object dataset by generating commands such as inputcsv or dbinspect.
  • Eval Expression: A field derived from a eval expression that you enter in the attribute definition. Eval expressions often involve one or more extracted fields.
  • Lookup: A field that is added to the events in the object dataset with the help of a lookup that you configure in the attribute definition. When you define a lookup attribute you can use any lookup that you have defined in Settings and associate it with any other attribute that has already been associated with that same object.
  • Regular Expression: A field that is extracted from the object event data using a regular expression that you provide in the attribute definition.
  • 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.

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.

Attribute categories

The Data Model Editor groups attributes into three categories:

  • Inherited - All objects have at least a few inherited attributes. Child objects inherit all of the attributes that belong to their parent object. Root event, search, and transaction objects have a default set of inherited attributes.
  • Extracted - Any auto-extracted attribute that has been added to an object appears in this category.
  • Calculated - Any attribute that is derived through a calculation or lookup appears in this category. When you add Eval Expression, Regular Expression, Lookup, and Geo IP attribute types to an object, they appear in this attribute category.

6.1 dm attributes.png

Attribute order and attribute chaining

The Data Model Editor lets you rearrange the order of calculated attributes. This is useful when you have a set of attributes that must be processed in a specific order, because attributes are processed in descending order from the top of the list to the bottom.

For example, you can design an Eval Expression attribute that uses the values of two auto-extracted attributes. extracted attributes precede calculated attributes, so in this case the attributes would be processed in the correct order without any work on your part. But you might also use the eval expression attribute as input for a lookup attribute. Because Eval Expression attributes and Lookup attributes are both categorized as calculated attributes by the Data Model Editor, you would want to make sure that you order the calculated attribute list so that the Eval Expression attribute appears above the Lookup attribute.

So the order of these attributes would be:

  • Auto Extracted Attribute 1
  • Auto Extracted Attribute 2
  • Eval Expression Attribute (calculates a field with the values of the two Auto-Extracted attributes)
  • Lookup Attribute (uses the Eval Expression attribute as an input field)

Marking attributes as hidden or required

All object attributes are shown and optional by default.

  • A shown attribute is visible and available to Pivot users when they are in the context of the object to which the attribute belongs. For example, say the url attribute is marked as shown for the HTTP Requests object. When a user enters Pivot and selects the HTTP Requests object, they can use the url attribute when they define a pivot report.
  • An optional attribute is not required to be present in every event in the dataset represented by its object. This means that there potentially can be many events in the object dataset that do not contain the attribute.

You can change these settings to hidden and required, respectively. When you do this the attribute will be marked as hidden and/or required in the object attribute list.

  • A hidden attribute is not displayed to Pivot users when they select the object in a Pivot context. They will be unable to use it for the purpose of Pivot report definition.
    • This setting lets you expose different subsets of attributes for each object in your data model, even if all of the objects inherit the same set of attributes from a single parent object. This helps to ensure that your Pivot users only engage with attributes that make sense given the context of the dataset represented by the object.
    • You can hide field attributes that are only being added to the object because they're used to define another attribute (see "Attribute order and attribute chaining," above). There may be no need for your Pivot users to engage with the first attributes in an attribute chain.
  • A required attribute must appear in every event represented by the object. This filters 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.

These attribute settings are specific to each object in your data model. This means you can have the ip_address attribute set to Required in a parent object but still set as optional in the child objects that descend from that parent object. Even if all of the objects in a data model have the same attributes (meaning the attributes are set in the topmost root object and then simply inherited to all the other objects in the hierarchy), the attributes that are marked hidden or required can be different from object to object in that data model.

Note: There is one exception to your ability to provide different "shown/hidden" and "optional/required" settings for the same attribute across different objects in a data model. You cannot update these settings for inherited attributes that are categorized as "Calculated" attributes in the parent object in which they first appear. For this kind of attribute you can only change the setting by updating the attributes in that parent object. Your changes will be replicated through the child objects that descend from that parent object.

You can set these values for extracted and calculated attributes when you first define them. You can also edit attribute names or types after they've been defined.

1. Click Override for an attribute in the Inherited category or Edit for an attribute in the Extracted and Calculated categories.

2. Change the value of the Flag field to the appropriate value.

3. Click Save to save your changes.

With the Bulk Edit list you can change the "shown/hidden" and "optional/required" values for multiple attributes at once.

1. Select the attributes you want to edit.

2. Click Bulk Edit and select either Optional, Required, Hidden, or Shown.

If you select either Required or Hidden the appropriate attributes update to display the selected status for the selected attributes. You cannot update these values for inherited attributes that are categorized as calculated attributes in the parent object in which they first appear. See the Note above for more information.

Enter or update attribute names and types

The Data Model Editor lets you give attributes in the Extracted and Calculated categories a display Name of your choice. It also lets you determine the Type for such attributes, even in cases where a Type value has been automatically assigned to the attribute.

Splunk software automatically assigns a type to auto-extracted attributes. If an auto-extracted attribute's Type value is assigned incorrectly, you can provide the correct one. For example, based on available values for an auto-extracted field attribute, Splunk software may decide it is a Number type attribute when you know that it is in fact a String type. You can change the Type value to String if this is the case.

Changing the display Name of an auto-extracted attribute won't change how the associated field is named in the index--it just renames it in the context of this data model.

1. Click Edit for the attribute whose Name or Type you would like to update.

2. Update the Name or change the Type. Name values cannot contain asterisk characters.

3. Click Save to save your changes.

Use the Bulk Edit list to give multiple attributes the same Type value.

1. Select the attributes you want to edit.

2. Click Bulk Edit and select either Boolean, IPv4, Number, or String.

All of the selected attributes should have their Type value updated to the value you choose.

Note: You cannot change the Type value for inherited attributes. If you select any inherited attributes the Type values in the Bulk Edit list will be unavailable.

Last modified on 20 July, 2016
Design data models and objects
Add an auto-extracted attribute

This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11

Was this documentation topic helpful?

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