Splunk® Enterprise

Installation 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

About Upgrading to 6.0 - READ THIS FIRST

This topic contains important information and tips about upgrading to version 6.0 from an earlier version. Read it before attempting to upgrade your Splunk environment.

Important: Not all Splunk apps and add-ons are compatible with Splunk Enterprise 6.0. If you are considering an upgrade to this release, please check Splunk Apps to confirm that your apps are compatible with Splunk Enterprise 6.0.

Upgrade clustered environments

If you plan to upgrade a Splunk cluster, read "Upgrade your clustered deployment" in the Managing Indexers and Clusters Manual. The instructions in that topic supersede the upgrade material in this manual.

Important: All nodes of a clustered Splunk environment must run the same version of Splunk. If you plan to upgrade your clustered environment, you must upgrade all nodes (including search heads, master nodes, and peer nodes) in the cluster at the same time.

Upgrade paths

Splunk Enterprise supports the following upgrade paths to Version 6.0 of the software:

  • From version 5.0 or later to 6.0.x
  • From version 4.3 or later directly to 6.0.x
  • From version 4.3 or later to 5.0, and then from version 5.0 or later to 6.0.x

If you run a version of Splunk prior to 4.3, upgrade to 4.3 first, then upgrade to 6.0. Read "About upgrading to 4.3 - READ THIS FIRST" for tips on migrating your instance to version 4.3.

You want to know this stuff

Upgrading to 6.0 from 4.3 and later is pretty simple, but here are a few things you should be aware of when installing the new version:

We have changed the Splunk Enterprise user interface...significantly

One of the biggest and most important things that you will notice after you upgrade to version 6.0 is the new user interface. We have transformed how you access Splunk through Splunk Web. To that end, the way you do things in Splunk Web on version 6 has changed from how you would do things in previous versions of the product.

We have changed a number of the Splunk terms that you've come to know

Along with a changed user interface, we've also changed a number of the terms you've been used to when using Splunk. Here's a list of some of them:

  • Manager, Splunk's main configuration interface, is now known as Settings.
  • Launcher, the initial menu you see when you run Splunk, is now known as Home.
  • Saved searches are now known as reports.
  • A saved search with an alert is now known as an alert.
  • "TSIDX stats" are now known as indexed field statistics.

We have changed some application development parameters and procedures

If you develop any type of Splunk app, be sure to read "Changes for Splunk app developers" to find out how to build or migrate your existing apps to work properly with version 6.

Other notable changes

We have changed the handling of some of the deployment server's serverclass.conf attributes

We've changed how whitelists and machine type filters get handled in serverclass.conf.

Back in version 4.3, we introduced a new attribute called machineTypesFilter. This attribute deprecated the similar machineTypes attribute. When you upgrade, Splunk Enterprise replaces machineTypes entries in serverclass.conf with machineTypesFilter.

Additionally, when using serverclass.conf, you must now specify either a whitelist or a blacklist in every stanza by using the whitelist.<n> or blacklist.<n> attributes.

If you use the new forwarder management feature for the deployment server, avoid using deployment server settings that are incompatible with Forwarder Management.

Note: A deployment server cannot be a client of itself.

We have increased the default amount of required available disk space for indexing and searching

Prior to version 6.0, the default amount of free space Splunk needed to index and search was 2 gigabytes. When you upgrade, Splunk raises this default requirement to 5 gigabytes. Before you upgrade, make sure you have enough free space on the volume(s) that contain Splunk indexes and search dispatch directories to ensure uninterrupted index and search operation.

Splunk no longer uses CHECK_FOR_HEADER for field extraction from structured data files

The deprecated CHECK_FOR_HEADER attribute in props.conf will no longer function for any new sourcetypes defined for structured data extraction. This means that, when you upgrade, attempts to use CHECK_FOR_HEADER will result in Splunk logging an error and disabling the associated definition.

This change does not impact structured data definitions created prior to the upgrade - those definitions will continue to work with the CHECK_FOR_HEADER attribute.

For information on Splunk's new structured data field extraction capabilities, read "Extract data from files with headers" in the Getting Data In Manual.

We have reduced the maximum real-time search multiplier attribute in limits.conf

We have reduced how many real-time searches a Splunk system can run by default.

In Splunk version 5.x, you used to be able to run a number of searches equal to the following formula, based on attributes from limits.conf:

Number of CPU cores * max_searches_per_cpu + base_max_searches * max_rt_search_multiplier

The max_rt_search_multiplier attribute's default value was 3. When you upgrade, Splunk reduces the default value to 1. This means that your real-time search capacity will be effectively reduced by 66% unless you reset this attribute by editing a copy of limits.conf after the upgrade.

We have extended the _internal index's retention period

