Splunk® Enterprise

Knowledge Manager Manual

Configure event types in eventtypes.conf

You can add new event types and update existing event types by configuring eventtypes.conf. There are a few default event types defined in $SPLUNK_HOME/etc/system/default/eventtypes.conf. The Splunk software adds any event types you create through Splunk Web to $SPLUNK_HOME/etc/users/<your-username>/<app>/local/eventtypes.conf, where <app> is your current app context.

Important event type definition restrictions

You cannot base an event type on a search that:

  • Includes a pipe operator after a simple search.
  • Includes a subsearch.
  • Is defined by a simple search that uses the savedsearch command to reference a report name. For example, if you have a report named failed_login_search, you should not use this search to define the event type: | savedsearch failed_login_search. In this case you should instead use the search string that defines failed_login_search as the definition of the event type.

This last point is more of a best practice than a strict limitation. You want to avoid situations where the search string underneath failed_login_search is modified by another user at a future date, possibly in a way that breaks the event type. You have more control over the ongoing validity of the event type if you use actual search strings in its definition.

Configure event types

When you run a search, you can save that search as an event type. Event types usually represent searches that return a specific type of event, or that return a useful variety of events.

Prerequisites
Review

Steps

  1. Make changes to event types in eventtypes.conf in $SPLUNK_HOME/etc/system/local/ or your own custom app directory in $SPLUNK_HOME/etc/apps/ . Use $SPLUNK_HOME/etc/system/README/eventtypes.conf.example as an example, or create your own eventtypes.conf.
  2. (Optional) Configure a search term for this event type.
  3. (Optional) Enter a human-readable description of the event type.
  4. (Optional) Give the event type a priority.
  5. (Optional) Give the event type a color.

Event type syntax

Use the following format when you define an event type in eventtypes.conf.

[$EVENTTYPE]
disabled = <1|0>
search = <string>
description = <string>
priority = <integer>
color = <string>

The $EVENTTYPE is the header and the name of your event type. You can have any number of event types, each represented by a stanza and any number of the following attribute-value pairs.

Note: If the name of the event type includes field names surrounded by the percent character (for example, %$FIELD%) then the value of $FIELD is substituted at search time into the event type name for that event. For example, an event type with the header [cisco-%code%] that has code=432 becomes labeled [cisco-432].

Attribute Description
disabled Toggle event type on or off. Set to 1 to disable the event type.
search Search terms for this event type. For example, error OR warn.
description Optional human-readable description of the event type.
priority Specifies the order in which matching event types are displayed for an event. 1 is the highest, and 10 is the lowest.
color Color for this event type. The supported colors are: none, et_blue, et_green, et_magenta, et_orange, et_purple, et_red, et_sky, et_teal, et_yellow.


Note: You can tag eventtype field values the same way you tag any other field-value combination. See the tags.conf spec file for more information.

Example

Here are two event types; one is called web, and the other is called fatal.

[web]
search = html OR http OR https OR css OR htm OR html OR shtml OR xls OR cgi

[fatal]
search = FATAL

Disable event types

Disable an event type by adding disabled = 1 to the event type stanza eventtypes.conf:

[$EVENTTYPE]
disabled = 1

$EVENTTYPE is the name of the event type you wish to disable.

So if you want to disable the web event type, add the following entry to its stanza:

[web]
disabled = 1
Last modified on 20 December, 2019
Automatically find and build event types   Configure event type templates

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.11, 8.1.13, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 9.4.0, 8.1.10, 8.1.12, 8.1.14, 8.1.2


Was this topic useful?







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