<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Scheduled View not working in Reporting</title>
    <link>https://community.splunk.com/t5/Reporting/Scheduled-View-not-working/m-p/27703#M500</link>
    <description>&lt;P&gt;Hi everyone. I've got an instance of Splunk 5.0.1 running with a large amount of firewall data coming into it daily (roughly 15GB). I created a relatively simply dashboard with 5 panels with the intent of scheduling the view for PDF delivery once per week. The view itself is fine, I tested it using a relatively short timespan on my search (e.g. last 60 mins of data). The problem is when I want to generate the view based on 1 week worth of data, it always fails and I suspect it has something to do with the large amount of data its trying to search through.&lt;/P&gt;

&lt;P&gt;Some further points to add context to the problem...&lt;/P&gt;

&lt;P&gt;Each of the 5 panels in the view run their own search, even though the base search is the same. e.g. index=firewall type=opsec attack="*" | ...  After the base search the results are piped to stuff like "top src_ip", "top des_ip", and stats. Since each panel uses the same base search I thought about using post processing to make things more efficient but I read in the documentation somewhere that you can't post process if the base search returns more than 10,000 events. My base search is returning close to 2 million matching events over the course of a week. &lt;span class="lia-unicode-emoji" title=":disappointed_face:"&gt;😞&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;So... that left things in a position where I have 5 saved searches, one for each dashboard panel. To try and speed things up I turned acceleration on for the searches and specified the summary period as 7 days (since I need to run this view to produce a PDF on a weekly basis). The acceleration doesn't appear to have had much (if any) effect.&lt;/P&gt;

&lt;P&gt;I've also tried opening the view, then going to the job manager and clicking save on each of the jobs that the view has kicked off thinking when they're done I can reopen the view and it should load the cached results. This doesn't work but I did learn that the searches take roughly 10 hours to complete &lt;span class="lia-unicode-emoji" title=":disappointed_face:"&gt;😞&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;Now I'm pretty sure I'm doing this in a way that's highly inefficient.. I know there must be a better way. Please help me with any ideas. I'm more than happy to provide more technical detail if need be.&lt;/P&gt;

&lt;P&gt;Thanks!&lt;/P&gt;</description>
    <pubDate>Mon, 28 Sep 2020 13:51:48 GMT</pubDate>
    <dc:creator>damuscat</dc:creator>
    <dc:date>2020-09-28T13:51:48Z</dc:date>
    <item>
      <title>Scheduled View not working</title>
      <link>https://community.splunk.com/t5/Reporting/Scheduled-View-not-working/m-p/27703#M500</link>
      <description>&lt;P&gt;Hi everyone. I've got an instance of Splunk 5.0.1 running with a large amount of firewall data coming into it daily (roughly 15GB). I created a relatively simply dashboard with 5 panels with the intent of scheduling the view for PDF delivery once per week. The view itself is fine, I tested it using a relatively short timespan on my search (e.g. last 60 mins of data). The problem is when I want to generate the view based on 1 week worth of data, it always fails and I suspect it has something to do with the large amount of data its trying to search through.&lt;/P&gt;

&lt;P&gt;Some further points to add context to the problem...&lt;/P&gt;

&lt;P&gt;Each of the 5 panels in the view run their own search, even though the base search is the same. e.g. index=firewall type=opsec attack="*" | ...  After the base search the results are piped to stuff like "top src_ip", "top des_ip", and stats. Since each panel uses the same base search I thought about using post processing to make things more efficient but I read in the documentation somewhere that you can't post process if the base search returns more than 10,000 events. My base search is returning close to 2 million matching events over the course of a week. &lt;span class="lia-unicode-emoji" title=":disappointed_face:"&gt;😞&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;So... that left things in a position where I have 5 saved searches, one for each dashboard panel. To try and speed things up I turned acceleration on for the searches and specified the summary period as 7 days (since I need to run this view to produce a PDF on a weekly basis). The acceleration doesn't appear to have had much (if any) effect.&lt;/P&gt;

&lt;P&gt;I've also tried opening the view, then going to the job manager and clicking save on each of the jobs that the view has kicked off thinking when they're done I can reopen the view and it should load the cached results. This doesn't work but I did learn that the searches take roughly 10 hours to complete &lt;span class="lia-unicode-emoji" title=":disappointed_face:"&gt;😞&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;Now I'm pretty sure I'm doing this in a way that's highly inefficient.. I know there must be a better way. Please help me with any ideas. I'm more than happy to provide more technical detail if need be.&lt;/P&gt;

&lt;P&gt;Thanks!&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 13:51:48 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Reporting/Scheduled-View-not-working/m-p/27703#M500</guid>
      <dc:creator>damuscat</dc:creator>
      <dc:date>2020-09-28T13:51:48Z</dc:date>
    </item>
    <item>
      <title>Re: Scheduled View not working</title>
      <link>https://community.splunk.com/t5/Reporting/Scheduled-View-not-working/m-p/27704#M501</link>
      <description>&lt;P&gt;Depending on your exact searches, you could merge them into one and then use postprocess. For example, take these two:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;index=firewall ... | top src_ip
index=firewall ... | top des_ip
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;You could merge them into this:&lt;/P&gt;

&lt;P&gt;index=firewall ... | top src_ip top des_ip&lt;/P&gt;

&lt;P&gt;And add post-process pipes like this:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;stats sum(count) as count by src_ip | eventstats sum(count) as sum | eval percent = count*100/sum | fields - sum | sort - count
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;Same for dst_ip, and you should get around some duplicate searches.&lt;/P&gt;

&lt;P&gt;That probably won't solve the issue entirely though - consider summary indexing.&lt;BR /&gt;
Staying with the &lt;CODE&gt;top&lt;/CODE&gt; example, you could compute a &lt;CODE&gt;stats count by src_ip&lt;/CODE&gt; every hour and store that in a summary index to use that for computing overall &lt;CODE&gt;top&lt;/CODE&gt; values.&lt;/P&gt;

&lt;P&gt;As for report acceleration, that can work brilliantly but its effect depends on the specific search. Also, make sure the report acceleration summary has finished building before checking its speed-up.&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 14:24:07 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Reporting/Scheduled-View-not-working/m-p/27704#M501</guid>
      <dc:creator>martin_mueller</dc:creator>
      <dc:date>2020-09-28T14:24:07Z</dc:date>
    </item>
  </channel>
</rss>

