Yes, you can edit the default login page yourself and add anything you want to it. Be aware that any changes you make will be overwritten on upgrade, so make sure you add a step to your upgrade process to back it up and restore it each time. The login page lives here $SPLUNK_HOME/share/splunk/search_mrsparkle/templates/account/login.html ... View more

It's not currently possible but we will add that to the list of enhancement requests ... View more

It really depends on your requirements, your intended/expected data thruput and your budget. Take a look at this deployment article referenced above, that's directly from our Engineering team to help estimate your hardware needs. The top performers in terms of indexing and search speed & capabilities are Linux and Windows, those two are consistently ahead of the pack when it comes to performance, with Linux currently edging the lead. A lot of environments have old SPARC boxes that can be reappropriated and on paper look like an ideal platform, but note the stipulation of x86 architecture in that planning article. Splunk will run just fine on SPARC, but the hardware will limit the performance simply because it's not suited to the way Splunk works. If you care about performance, SPARC is not for you. If you don't care so much and just need a server to run on, go right ahead, but bear in mind that at some point you may want to migrate to x86 and currently there's no easy way to just copy your indexes over. ... View more

If you don't vote up my answer, nobody knows how smart I am. Click the "up" arrow if you find the answer useful people! ... View more

No, there's no way to push out individual files, or to define a variable in inputs.conf that will be server specific. The only real solution here is to update the $SPLUNK_HOME/etc/system/local/inputs.conf at install time. That gets created with the localhost as the default host name initially, so if you add a step to your install process/script you should be all squared away. I'll also suggest the idea of variables to the Dev team and see if there's any way we can add this capability in a future release ... View more

It depends on the app-specific permissons, which are controlled by $SPLUNK_HOME/etc/apps/<app_name>/metadata/default.meta For example, in the search app, only admin users have write permissions for views - ### VIEWS [views] access = read : [ * ], write : [ admin ] If you change the permissions so that the user role has write-access, then you should be able to promote your views. ... View more

RAID 5 is not a good storage solution for Splunk, as it is slow, and Splunk can only work as fast as the storage volume can, so if you're interested in fast performance, don't go down that route. Another consideration is 100GB of data doesn't necessarily equate to 100GB of disk-space when indexed. The compression ratio depends on the data, but you could find that 100GB equates to 50GB of space within $SPLUNK_DB . The only way to know for sure, is to run some tests with known data volumes. Also remember that cheap NFS storage is perfectly acceptable for older data you don't search very often ... View more

Following on from gkanapathy - When Splunk moves data from the Hot DB to the Warm DB, nothing is deleted - it is simply moved When Splunk moves data from the Warm DB to the Cold DB, nothing is deleted - it is simply moved When Splunk "retires" data from the Cold DB, it will be deleted unless you have configured a coldToFrozenScript in indexes.conf. This is done as part of a larger exercise to configure your data retirement policy, click here to learn more about this subject. A follow on page from the above link is this one, which will tell you how to set up your script, and some other options you may want to consider. The main thing to understand here are the states through which your data moves as Splunk is indexing it and as it ages. You can't keep data in the warm DB forever unless you have a lot of space or are indexing very little, so you need to consider how much space you want to use and how often you want to access it. If you usually run searches on data from the last week or two, then that's all you really need to keep in the hot & warm DB's and you can move your cold DB off to a cheap NFS location somewhere. Searching data on a NFS location, is slower than local disk, so if you're going to be regularly searching over data from the last 3 - 6 months and speed is important to you, then you will want to size your Splunk server accordingly and give it a lot of local storage. ... View more

We don't have a timeline for a 64-bit release on Snowleopard I'm afraid, so I can't give you an expected date. It's on the Development list of 'things-to-do' but not a priority right now. If this is something that would be important for a major deployment, you can feed this info to the PM team via your Sales rep or by filing a request for it via the Support Case process. ... View more

Where does your backed up data live and do you have the SPLUNK_DB variable set correctly in %SPLUNK_HOME\etc\splunk-launch.conf ? Or do you have your $SPLUNK_HOME\etc\system\local\indexes.conf pointing to the backup location? Basically what I'm asking is, have you told your new Splunk instance where to find the existing data? An easy solution would be to just copy all of your index buckets into the %SPLUNK_HOME\var\lib\splunk\defaultdb\db directory, assuming it's a brand new instance and you haven't yet made any changes to the files mentioned above. ... View more

