<?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 Re: How do we keep Splunk from complaining about an event it's going to drop anyway? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308181#M58032</link>
    <description>&lt;P&gt;That is based on my experience. You can always open a support ticket and see what Splunk says.&lt;/P&gt;</description>
    <pubDate>Fri, 17 Feb 2017 21:42:33 GMT</pubDate>
    <dc:creator>starcher</dc:creator>
    <dc:date>2017-02-17T21:42:33Z</dc:date>
    <item>
      <title>How do we keep Splunk from complaining about an event it's going to drop anyway?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308176#M58027</link>
      <description>&lt;P&gt;Here's the setup:&lt;/P&gt;

&lt;P&gt;We have a sourcetype that we exclude certain events by routing them to the nullQueue based on a REGEX with a props/transforms stanza duo. This action works as we would expect; the events we do not want are not indexed.&lt;/P&gt;

&lt;P&gt;What we've come to learn is that some of these lines are more than 10,000 characters. We have not updated the TRUNCATE setting for these events because we drop them and to our knowledge no other events in the file exceed this length.&lt;/P&gt;

&lt;P&gt;We didn't realize that LineBreakingProcessor would still complain about truncating the events. If I understand Splunk data correctly, the nullQueue routing occurs at the index pipeline which is downstream from the parsing pipeline.&lt;/P&gt;

&lt;P&gt;In an effort to clear up our _internal and reduce the amount of time Splunk spends on the parsing pipeline, is there any way to catch these events before they hit the parsing queue? Perhaps at the forwarder layer?&lt;/P&gt;

&lt;P&gt;If not, what are the performance implications of continually raising the TRUNCATE setting? We've done this for several data sources that we need and are actually really long (splunkd_remote_searches, itsi_internal_log, various structured XML/JSON data sources) and I would like to be confident we are not setting ourselves up for more issues. We index multiple terabytes a day.&lt;/P&gt;

&lt;P&gt;Thank you!&lt;/P&gt;</description>
      <pubDate>Tue, 29 Sep 2020 12:54:54 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308176#M58027</guid>
      <dc:creator>paulstout</dc:creator>
      <dc:date>2020-09-29T12:54:54Z</dc:date>
    </item>
    <item>
      <title>Re: How do we keep Splunk from complaining about an event it's going to drop anyway?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308177#M58028</link>
      <description>&lt;P&gt;The best performance is not to send it.  If you use Universal Forwarders to pick up the files then I would black list those files from the folder and just send the ones you want. Making Splunk process it for null queue at scale can seriously backup your indexing pipelines.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Feb 2017 21:08:56 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308177#M58028</guid>
      <dc:creator>starcher</dc:creator>
      <dc:date>2017-02-17T21:08:56Z</dc:date>
    </item>
    <item>
      <title>Re: How do we keep Splunk from complaining about an event it's going to drop anyway?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308178#M58029</link>
      <description>&lt;P&gt;The challenge is that we want most of the events in the log, so blacklisting the file will not work for us. It's only certain junk lines within the file we are indexing that we want to discard. If there's a way to filter only certain events within a log file we need this at the UF layer, please share!&lt;/P&gt;

&lt;P&gt;example.log&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP ABSOLUTE JUNK THAT MAKES NO SENSE AND JUST CONFUSES SEARCHES&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;BR /&gt;
TIMESTAMP INFO INFO StuffWeWant&lt;/P&gt;</description>
      <pubDate>Fri, 17 Feb 2017 21:12:35 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308178#M58029</guid>
      <dc:creator>paulstout</dc:creator>
      <dc:date>2017-02-17T21:12:35Z</dc:date>
    </item>
    <item>
      <title>Re: How do we keep Splunk from complaining about an event it's going to drop anyway?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308179#M58030</link>
      <description>&lt;P&gt;There is no parsing and filtering at the UF with the one exception being windows event codes. If you require inspecting parsing the log stream to decide to throw it away then you are already doing what you can. Best you can do is keep increasing truncate which can impact memory etc. The best option is going to tune what you log. If this is some application log you control I would put into your roadmap to log application events via HEC and get away from trying to eat things java logs.  You could consider increasing your input pipelines so you are less likely to jam inbound for other sources. Or send these logs onto to dedicated inputs on certain systems to segregate it.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Feb 2017 21:17:08 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308179#M58030</guid>
      <dc:creator>starcher</dc:creator>
      <dc:date>2017-02-17T21:17:08Z</dc:date>
    </item>
    <item>
      <title>Re: How do we keep Splunk from complaining about an event it's going to drop anyway?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308180#M58031</link>
      <description>&lt;P&gt;I was afraid of that. The events are quite infrequent and we run at a pretty low mem% so this may be the only option for now. Thanks!&lt;/P&gt;

&lt;P&gt;I just found it odd that Splunk would process the event through the entire pipeline just to throw it away at the end. Seems it would make more sense to pick up that the event was destined for the nullQueue and drop it first before applying additional processing.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Feb 2017 21:20:32 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308180#M58031</guid>
      <dc:creator>paulstout</dc:creator>
      <dc:date>2017-02-17T21:20:32Z</dc:date>
    </item>
    <item>
      <title>Re: How do we keep Splunk from complaining about an event it's going to drop anyway?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308181#M58032</link>
      <description>&lt;P&gt;That is based on my experience. You can always open a support ticket and see what Splunk says.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Feb 2017 21:42:33 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-do-we-keep-Splunk-from-complaining-about-an-event-it-s-going/m-p/308181#M58032</guid>
      <dc:creator>starcher</dc:creator>
      <dc:date>2017-02-17T21:42:33Z</dc:date>
    </item>
  </channel>
</rss>

