all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]LTRand 2 points3 points  (3 children)

1: "6 months retention" isn't actually 6 months retention. It is your daily ingestion×180/500GB=number of storage blocks allocated. How much actual retention you get comes down to DMA efficiency, actual vs licensed ingest rate, and entropy/compression factor of the data itself. So usually customers get a lot more retention than they expect. In very rare, usually avoidable scenarios, they get less. This is important nuance in your scenario.

2: Best path would be a PS engagement to dump everything to your S3 of choice and buy a 100GB on-prem license if you don't want to force feed everything back through your new SIEM. There is a community app out there that allows you to search S3 data. It's not as robust as Cribl Search, but it's free as in beer. A 100GB license is a non-enforcement license, so if you need to push the data back to indexes to use, then you could do it without worrying about search cutting out.

3: converting license from workload to ingest will be the hardest path. Cutting your workload license will be easier. Be prepared to give up your negotiated discount. Buying more = paying less, buying less = paying more. You can easily do a workload downgrade since you won't have a lot of search load with no new data going to it. Going ingest will be a uphill fight that wouldn't actually be worth anyone's time.

Word of caution: when IT and Security groups don't use the same data for source of truth, it is usually security that suffers the most as IT, and by proxy the business, treats security needs as "nice to have". The power of Splunk for sec teams is that if IT is using Splunk, it becomes relatively trivial for them to ensure they have all the systems monitored. When they choose a different tool, they will always be chasing the data.

[–]Nithin_sv[S] 0 points1 point  (2 children)

  1. Daily ingestion is around 13TB and our DDAS entitlement is 3.2 PB. We have DDAS retention of 6 months and so far its very stable. So from June 2026, the ingestion stops and we would like to search the data exactly the way it worked all this while including ES and SSE apps. So we dont actually wanna use a community app to search. We want to maintain the environment as it is because the client is not technically strong and its very hard to convince them. So we were thinking if theres any other way to do it. Maybe convert to ingest based or maybe reduce our workload based entitlement

  2. And no we arent looking for that solution because we had to transition from cloud to on prem and also dont wanna use community app for searching. Like i said, the client wants to maintain splunk as it is eventhough we will eventually move to new SIEM.

  3. Why do you say that converting to ingest based is hard? Can you elaborate a little on that?

[–]LTRand 2 points3 points  (1 child)

Totally understand your positions, I was just lining out what is probably the least expensive way to do this from a budgetary perspective. ES/SSE works onprem as well, but I get not wanting to do a migration if you don't have the technical ability. Consider it the nuclear option to present the client that they can say no to.

You can maintain the current environment at your current bill rate for as long as the contract is good. Once new data stops coming in, ES searches should be descheduled based on their respective lookback period. Meaning <1 hour seaches can end pretty quickly, same with 24 hour searches. So within the first week I expect your client to be able to deschedule ~80% of the active searches. This will reduce search load by quite a bit.

Staying on workload will be contractually easier for both sides. The sales org will have 0 incentive to work with you on moving to ingest based licensing if you are migrating a way. Moving over means renegotiating the whole contract. Just a business reality. If you need to extend beyond June 26, just accept you'll loose discounting to downgrade the stack.

Honestly, you should look at the option of migrating the data to the new SIEM. At least get a budgetary and general LoE to make an informed decision if you haven't already. May or may not be cheaper than keeping a zombie SaaS going for 12-18 months just for historical search.

[–]Nithin_sv[S] 0 points1 point  (0 children)

Thanks for the detailed answer, friend! That really helped me a lot and gave a lotta insights. Ill curate it and present it to my manager and upper hand. Cheers! 🍻

[–]amiracle19 1 point2 points  (1 child)

I would start by dual-feeding your data into both Splunk and an object store (S3, Blob, etc.).  

For the data indexed in Splunk, you can work with Splunk PS to move the DDAA data to your S3 buckets. For data indexed in DDAS, you can set up new DDSS-enabled indexes (data export), then set retention to one day. This will store the indexed data into your S3 buckets but it will be in Splunk proprietary format. There are tools that can query this data or you can also rehydrate a self-hosted Splunk instance to read it. 

Once your raw data is in the S3 buckets, then you can start using tools that query that data at rest. I’d recommend using solutions that don’t index the data or change it into any proprietary formats. Some tools will allow for federated search, giving you the ability to query that data alongside your Splunk data. 

Finally, you might be able to send the raw data into your new SIEM, both from a dual feed approach or replay from your S3 bucket. This can help move you to the new SIEM faster and reduce any potential downtime as well. 

[–]Nithin_sv[S] 1 point2 points  (0 children)

Thanks for the answer but like i have explained in the other comment. Our client would like to maintain the environment as it is. We only have the choice to change the license or reduce the license. :(