Yes, the list monitor command does have some enhancements coming down the pipeline, right now it doesn't give complete information on every file & directory being monitored, and it lists files that are not being monitored due to whitelist/blacklist settings. Also, it's possible that it could take a long time to complete if you are monitoring hundreds of thousands of files & directories. There is a way you can get this information, but it's in the early stages of development and not as pretty as it could be. If you hit this endpoint with your browser - https://<servername>:8089/services/admin/inputstatus/TailingProcessor%3AFileStatus - you will get a lot of XML back detailing the current status of your monitored files. Again, this is not fully developed yet so it just gives you a lot of bare-bones info. Remember to insert your servername and splunkd management port into the URL. ... View more

There is a bug in the 4.1.3 and previous builds that is triggered by the slow NFS stat() calls, that much we know for sure. If your Splunk instance just stops indexing data, or stops picking up new files, then it's highly likely you are hitting this bug. Splunk should never stop indexing data from monitored files and discovering new files as long as new data is available. Increasing the max_fd setting will increase the number of FD's we can keep open for files that we've finished reading. The files will remain open until the time_before_close seconds. This doesn't mean that Splunk will run faster if you increase it to a huge number, it just means that files stay open longer so we may pick up new data more quickly. If files aren't updated once read, then it's of little use to you. Theoretically, there should be no limit to the number of files that Splunk can monitor. We depend on the OS to tell us which files have changed, so if the OS knows then Splunk will know too. An important distinction here is a 'live' file vs a 'static' file. Live files are currently being updated/written to, and Splunk will pick up new data from here as long as it keeps being added. Static files should be indexed and then ignored indefinitely. The concept of 'real-time' can also play a major role here. How quickly do you want Splunk to pick up data once it's written to a file? If your requirement is that Splunk should display the data as quickly as possible, then you want to limit the number of live files that Splunk is monitoring. If you have 20,000 live files then Splunk will not be able to keep up to date with every single file at the same time. However, if you have 20,000 files and only 50 of them are live, then Splunk should be easily able to keep up - are we starting to make sense yet? Our testing has shown that when tailing 10,000 live files, you can expect somewhere between 30 seconds and 1 minute lag. Those timings should increase linearly as you increase the number of files, so at 20,000 files you can expect 1 - 2 minutes delay. There's no hard and fast rule here, the speed of Splunk is dependent on the hardware resources available and how the instance is tuned - number of CPU cores, number of indexing threads, number of FD's, speed of the disk Splunk is writing to, data-segmentation etc. The faster Splunk can write to the index, the faster it can pull new data from files. Testing is the only true way to gauge the expected performance of your hardware, with your data. ... View more

Lets take a 3GB license as an example - Your Enterprise license will allow you to index 3GB of data per day. In case of an unexpected data surge, we do allow for 5 violations in a 30-day period - so if you have a web-server start to produce lots of errors and you index 3.5GB on a Sunday, Splunk will tell you this on Monday morning, and everything will continue to work as before. If you don't fix the problem and Splunk continues to index more that 3GB data on Monday, Tuesday, Wednesday & Thursday, that makes 5 violations, so Splunk will not allow you to search any data on Friday morning. Data will still be indexed, as Splunk never stops eating your data, but you won't be able to search it until you get a reset key from Splunk Support. The first one is free but repeated requests for reset keys will result in questions on the suitability of your license size so make sure you size your purchased license appropriately for your needs The only reason Splunk will stop indexing data is if it runs out of disk-space to write to. As long as data keeps coming in, Splunk will keep indexing it, even if you have 20 violations. ... View more

It sounds like there's something in your server's startup prcoess that calls both the splunkd and splunkweb services directly. Perhaps something was configured originally to do this before the SplunkLightForwarder app was enabled? When you just run the ./splunk start or ./splunk restart commands, it sounds like Splunk itself is doing the right thing, and not starting the splunkweb process, so something else must be calling that service directly. What have you got configured to start Splunk automatically when the server boots? ... View more

Yes there is, and it's documented here Your startup command becomes ./splunk start --accept-license ... View more

This is one explanation, another is that there is a known bug in 4.1.2 & 4.1.3 where Splunk tries to access a results file before it is actually created. It's not really anything to be concerned about, unless you're actually noticing a problem with loading search results or accessing saved results objects. It will be resolved in an upcoming release ... View more

Sounds to me that the services didn't install properly, but that's just stating the obvious. Every MSI installation should write a log file in %temp% , if there are any problems/errors during installation they should be recorded there. This smells like a permissions issue to me, have you tried installing as the 'Local System User'? One of the requirements of the 'User' Splunk runs as, is that User needs to have the 'Run as a Service' capability. From what I see here, it sounds like your Admin user doesn't have this permission. You can create a service, but that's a different function. ... View more