topic Re: Dashboard Saved search results is being truncated to 1000 in Dashboards & Visualizations

Dashboard Saved search results is being truncated to 1000

alexantao — Mon, 11 Nov 2013 21:09:14 GMT

I built a Saved Search and configured a Dashboard to include that Saved Search (below). In a panel of this Dashboard, I configured a report based on this saved search.

When I load the Dashboard, the search is started and stops showing NO data and a message below the graphic said that the results were truncated, and No data is shown. Opening in search I get a lot of results in events....

The Saved Search:

index=acess_web |eval Gb=bytes_in/1073741824| timechart span=1d sum(Gb)

Screenshot:

imageshack.com/a/img571/9028/ddaw.png

Thanks for any help

Re: Dashboard Saved search results is being truncated to 1000

somesoni2 — Tue, 12 Nov 2013 00:25:28 GMT

What is the earliest and latest value for the dashboard?

Re: Dashboard Saved search results is being truncated to 1000

alexantao — Tue, 12 Nov 2013 10:53:52 GMT

The Visualisation must show 1 month of logs, with 1 day of span. In teory, the visualisation should have only 30 points, each one is one day, and the data is the sum of Gb transfered that day.

Re: Dashboard Saved search results is being truncated to 1000

MuS — Mon, 28 Sep 2020 15:16:08 GMT

if you run this search in the search app:

index=acess_web |eval Gb=bytes_in/1073741824| timechart span=1d sum(Gb)

do you get back any results? Do you have any field named 'bytes_in'?

Re: Dashboard Saved search results is being truncated to 1000

somesoni2 — Wed, 13 Nov 2013 16:39:20 GMT

How many rows are you getting while running this query in search app? In ideal situation, if your selected timerange (in both search app and in your dashboard) should be set to show one month data. If nothing is specified if will run for All Times and may result more than 30 rows.

Re: Dashboard Saved search results is being truncated to 1000

alexantao — Wed, 13 Nov 2013 16:52:31 GMT

MuS,
I created a new Dashboard and added the search. It worked ! So I made the new Dashboard similar to the other that doesn't work.

With my user I can see the chart, but with another user, when loading message reaches 71%, the process is aborted and the same message is shown. All other charts are processes.

Chart working: http://imageshack.com/a/img824/2297/uslk.png

Re: Dashboard Saved search results is being truncated to 1000

alexantao — Wed, 13 Nov 2013 17:27:37 GMT

Somesoni2, for now, I'm getting 20 rows. But the maximum I'm planning is for the role month, or 31 rows.

Re: Dashboard Saved search results is being truncated to 1000

alexantao — Thu, 14 Nov 2013 09:38:33 GMT

Update: after the saved search ran on background (programed to run at midnight), it stopped working again, for all users.
With the user I created the dashboard, entered the Edit Panel and then, the Statistics mode. It is listing dates since January. There are more than 500 pages of data.
But it should not happen, since I configured to count the events from only 1 month ago ( -1mon, now).

Re: Dashboard Saved search results is being truncated to 1000

alexantao — Thu, 14 Nov 2013 11:21:15 GMT

Tried to put earliest=-mon on search string but didn't work (same results).
The strange is that, when I try the search mannually, on the result table for 1 second apears a bunh of rows with all dates and then disapear, showing only the results (correct results) from the search.

Re: Dashboard Saved search results is being truncated to 1000

the_wolverine — Thu, 12 Dec 2013 17:32:03 GMT

I'm encountering the same issue using PDF report. The view (dashboard) displays all the results just fine. A manual preview generates a PDF that displays only 1000 lines when there should be many more lines. This started after our upgrade to 5.0.3 (from version 4.3.x).

Re: Dashboard Saved search results is being truncated to 1000

kbecker — Thu, 29 Sep 2016 15:12:45 GMT

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