In an effort to provide better statistics on license usage, we have extended the retention period of the _internal index from 28 days to 30 days. When you upgrade, you might notice that Splunk uses up to an additional 7 percent of available disk space on the server which hosts that index.

The "Results Display Option" dialog for search queries does not retain changes through an upgrade

If you make changes to the results display options for a given search query in version 5.x, Splunk does not retain those choices through an upgrade. You must make those changes again after the upgrade is complete.

Some upgraded dashboards display visible axis titles where they did not before

When you upgrade, some dashboards will display visible axis titles which did not exist prior to the upgrade. To address the issue, use the visualizations editor to remove the titles.

View states do not persist during the upgrade

If you make a change to a view state (such as adjusting the number of items to show per page in the flash timeline) and then upgrade Splunk, Splunk does not preserve the view state through the upgrade, and the default view loads when you use the upgraded version.

This is because Splunk assigns each view state a module ID, which changes when you modify the view state's XML (by modifying the view).

To manage view states after upgrading, edit ui-prefs.conf.

We have changed how you set the default search time range

Prior to version 6, you could set the default search time range by selecting the desired entry in the flash timeline. Once you upgrade, you must use a configuration file, ui-prefs.conf, to set these default time ranges. Selecting the time range in the time range picker in a view will no longer have any affect.

To learn how to use this file to set time ranges, read "Change the default selected time range" in the Search Manual.

The configuration location for globally unique identifiers (GUIDs) has changed

We have changed the location for the configuration of GUIDs for Splunk instances. In Splunk 6.0, instead of setting the GUID in server.conf, you must now set it in instance.cfg.

In props.conf, the initCrcLength attribute is now valid for sourcetype stanzas

Prior to Splunk 6.0, you could only use the initCrcLength attribute in a [source::<source>] stanza type. Now, you can use this attribute in any [<sourcetype>] stanzas as well.

tsidx file format changed from version 5.x.

If you are upgrading from Splunk Enterprise 5.x and you used the experimental version of the tscollect command in that release, the format of the tsidx files in Splunk Enterprise 6.x is not compatible with the earlier version.

Notable changes for those upgrading directly from version 4.3 to version 6

We have changed how Splunk handles invalid regular expressions in monitoring stanza filters

For versions 5.0.3 and later of Splunk, including version 6.0, we've changed how Splunk deals with improperly formatted regular expressions in monitoring stanza filter attributes in inputs.conf.

If you supply an invalid regular expression for a filter attribute (for example, whitelist or blacklist) in a monitoring stanza, Splunk now ignores the entire stanza as being invalid, instead of ignoring only the filter attribute with the invalid regular expression. This means that Splunk will not monitor whatever data that stanza references until you fix the error and restart Splunk. Here's an example:

