--- title: "Splunk With Wasabi" slug: "how-do-i-use-splunk-with-wasabi" updated: 2026-10-21T17:08:21Z published: 2026-10-21T17:08:21Z canonical: "docs.wasabi.com/how-do-i-use-splunk-with-wasabi" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.wasabi.com/llms.txt > Use this file to discover all available pages before exploring further. # Splunk With Wasabi [Splunk](https://www.splunk.com/) Enterprise is certified to store indexed application logs in Wasabi Hot Cloud Storage. Any indexed logs that Splunk can store locally can be stored remotely with Wasabi using Splunk’s [SmartStore](https://help.splunk.com/en/splunk-enterprise/administer/manage-indexers-and-indexer-clusters/10.0/implement-smartstore-to-reduce-local-storage-requirements/about-smartstore). SmartStore creates a remote storage tier (Wasabi) where most data resides, and a local cache for recent data. To use Splunk Enterprise with Wasabi, follow the instructions below. ## **Requirements** - Splunk Enterprise is deployed and licensed. This solution was most recently tested with Splunk Enterprise version 10.0.1. - Existing index(es) created within Splunk. - An active Wasabi Hot Cloud Storage account. - Wasabi access and secret keys. - A Wasabi bucket with Versioning enabled. Note that Object Lock must not be used because Splunk requires read/write/delete access to data in your bucket. See [Bucket Versioning](https://docs.wasabi.com/docs/versioning) for further information on Versioning and how to create a bucket with Versioning enabled. Choose the Wasabi region closest to your Splunk deployment. ## **Procedure to Enable Wasabi Storage in Splunk** Refer to [Configure SmartStore](https://help.splunk.com/en/splunk-enterprise/administer/manage-indexers-and-indexer-clusters/10.0/manage-smartstore/configure-smartstore) for further information. 1. The **Cache Manager** must be enabled on each Indexer where SmartStore will be used. A cache that is too small will result in premature eviction of buckets to remote storage. A cache that is too large will take up excess space in local storage. Using a reference of a 100 GB per day ingest, 1 day of hot storage, a 30 day cache retention, a replication factor of 2, and a compression factor of 50%, we came to a cache size of or 1550 GB or 1550000 MB. > [!NOTE] > **These settings should be verified with Splunk to ensure a functional deployment.** See [Reference Configs](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.0/configuration-file-reference/10.0.1-configuration-file-reference/server.conf) for more details. For our testing, we assigned this stanza to **server.conf** in the /opt/splunk/etc/system/local directory. [cachemanager] #A non-zero max_cache_size is necessary to enable SmartStore. This can be adjusted to a lower value for testing. max_cache_size = 1550000 #hotlist settings protect critical data from eviction; these settings will vary per deployment hotlist_bloom_filter_recency_hours = 1 hotlist_recency_secs = 60 2. Next, we want to add our Wasabi volume information to the **indexes.conf** (typically located in the /opt/splunk/etc/system/local directory) in order to connect to the remote storage. This is usually at the top of the conf file. See the [Splunk Admin Manual](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.0/configuration-file-reference/10.0.1-configuration-file-reference/indexes.conf) for additional information. For this volume, provide a name (Wasabi in our example). It is only a reference within Splunk to the remote storage. Under path, you need to reference your Wasabi bucket. [volume:wasabi] storageType = remote path = s3:/// remote.s3.access_key = remote.s3.secret_key = remote.s3.endpoint = https://s3.us-east-1.wasabisys.com remote.s3.auth_region = us-east-1 # It is preferred to use Versioning. If versioning is not being utilized, add the following, along with Wasabi [Lifecycle](https://docs.wasabi.com/docs/lifecycle-1) policies: # remote.s3.supports_versioning = false > [!NOTE] > Note that this config example discusses the use of Wasabi's us-east-1 storage region. To use other Wasabi storage regions, please use the appropriate Wasabi service URL as described in this [Service URLs for Wasabi's Storage Regions](https://docs.wasabi.com/docs/what-are-the-service-urls-for-wasabis-different-storage-regions). 3. Restart Splunk **/opt/splunk/bin/splunk restart** Create a sample txt file by typing: **echo "hello world" > test01.txt** Let’s use Splunk to try pushing it to Wasabi using the volume we created. **/opt/splunk/bin/splunk cmd splunkd rfs -- putF test01.txt volume:wasabi** If no errors occur, we can list from the cli as well to verify: **/opt/splunk/bin/splunk cmd splunkd rfs -- ls --starts-with volume:wasabi** As a result, the following is displayed. | **Size** | **Name** | | --- | --- | | 12B | test01.txt | It is listed within the [Wasabi Console](https://console.wasabisys.com). ![](https://cdn.document360.io/bef0a1ea-7768-4d5a-b520-c4fe2f7fafad/Images/Documentation/Screenshot_2025-11-19_at_4_57_59 PM.png) 1. If something is not working, it would be logged in /opt/splunk/var/log/splunk/splunkd-utility.log under the S3Client heading. You can check from the CLI with **grep S3Client /opt/splunk/var/log/splunk/splunkd-utility.log** 2. Now that we have verified connectivity, we can add this remote storage to a provisioned index. In our example, the index is called syslog. We need to mount the volume under the syslog index stanza in **indexes.conf**. > [!NOTE] > **These settings will vary per deployment and you should check with Splunk before rolling it into production.** The key part is the remote path, which references the volume we created and the index name (syslog in the example). **[syslog]** **coldPath = $SPLUNK_DB/syslog/colddb** **homePath = $SPLUNK_DB/syslog/db** **maxTotalDataSizeMB = 512000** **thawedPath = $SPLUNK_DB/syslog/thaweddb** **enableDataIntegrityControl = false** **enableTsidxReduction = false** **remotePath = volume:wasabi/syslog** **hotlist_bloom_filter_recency_hours = 48** **hotlist_recency_secs = 86400** Once that is edited, restart Splunk. **/opt/splunk/bin/splunk restart** 3. Now, the wasabi volume is linked to the specific index. At this point, we can begin ingesting data into that index. The data will roll from hot -> warm after a certain time or size, which in this case is 1 day or 1550 GB. If we want to force a roll for testing purposes, we can make an internal REST call to do so. The format is: /opt/splunk/bin/splunk _internal call /data/indexes//roll-hot-buckets For example: **/opt/splunk/bin/splunk _internal call /data/indexes/syslog/roll-hot-buckets** Then enter your Splunk admin username and password. 4. Once the bucket is rolled to warm, we should see it populate in its own folder within our Wasabi bucket. ![](https://cdn.document360.io/bef0a1ea-7768-4d5a-b520-c4fe2f7fafad/Images/Documentation/Screenshot_2025-11-19_at_4_57_59 PM_2.png) Now SmartStore is fully enabled for the specific index. For troubleshooting information, refer to the Troubleshoot SmartStore section. > Splunk SmartStore Dashboards are available in the Splunk Monitoring Console to view SmartStore deployment status and errors.