About upgrading to 5.0 READ THIS FIRST
Contents
- You want to know this stuff
- We have removed the deployment monitor from the Splunk installation package
- We have removed multicast distributed search peer discovery
- We have deprecated the fschange monitor
- We have deprecated several REST endpoints and a Python SDK function
- The Windows performance monitoring input is now modular
- Active Directory monitoring time formats have changed
- Viewstates do not persist during the upgrade
- Forwarding method now defaults to auto-loadbalancing
- Splunk now offers integrated PDF printing
- Splunk uses more Unix file descriptors
- Splunk's database-checking utility might use more resources
- The configuration location for globally unique identifiers (GUIDs) has changed
About upgrading to 5.0 READ THIS FIRST
This topic contains some important information and tips that you should read about when migrating to version 5.0 from an earlier version.
You want to know this stuff
Upgrading to 5.0 from 4.2 and later is pretty simple, but here are a few tips:
We have removed the deployment monitor from the Splunk installation package
The deployment monitor is no longer a part of the Splunk installation package. Starting with version 5.0, the deployment monitor is now available as a downloadable app from Splunkbase.
If you use the deployment monitor, you should not be impacted by this change when you upgrade. However, be sure to double check your configuration to ensure that the app works as desired after the upgrade is complete.
We have removed multicast distributed search peer discovery
We've removed multicast distributed search peer discovery. Starting with version 5.0, you must now configure distributed search peers explicitly with SSL security. The following attributes in distsearch.conf are no longer valid:
-
heartbeatFrequency -
blacklistNames -
blacklistURLs -
heartbeatMcastAddr -
heartbeatPort -
ttl -
autoAddServers -
skipOurselves
We have deprecated the fschange monitor
We have deprecated the fschange monitor input. While it continues to function in version 5.0 of Splunk, it might be removed in a future version.
We have deprecated several REST endpoints and a Python SDK function
For version 5.0 of Splunk, we have deprecated some representational state transfer (REST) endpoints, as well as a Python SDK function. While they continue to work in this release, they might be removed entirely in a future release. Read "Deprecated features" in the Release Notes for specifics.
The Windows performance monitoring input is now modular
The performance monitoring inputs for Windows now use the new modular input type. When you upgrade, Splunk replaces the existing scripted input with the new modular input. During the migration, Splunk saves the existing perfmon.conf file and renames it to perfmon.conf.migrated. It then copies the inputs defined in that file and places them into inputs.conf under similarly-named stanzas.
This has major impact for users who use the Splunk App for Microsoft Exchange and the Splunk App for Active Directory. Those apps use performance monitoring inputs extensively. If you use either of these apps, we suggest that you do not upgrade the apps until compatible versions are released.
For additional information on what a modular input is, read "Modular inputs overview" in the Developing Views and Apps for Splunk Web Manual.
Active Directory monitoring time formats have changed
The time stamp format that Splunk's Active Directory monitoring input logs in has changed. In Splunk 5.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.
Viewstates 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).
Forwarding method now defaults to auto-loadbalancing
Splunk 5.0 now makes auto-load balancing the default method of forwarding data to multiple indexers at one time.
When you upgrade, any forwarding configurations (outputs.conf) which do not explicitly have the autoLB attribute set to false will operate under the new method. If you do not desire this, you must explicitly add autoLB=false to the appropriate stanza(s) in outputs.conf.
Splunk now offers integrated PDF printing
With version 5.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 is found in "Upgrade PDF printing for Splunk Web" in this manual.
Splunk uses more Unix file descriptors
Splunk 5.0 uses more file descriptors on Unix 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.
Splunk's database-checking utility might use more resources
After you upgrade to 5.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.
The configuration location for globally unique identifiers (GUIDs) has changed
We've changed the location for the configuration of GUIDs for Splunk instances. In Splunk 5.0, instead of setting the GUID in server.conf, you must now set it in instance.cfg.
This documentation applies to the following versions of Splunk: 5.0 , 5.0.1 , 5.0.2 View the Article History for its revisions.
Comments
The manual migration is quite easy (move configuration from perfmon.conf to inputs.conf and prepend your stanza with "perfmon://"), and I did eventually find the introspection scheme for the perfmon modular input.
Old (perfmon.conf):
[PERFMON:CPUTime]
counters = % Processor Time;% User Time
disabled = 1
instances = _Total
interval = 10
object = Processor
New (inputs.conf)
[perfmon://PERFMON:CPUTime]
counters = % Processor Time;% User Time
disabled = 1
instances = _Total
interval = 10
object = Processor
With respect to windows performance monitoring it would be extremely useful to understand what the new specification is for perfmon inputs. This will go along way to helping manually migrate perfmon.conf for deployments that use deployment-server, or app developers that need to update there perfmon.conf stanzas to inputs.conf stanzas.
UPDATE: When migrating manually "Perfmon:" is prepended to your inputs.conf stanza name
Old (perfmon.conf):
[PERFMON:CPUTime]
counters = % Processor Time;% User Time
disabled = 1
instances = _Total
interval = 10
object = Processor
New (inputs.conf)
[perfmon://CPUTime]
counters = % Processor Time;% User Time
disabled = 1
instances = _Total
interval = 10
object = Processor