Read this first before upgrading to 3.0.x

3.0 introduced many significant improvements and new features across the entire Splunk product. Some of the improvements require that customers manually re-implement some of their 2.2.3 and previous configuration using 3.0 methods, as it would be impossible to create a one-size-fits-all automated conversion. We also strongly recommend that customers consider whether some of the new features should be leveraged to replace older deployment approaches. This page provides an overview of some of the major changes that administrators of 2.2.3 and previous deployments should understand prior to beginning an upgrade.

All bundles, all the time

To make Splunk configuration files easier to read, write and share, we moved a lot more of this data from .xml to .conf files and placed them within $SPLUNK_HOME/etc/bundles. This change will also support Splunk's deployment server as well as the product's integration with SplunkBase.

Additionally, some of the previously existing bundled .conf files have been renamed in order to match some terminology changes that we've made in order to make Splunk easier to understand.

Read the step-by-step upgrade instructions to learn how to migrate your existing configuration files to 3.0.

Terminology changes

We've changed how we refer to some key features of Splunk. You'll have an easier time following Splunk 3.0 documentation and language in the product itself if you review this quick list of changes:

The product name is now officially Splunk rather than Splunk Server; a Splunk server refers to an installation of Splunk.
Splunk Professional is now Splunk with an Enterprise license. Similarly you can have Splunk with a Free license.
Live Splunks are now alerts.
Saved Splunks are now saved searches and accordingly savedsplunks.conf is now simply savedsearches.conf.
Splunk-2-Splunk as an umbrella term for all distributed Splunk deployment features has been discontinued. We now refer simply to distributed search and data cloning and routing. Forwarding is a specific example of data routing.
Transforms is a new name for pattern-based transformations that used to be stored in regexes.conf. Accordingly regexes.conf is now transforms.conf and the attributes in props.conf now begin with TRANSFORMS- or REPORT-.
Segmenters is a new name for segmentation schemes used by Splunk's indexing processor, as you can now pick different segmentation schemes for events from different sources, sourcetypes or hosts.

Event typer changes

The event typer has completely changed for 3.0. If you have tagged event types in previous versions, your tags will no longer appear with your events. However, we believe you'll find that the new flexible event typing offers you a much better approach for classifying your data. We recommend that you use your previous tagging as a guideline to defining new event types and tags in the new system.

Before 3.0, a single eventtype:: value was assigned at index time based on a rigid algorithm that took into account keywords present in the event and the structure of the event. You could assign one or more tags at search time to the event type, but if the type itself was too granular (i.e. Splunk treated events you considered the same as different) or was too coarse (i.e. Splunk assigned a single eventtype:: value for two events that you considered very different, you had no ability to change that.

For 3.0 event types are now flexible, applied at search time, and transparently defined by search strings. The event type discovery process is now dynamic and takes into account patterns in your specific data to define event types for you that you can then edit. You can supplement or replace the discovered event types with your own definitions. Tags are still supported, but many of the reasons for tagging are now replaced by being able to define more appropriate event types.

Because of the depth of the event type changes, event type tags are not convertible from pre-3.0 versions to 3.0+. If you have invested time in tagging, we recommend that you run an event type export command prior to beginning any migration, which will give you a record of eventtypes and tags with a sample for each event type, which you can use to begin defining a new event type scheme in 3.0.

What will be preserved on upgrade

Provided you follow the step-by-step instructions for upgrade and migration, your indexed event data, indexed fields including source::, host:: and sourcetype::, users and passwords, and most global data such as host tags and source type aliases will be preserved. The only global data that will be lost is your 2.x event types and event type tags. Your saved and live splunks, now called saved searches and alerts, will be preserved by means of a step outlined in the step-by-step migration process.

Deployment server

If you have a multiple server Splunk deployment, we strongly recommend that you take advantage of the new deployment server. This will enable you to manage the configuration of all servers from a single location, and manage identically configured Splunk servers as a single class. In that event it might be best to follow the upgrade instructions for your central Splunk server, then redeploy any forwarding Splunk servers from scratch as deployment clients. Read more about configuring a Splunk deployment in 3.0 and specifically about the deployment server.

License changes

If you are using 2.x Splunk Professional, you will need a new Enterprise license for 3.0. For customers with current support agreements your new license should already be downloadable from the Splunk store.

Previous: Uninstall Splunk | Next: Upgrading 2.1.x or 2.2.x to 3.0.x

Comments

The event typer changes really made my job harder. In version 2.1.1 events were automatically typed as they were recieved. This allowed me to review a great number of events based on their type for auditing purposes.

In my environment 290,000+ events were typed into 300 or so event types. I could review all the event types and drill down on new or exciting events in a matter of 20 minutes or so. The event typing also allowed me to find "needle in a haystack" events that occurred only once or twice in the 290,000 log "haystack". I start each morning with a search like "hoursago::24 maxresults::500000". I go to the last event on the events tab and work my way to the beginning. By the end of my first cup of coffee I know every failed login, su, sudo command, ssh session, process exit signal and firewall deny rule match in my company. This is absolutely amazing.

As it stands now they will pry version 2.1.1 from my cold dead hands. But I'd love to get the benefits of 3.x.
Posted by sixminutemile on Oct 31 2007, 8:17am
In the Event typer changes section, it refers to doing an "event type export". Is that "splunk export userdata -subset eventtypetags" or is it globaldata... Possibly a reference to what an event type export is as i can't quite find one in the dox.
Posted by michaelwilde on Aug 25 2007, 8:39pm