Installation

License usage dashboard results vary when using "split by" option.

dflodstrom
Builder

In the past 30 days I have received a license warning for exceeding my daily indexing limit. When I look at the distributed management console's License Usage dashboard I can see these violations in relation to my stack size. When I use 'split by' and select index the dashboard refreshes and now none of the bars go above my stack size.

I get the same results when I look at the licensing dashboard from Settings>Licensing.

Is one of the reporting methods inaccurate? Is there a difference in the way the volume is being calculated that I'm missing?

Labels (1)
0 Karma
1 Solution

dflodstrom
Builder

The issue ended up being a result of missing indexers in my distributed search configuration on the DMC server. We've added indexers to our cluster which were not included in the DMC host's distributedsearch.conf. I suppose the total volume indexed was available from the license master but when splitting by index it needed to use metrics from the indexers themselves.

View solution in original post

dflodstrom
Builder

The issue ended up being a result of missing indexers in my distributed search configuration on the DMC server. We've added indexers to our cluster which were not included in the DMC host's distributedsearch.conf. I suppose the total volume indexed was available from the license master but when splitting by index it needed to use metrics from the indexers themselves.

Yasaswy
Contributor

Hi... Assuming you just have right license pool selected. The violations you see are from the perspective of the "indexer" ... so if you do a split by indexer rather than index... you should see the offending indexers cross the stack size.

Eg: Pool A might have a stack size of say 1 TB and if it breached data coming into the pool from slaves after the breach will be reported as warnings. However from an index standpoint ...depending on how the indexes have been defined that same 1TB data can be spread across multiple indexes and so none of them will show up above your stack size.

0 Karma

dflodstrom
Builder

The graph I'm looking at shows Daily License Usage by volume compared to stack size. I do not have it split on indexer, our indexers are all members of the same license pool which is equal to the size of our license stack; if I'm not mistaken this configuration means if one indexer generates a warning all of the indexers will generate a warning. Each bar in the graph shows us the total volume of logs for each day for the past 30 days.

When I choose 'Split by: Index' each bar should still show the total volume with colored bands representing the various indexes; this graph displays as a stacked bar graph. I still don't understand how the total volume is not the same from one graph to the next.

0 Karma

Yasaswy
Contributor

Hi... sorry about the confusion. You are correct. License Usage does show stacked data. If you have all your indexers sharing the same pool it is to be expected the stacked bar of all indexed data should cross the defined stack size on a breach. So am not sure what issue can be 🙂 ...
If your license pool is pretty big, depending on your env the 30 day report might take a while to fully render...
Also just curios if you tried to look up same information from the metrics side... something like

index=_internal earliest=XXX latest=XXX metrics* per_index_thruput host=urindexers* series=urindex(s)|eval GB=kb/1024/1024|stats sum(GB)

I think data on license manager report uses license_usage log. From data indexed standpoint I would guess it should match what is reported in metrics.

0 Karma
Get Updates on the Splunk Community!

Exporting Splunk Apps

Join us on Monday, October 21 at 11 am PT | 2 pm ET!With the app export functionality, app developers and ...

Cisco Use Cases, ITSI Best Practices, and More New Articles from Splunk Lantern

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

Build Your First SPL2 App!

Watch the recording now!.Do you want to SPL™, too? SPL2, Splunk's next-generation data search and preparation ...