<?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: indexes.conf sanity question. in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492937#M84262</link>
    <description>&lt;P&gt;I hear what you are saying, and it makes sense. However...&lt;/P&gt;

&lt;P&gt;We do not control the disk settings, they are what they are, /hotwarm is N-tb and /cold is N-tb. &lt;/P&gt;

&lt;P&gt;You're talking about setting &lt;CODE&gt;homePath.maxDataSizeMB&lt;/CODE&gt; right? So what happens if I set that to say, 500GB on index1, but over the period of a year that index1 never exceeds that limit. It will never roll to cold, but will get rolled to frozen after 13 months. So now hotwarm will fill and the storage in cold will never be utilized by index1. &lt;/P&gt;

&lt;P&gt;Or.. If I abandon all time-based settings as you suggest and just set wholesale caps on the data at the volume level with, &lt;CODE&gt;maxVolumeDataSizeMB&lt;/CODE&gt; for hotwarm and cold and at an index level using &lt;CODE&gt;homePath.maxDataSizeMB&lt;/CODE&gt; and &lt;CODE&gt;coldPath.maxDataSizeMB&lt;/CODE&gt; .  We now have low volume indexes keeping more than 13 months because they never reached that cap, which we don't want. Also,what happens when someone gets goofy and turns on debug log levels on 3000 hosts and fills the max sizes overnight? All of my historical is now gone and our 13 month retention period requirement is shot. I mean, I'd rather the disk fill, Splunk fall over and not log new debug crap than push my good data into a bit bucket or frozen.&lt;/P&gt;</description>
    <pubDate>Wed, 18 Mar 2020 15:27:01 GMT</pubDate>
    <dc:creator>JDukeSplunk</dc:creator>
    <dc:date>2020-03-18T15:27:01Z</dc:date>
    <item>
      <title>indexes.conf sanity question.</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492935#M84260</link>
      <description>&lt;P&gt;I wanted to ask here before making this change, for just another set of eyes.&lt;/P&gt;

&lt;P&gt;Issue. We have /hot and /cold both with equal amounts of storage, with no difference between the storage speed on either volume. Currently data is rolling to cold at 90 days, and so cold is filling up and leaving hot about 20% full.&lt;/P&gt;

&lt;P&gt;I'd like to set the following to try and keep data in hot/warm for almost 1/2 of our global 13 month retention period. Do the following settings make sense?&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[default]
#######retentions and hotwarm limits#######
repFactor = auto

#To balance disk space keep warm more warm buckets that the default 300.
maxWarmDBCount = 3600

#Idle hot buckets roll to warm if no data is written to them in a day.
maxHotIdleSecs = 86400

#Upper bound of timespan of hot/warm buckets, in seconds.
maxHotSpanSecs = 15778476

#13 Months and data will roll to bitbucket unless a frozen directory is specified in their stanza.
frozenTimePeriodInSecs = 34136000

#Data coming in on an unconfigured index will land in sandbox.
lastChanceIndex = sandbox
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;Thanks.&lt;/P&gt;</description>
      <pubDate>Wed, 18 Mar 2020 14:10:56 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492935#M84260</guid>
      <dc:creator>JDukeSplunk</dc:creator>
      <dc:date>2020-03-18T14:10:56Z</dc:date>
    </item>
    <item>
      <title>Re: indexes.conf sanity question.</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492936#M84261</link>
      <description>&lt;P&gt;You are doing it all wrong.  You need to forget about the &lt;CODE&gt;time-based&lt;/CODE&gt; settings and configure &lt;CODE&gt;volume-based&lt;/CODE&gt; settings.  That way you can let &lt;CODE&gt;hot/warm&lt;/CODE&gt; fill based on size.  Better yet, do that AND create a logical volume that contains both your current &lt;CODE&gt;hot/warm&lt;/CODE&gt; and your &lt;CODE&gt;cold&lt;/CODE&gt; and then don't configure &lt;CODE&gt;cold&lt;/CODE&gt; at all.  If it is the same storage type, it should be the same &lt;CODE&gt;volume&lt;/CODE&gt; and there is no need to complicate things by having &lt;CODE&gt;cold&lt;/CODE&gt; at all.&lt;/P&gt;</description>
      <pubDate>Wed, 18 Mar 2020 14:36:50 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492936#M84261</guid>
      <dc:creator>woodcock</dc:creator>
      <dc:date>2020-03-18T14:36:50Z</dc:date>
    </item>
    <item>
      <title>Re: indexes.conf sanity question.</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492937#M84262</link>
      <description>&lt;P&gt;I hear what you are saying, and it makes sense. However...&lt;/P&gt;

&lt;P&gt;We do not control the disk settings, they are what they are, /hotwarm is N-tb and /cold is N-tb. &lt;/P&gt;

&lt;P&gt;You're talking about setting &lt;CODE&gt;homePath.maxDataSizeMB&lt;/CODE&gt; right? So what happens if I set that to say, 500GB on index1, but over the period of a year that index1 never exceeds that limit. It will never roll to cold, but will get rolled to frozen after 13 months. So now hotwarm will fill and the storage in cold will never be utilized by index1. &lt;/P&gt;

&lt;P&gt;Or.. If I abandon all time-based settings as you suggest and just set wholesale caps on the data at the volume level with, &lt;CODE&gt;maxVolumeDataSizeMB&lt;/CODE&gt; for hotwarm and cold and at an index level using &lt;CODE&gt;homePath.maxDataSizeMB&lt;/CODE&gt; and &lt;CODE&gt;coldPath.maxDataSizeMB&lt;/CODE&gt; .  We now have low volume indexes keeping more than 13 months because they never reached that cap, which we don't want. Also,what happens when someone gets goofy and turns on debug log levels on 3000 hosts and fills the max sizes overnight? All of my historical is now gone and our 13 month retention period requirement is shot. I mean, I'd rather the disk fill, Splunk fall over and not log new debug crap than push my good data into a bit bucket or frozen.&lt;/P&gt;</description>
      <pubDate>Wed, 18 Mar 2020 15:27:01 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/indexes-conf-sanity-question/m-p/492937#M84262</guid>
      <dc:creator>JDukeSplunk</dc:creator>
      <dc:date>2020-03-18T15:27:01Z</dc:date>
    </item>
  </channel>
</rss>

