<?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: Best practice on false positives in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183305#M36690</link>
    <description>&lt;P&gt;Can they be applied to the _raw field as well?&lt;/P&gt;</description>
    <pubDate>Thu, 19 Dec 2013 08:29:15 GMT</pubDate>
    <dc:creator>FRoth</dc:creator>
    <dc:date>2013-12-19T08:29:15Z</dc:date>
    <item>
      <title>Best practice on false positives</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183302#M36687</link>
      <description>&lt;P&gt;What do you regards as the best practice to filter false positives from all views. &lt;BR /&gt;&lt;BR /&gt;
Currently I add all false positives to a search macro like this: &lt;BR /&gt;&lt;BR /&gt;
Macro: fps &lt;BR /&gt;&lt;BR /&gt;
Expression: ( "user1234" OR "admin123" ) &lt;BR /&gt;&lt;BR /&gt;
&lt;BR /&gt;&lt;BR /&gt;
Then I use the " NOT `fps`" string in the search to filter the false positives from the view. Would you regard this as a good idea. I find it quite handy to change the single statement that is included in all searches and panels. A problem I have is that the expression grew pretty big and some of the searches from dashboard panels fail because of an over long URL query. &lt;BR /&gt;&lt;BR /&gt;
Would you prefer using "tags" or something else?&lt;/P&gt;</description>
      <pubDate>Wed, 18 Dec 2013 14:44:48 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183302#M36687</guid>
      <dc:creator>FRoth</dc:creator>
      <dc:date>2013-12-18T14:44:48Z</dc:date>
    </item>
    <item>
      <title>Re: Best practice on false positives</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183303#M36688</link>
      <description>&lt;P&gt;I consider this a problem to be tuned on a per search basis. Generally I try to avoid doing the &lt;CODE&gt;NOT this NOT that&lt;/CODE&gt; approach, but we all have to do it at times. I find it generally better to tune each search because there might be a case where something is a false positive for one search but not another search. In addition, as you noted, there becomes a management overhead and possible performance issue with it growing too big.&lt;/P&gt;

&lt;P&gt;You could make a saved search of &lt;CODE&gt;fps&lt;/CODE&gt; that included all the other eventtypes, tags, macros, or other saved searches you create to mark false positives, but having a single definition used in too many places might bite you in the future.&lt;/P&gt;

&lt;P&gt;So, specifically I try to change my searches to be more specific in ways that won't find false positives and don't require negating a bunch of stuff manually. This is easier done with more complex profiling rather than simpler pattern matching searches, of course.&lt;/P&gt;</description>
      <pubDate>Wed, 18 Dec 2013 15:09:52 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183303#M36688</guid>
      <dc:creator>jtrucks</dc:creator>
      <dc:date>2013-12-18T15:09:52Z</dc:date>
    </item>
    <item>
      <title>Re: Best practice on false positives</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183304#M36689</link>
      <description>&lt;P&gt;I like to use tags for this use case. Tags can be applied to any field, or can be applied to an eventtype for a more complex exclusion.&lt;/P&gt;</description>
      <pubDate>Wed, 18 Dec 2013 15:17:47 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183304#M36689</guid>
      <dc:creator>dart</dc:creator>
      <dc:date>2013-12-18T15:17:47Z</dc:date>
    </item>
    <item>
      <title>Re: Best practice on false positives</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183305#M36690</link>
      <description>&lt;P&gt;Can they be applied to the _raw field as well?&lt;/P&gt;</description>
      <pubDate>Thu, 19 Dec 2013 08:29:15 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Best-practice-on-false-positives/m-p/183305#M36690</guid>
      <dc:creator>FRoth</dc:creator>
      <dc:date>2013-12-19T08:29:15Z</dc:date>
    </item>
  </channel>
</rss>

