I am attempting to generate an area chart for the past 15 days using the following search:
index=test sourcetype=abcd source=1234 field1=* | timechart span=1h count by field1 useother=f limit=0
field1 has approximately 160 distinct values. Given this in conjunction with the time range and 1 hour span this results in almost 60,000 data points to be plotted. When attempting to chart this, I get the error
These results may be truncated. Your search generated too much data for the current visualization configuration.
I have done the following to attempt to resolve this issue:
None of the above fixes have resulted in the chart rendering with all the results. Are there any other potential solutions to this issue that I can try?
Thanks for your assistance.
Have you opened a support case for this? We are trying to get Splunk to remove this limit and more customers behind this will help drive this.
Thanks,
Ken
Part of the reasons for this "unavoidable error" is that charts that are busier than 50K data elements are pretty much too busy to be useful. It is Splunk's way of telling you, "Don't be ridiculous, nobody will even use it!"
The way to do this is to segment your field1
value-space into logical sub-groupings and plot each subgrouping on a separate dashboard by adding | where tag=field1USA
for one and | where tag=field1UK
another, etc. This is what I have done.
I agree in theory that plotting this large a volume of data may not be useful. However, in transitioning to Splunk we are trying to convert all existing reports and dashboards that are being currently generated in other tools. The dashboard panel in question is currently being generated successfully in Excel.
That being said I believe the issue is not so much related to the number of data points as it is to the number of series being attempted to chart. According to Splunk documentation, in version 6.2.8 JSChart is limited to plotting a maximum of 50 series - http://docs.splunk.com/Documentation/Splunk/6.2.8/AdvancedDev/CustomChartingConfig-JSChart
There is no current version of this document for 6.3.3. Can someone validate that this maximum limit also applies to 6.3.3?