[monitor:///a/directory]
whitelist = unclosed[class

This stanza is invalid because the whitelist attribute has an invalid value assigned to it (the "unclosed[class" regular expression is missing the right bracket (])).

In version 5.0.2 and earlier, including version 4.3, Splunk monitors the files in /a/directory while ignoring the whitelist attribute.

TailingProcessor - Ignoring regular expression 'your_regex' in stanza 'your_stanza' due to 'error_message'.

In version 5.0.3 and later, Splunk ignores the [monitor:///a/directory] stanza, logs an error in splunkd.log, and does not monitor the files in /a/directory:

TailingProcessor - Invalid regular expression: 'your_regex' in stanza 'your_stanza' due to: error_message, ignoring this stanza.

When you upgrade, Splunk warns you of any invalid regular expressions it detects, and prompts you to fix them before attempting to complete the migration. To prevent this warning from occurring, check inputs.conf to ensure that all your monitoring stanzas have valid values before starting the upgrade.

Note: This change was originally introduced in Splunk 5.0.2, but we include it here for users who plan to upgrade directly from version 4.3 to version 6.0.

We have deprecated the fschange monitor

We have deprecated the fschange monitor input. This means that although it continues to function in version 6.0 of Splunk, it might be removed in a future version. As an alternative, you can:

Note: This change was originally introduced in Splunk 5.0, but we include it here for users who plan to upgrade directly from version 4.3 to version 6.0.

Forwarding method now defaults to auto-loadbalancing

Splunk 6.0 now makes auto-load balancing the default method of forwarding data to multiple indexers at one time.

Note: This change was originally introduced in Splunk 5.0, but we include it here for users who plan to upgrade directly from version 4.3 to version 6.0.

Splunk now offers integrated PDF printing

With version 6.0 of Splunk comes integrated PDF printing. This means that PDF printing no longer requires a Linux Splunk instance.

There are some things to pay attention to when upgrading, however - particularly with regards to views that contain Advanced XML. Additional information can be found in "Generate PDFs of your reports and dashboards" in the new Reporting Manual.

Note: This feature was originally introduced in Splunk 5.0, but we include it here for users who plan to upgrade directly from version 4.3 to version 6.0.

Splunk uses more *nix file descriptors

Splunk 6.0 uses more file descriptors on *nix filesystems than version 4.3 did when monitoring files.

Before you upgrade, consider increasing the number of open file descriptors your system can use with the ulimit command.

Note: This change was originally introduced in Splunk 5.0, but we include it here for users who plan to upgrade directly from version 4.3 to version 6.0.

Splunk's database-checking utility might use more resources

After you upgrade to 6.0, Splunk's database consistency checking utility (fsck) might use more system resources (in particular, disk I/O) when they run, particularly if bloom filters are being created at the same time.

Note: This change was originally introduced in Splunk 5.0, but we include it here for users who plan to upgrade directly from version 4.3 to version 6.0.

Windows-specific changes

The Windows Event Log input is now modular and has additional filtering capabilities

The Windows event log input gets two new improvements:

  • The input, which until now had its own input processor, is now modular. This helps increase its efficiency and removes the limit of 64 concurrent Event Log channels. Since the Windows Event Log input already uses inputs.conf, there should be no impact to your configuration by this change. However, we suggest that you review any .conf files post-upgrade as a precautionary measure.
  • Additionally, the input receives several new attributes which allow you to filter events based on their Windows Event IDs and suppress event log text.

There are also certain situations where, if you use a deployment server to control configurations, some versions of universal forwarder might collect duplicate events. See "Upgrade deployment servers and installed apps that use 6.0 stanzas might generate duplicate events" below for additional information.

Upgraded deployment servers and installed apps that use 6.0 stanzas might generate duplicate events

In order to maintain interoperability, Splunk does not remove an old-style Windows Event Log stanza during an upgrade to version 6. Instead, it notifies you that you need to remove them yourself manually.

This is particularly important for deployment servers or universal forwarders that host apps that use 6.0 style configuration file stanzas. When you upgrade, if you do not remove the old-style stanzas, Splunk might generate duplicate events.

Splunk on Windows introduces three new inputs: Host, printer, and network monitoring

New for version 6.0, Splunk introduces three new Windows-only modular inputs: Host monitoring, print monitoring, and network monitoring.

Host monitoring allows you to collect information about a Windows system, including operating system build and version, system architecture and memory, running processes and services, and installed applications.

Print monitoring lets you gather information on your printer subsystem, including installed printers, print drivers and ports, and also allows you to check print jobs.

Network monitoring lets you collect information on the configuration and status of the networking subsystem on Windows computers.

For additional information on these three new inputs, read the following topics in the Getting Data In Manual:

Windows users now have a file monitoring input that does not use file handles

On Windows instances of Splunk only, a new file monitoring input, MonitorNoHandle allows users to monitor files without using system file handles. This addresses problems with cases where a file handle prevents a file from being closed properly, such as what occurs with Microsoft's DNS server logs when the DNS server attempts to roll them.

The MonitorNoHandle input is only accessible by editing inputs.conf. You cannot enable this input with Splunk Web.

The Windows Registry and Active Directory inputs are now modular

In our ongoing efforts to streamline configuration files, we have made the Windows Registry monitor and Active Directory inputs modular. This means that, among other things, instead of using separate configuration files, these inputs now use inputs.conf for configuration. When you upgrade, settings will get migrated from the existing configuration files to inputs.conf.

Splunk will migrate the following files during the upgrade:

  • Registry monitoring: regmon-filters.conf
  • Active Directory: admon.conf

What happens after you upgrade:

  • Registry monitoring stanzas will appear in inputs.conf as [WinRegMon://<stanza name>].
  • Active Directory stanzas will appear in inputs.conf as [admon://<stanza name>].

After you complete the upgrade, review the updates to inputs.conf and remove admon.conf.

Active Directory monitoring time formats have changed

The time stamp format that Splunk's Active Directory monitoring input logs in has changed. In Splunk 6.0 and later, AD monitoring inputs log events as follows:

pwdLastSet=07:03.12 pm, Mon 04/30/2012

If you use Active Directory monitoring inputs, you might be impacted by this change after you upgrade, particularly if you have configured alerts that rely on the old time stamp format.

No support for enabling Federal Information Processing Standards (FIPS) after an upgrade

There is no supported upgrade path from a Splunk 5.x system with enabled Secure Sockets Layer (SSL) certificates to a Splunk 6.0 system with FIPS enabled.

PREVIOUS
How to upgrade Splunk
  NEXT
How Splunk Web procedures have changed from version 5 to version 6

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


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