How do you handle chargebacks to business units within your organization?


I'm part of a large organization that is sub-divided into various business units.

We're pretty much running an internal "Splunk as a Service"-type deal. We own and manage the license, servers, storage, etc.

Our chargeback rate is pretty much identical to how Splunk is licensed:

BilledRate = GBs_Indexed * (Price_Per_GB + Internal_Overhead)

Internal_Overhead is a number we calculated based on our storage and hardware costs. Our IT organization isn't supposed to make any money - best case scenario, we break even.

Our BUs come to us and say "we want to monitor logs from MyApp", and we go from there in setting up/identifying the proper sourcetypes, directing it to a proper index, etc.

I'm just curious how other people at similar organizations have handled chargebacks to supported BUs within their organization.

  • How many business units are you supporting as "customers"?
  • What methods are you using to meter how much data flows through?
  • How'd you calculate your chargeback rate?
  • Any other things you learned along the way?
Labels (2)

Splunk Employee
Splunk Employee

I have struggled with chargeback since I first started using Splunk in a shared environment several years ago. At first, I tried to charge based on the actual utilization of Splunk, but that is an extremely difficult problem to solve. Then it dawned on me - chargeback the same way that I buy and deploy Splunk. I then focused in on the two main cost factors - licensing and storage. By calculating my run rates for licensing and storage, I am very close to the overall costs.

I then wrote the Chargeback App to make my life easier and to share with others. It is well documented, but you can reach out to me if you need more details. I have a 30 - 60 minute talk and demo that I have been giving to customers and just recently at .Conf. When the video is available for that, I will post it here.

Pay close attention to the "Micro License" that is applied within the App. It puts your greatest fears to rest, "how do you know when someone is indexing more data than was previously agreed to?"

I plan to continue development on this App. My next goals are to add in a model for Premium Apps , such as ES or ITSI, as well as account for the hardware within your Splunk architecture. If there is more that you would like to see, contact me. All of my information is in the README file, but you were headed there anyway ;).

0 Karma


I'm really curious to hear how other people manage this, too. Not just from a chargeback perspective, but also how resources such as licensing and storage are are managed between different customers and business units. We rarely do chargebacks, (unless the customer is asking for a very high volume) but we do share cost information with customers. We calculate cost in a similar way.

We start with their estimated daily volume and the number of days they want to retain their data. Then we calculate the licensing cost, storage cost, and server hardware cost.

GB/day indexed (based on our license and maintenance cost)
+ Storage (GB/day * retention period in days * 50% * Storage Price/GB)
+ Server HW (GB/day * 1/100 (assuming 100GB/day per indexer) * Price of new indexer)

We support our corporate entity and all of our business units, so we have somewhere around 175 different applications in Splunk. We rely on the _internal metric data from the indexers and we create hourly summaries of that data to help with reporting. We use the the per sourcetype and per host metrics the most. All of our sourcetypes include the name of the application, so even common log formats like a web access log would have the sourcetype access_common_appname, so we can easily run a search by application volume. We have daily volume reports that show us things like top 25 hosts, etc. that help us keep down overages.


Awesome answer!

0 Karma
Get Updates on the Splunk Community!

Using Machine Learning for Hunting Security Threats

WATCH NOW Seeing the exponential hike in global cyber threat spectrum, organizations are now striving more for ...

Observability Newsletter Highlights | March 2023

 March 2023 | Check out the latest and greatestSplunk APM's New Tag Filter ExperienceSplunk APM has updated ...

Security Newsletter Updates | March 2023

 March 2023 | Check out the latest and greatestUnify Your Security Operations with Splunk Mission Control The ...