<?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 Is it possible to ingest-time eval _indextime field? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501926#M85530</link>
    <description>&lt;P&gt;Hello!&lt;/P&gt;

&lt;P&gt;I have a distributed deployment of Splunk Enterprise. All my UFs send raw events to two HFs, these send cooked data to three-node IDX cluster. My search interface is three-node SH cluster. I plan to use a few ingest-time eval fields, first of all I tested how it works, placing:&lt;/P&gt;

&lt;P&gt;props.conf to HFs:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;props.conf
------------------------------------------------------------
[airwatch_iis_flogs]
TRANSFORMS = ingest-eval-rule-size_bytes, ingest-eval-rule-orig_host, ingest-eval-rule-orig_time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;transforms.conf to HFs:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;transforms.conf
------------------------------------------------------------
[ingest-eval-rule-size_bytes]
INGEST_EVAL = size_bytes=len(_raw)

[ingest-eval-rule-orig_host]
INGEST_EVAL = orig_host=upper(host)

[ingest-eval-rule-orig_time]
INGEST_EVAL = orig_time=_time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;fields.conf to SHs:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;fields.conf
------------------------------------------------------------
[size_bytes]
INDEXED = True

[orig_host]
INDEXED = True

[orig_time]
INDEXED = True
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I put props.conf/transforms.conf to HFs (not to IDXs) as these servers process all the raw events and cook the data for indexers. This configuration works like a charm: querying &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;index=* sourcetype=airwatch_iis_flogs
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I get the events having expected indexed fields size_bytes (calculated), orig_host (uppercase) and orig_host (match _time).&lt;/P&gt;

&lt;P&gt;Now, field of interest to me is _indextime. I want to index the latency:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;transforms.conf
 ------------------------------------------------------------
 [ingest-eval-rule-latency_sec]
 INGEST_EVAL = latency_sec=_indextime-_time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I also put the relevant changes to props.conf and fields.conf, but unfortunately this configuration doesn't work. Is it maybe because _indextime is empty while cooking events on HFs, and actually filled up while writing events to disk on indexers (not sure, where IndexQueue lives - on IDXs or HFs)? &lt;/P&gt;

&lt;P&gt;What should I do to use this _indextime field in ingest-time eval - maybe put:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;outputs.conf
------------------------------------------------------------
sendCookedData = false
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;to my HFs, move all props.conf/transforms.conf to IDXs? I feel myself, there are more drawbacks then benefts from this decision.&lt;/P&gt;

&lt;P&gt;Are there any more limitations using _indextime ingest-time eval?&lt;/P&gt;</description>
    <pubDate>Wed, 30 Sep 2020 02:32:38 GMT</pubDate>
    <dc:creator>oshirnin</dc:creator>
    <dc:date>2020-09-30T02:32:38Z</dc:date>
    <item>
      <title>Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501926#M85530</link>
      <description>&lt;P&gt;Hello!&lt;/P&gt;

&lt;P&gt;I have a distributed deployment of Splunk Enterprise. All my UFs send raw events to two HFs, these send cooked data to three-node IDX cluster. My search interface is three-node SH cluster. I plan to use a few ingest-time eval fields, first of all I tested how it works, placing:&lt;/P&gt;

&lt;P&gt;props.conf to HFs:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;props.conf
------------------------------------------------------------
[airwatch_iis_flogs]
TRANSFORMS = ingest-eval-rule-size_bytes, ingest-eval-rule-orig_host, ingest-eval-rule-orig_time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;transforms.conf to HFs:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;transforms.conf
------------------------------------------------------------
[ingest-eval-rule-size_bytes]
INGEST_EVAL = size_bytes=len(_raw)

[ingest-eval-rule-orig_host]
INGEST_EVAL = orig_host=upper(host)

[ingest-eval-rule-orig_time]
INGEST_EVAL = orig_time=_time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;fields.conf to SHs:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;fields.conf
------------------------------------------------------------
[size_bytes]
INDEXED = True

[orig_host]
INDEXED = True

[orig_time]
INDEXED = True
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I put props.conf/transforms.conf to HFs (not to IDXs) as these servers process all the raw events and cook the data for indexers. This configuration works like a charm: querying &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;index=* sourcetype=airwatch_iis_flogs
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I get the events having expected indexed fields size_bytes (calculated), orig_host (uppercase) and orig_host (match _time).&lt;/P&gt;

&lt;P&gt;Now, field of interest to me is _indextime. I want to index the latency:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;transforms.conf
 ------------------------------------------------------------
 [ingest-eval-rule-latency_sec]
 INGEST_EVAL = latency_sec=_indextime-_time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I also put the relevant changes to props.conf and fields.conf, but unfortunately this configuration doesn't work. Is it maybe because _indextime is empty while cooking events on HFs, and actually filled up while writing events to disk on indexers (not sure, where IndexQueue lives - on IDXs or HFs)? &lt;/P&gt;

&lt;P&gt;What should I do to use this _indextime field in ingest-time eval - maybe put:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;outputs.conf
------------------------------------------------------------
sendCookedData = false
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;to my HFs, move all props.conf/transforms.conf to IDXs? I feel myself, there are more drawbacks then benefts from this decision.&lt;/P&gt;

&lt;P&gt;Are there any more limitations using _indextime ingest-time eval?&lt;/P&gt;</description>
      <pubDate>Wed, 30 Sep 2020 02:32:38 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501926#M85530</guid>
      <dc:creator>oshirnin</dc:creator>
      <dc:date>2020-09-30T02:32:38Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501927#M85531</link>
      <description>&lt;P&gt;I believe it's not possible to reference the _indextime field at index time since it is not defined until after all other props and transforms are processed.  You'll need to calculate latency at search time.&lt;BR /&gt;
I'm waiting to be corrected on this.&lt;/P&gt;</description>
      <pubDate>Tue, 15 Oct 2019 13:18:40 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501927#M85531</guid>
      <dc:creator>richgalloway</dc:creator>
      <dc:date>2019-10-15T13:18:40Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501928#M85532</link>
      <description>&lt;P&gt;Hello, @richgalloway ! I feel the same. I think it would be enough to ingest-eval now() but strange - it doesn't work! Do you maybe see errors in the configs?&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;transforms.conf
------------------------------------------------------------
[ingest-eval-rule-time_now]
INGEST_EVAL = time_now = now()

props.conf
------------------------------------------------------------
[airwatch_iis_flogs]
TRANSFORMS = ingest-eval-rule-time_now

fields.conf
------------------------------------------------------------
[time_now]
INDEXED = True
&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Thu, 17 Oct 2019 13:24:05 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501928#M85532</guid>
      <dc:creator>oshirnin</dc:creator>
      <dc:date>2019-10-17T13:24:05Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501929#M85533</link>
      <description>&lt;P&gt;Why ingest &lt;CODE&gt;now()&lt;/CODE&gt;?  _indextime is already available and it pretty much the same thing.&lt;/P&gt;</description>
      <pubDate>Fri, 18 Oct 2019 15:07:35 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501929#M85533</guid>
      <dc:creator>richgalloway</dc:creator>
      <dc:date>2019-10-18T15:07:35Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501930#M85534</link>
      <description>&lt;P&gt;Hi &lt;a href="https://community.splunk.com/t5/user/viewprofilepage/user-id/153721"&gt;@oshirnin&lt;/a&gt; ,&lt;BR /&gt;
the eval statement now() is not available for INGEST_EVAL. But you can use time(), which does pretty much the same and which can be used for INGEST_EVAL. So please try the following:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[ingest-eval-rule-latency_sec]
INGEST_EVAL = latency_sec= time() - _time
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I had a similar requirement yesterday and tested that successfully. This will also give more accuracy than _indextime, since time() includes subseconds, which are not available in _indextime, potentially leading to negative latency values when _indextime and _time are in the same second. &lt;/P&gt;

&lt;P&gt;Cheers&lt;/P&gt;</description>
      <pubDate>Wed, 30 Sep 2020 04:08:46 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/501930#M85534</guid>
      <dc:creator>norbert_hamel</dc:creator>
      <dc:date>2020-09-30T04:08:46Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/508194#M86484</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;SPAN&gt;norbert_hamel&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I try to get time() in my Heavy Forwarder, doesn't seem working.&lt;/P&gt;&lt;P&gt;Are you putting the ingest_eval at your heavy forwarder as well?&lt;/P&gt;&lt;P&gt;And what is your Splunk version&lt;/P&gt;&lt;P&gt;Many thanks.&lt;/P&gt;&lt;P&gt;Cheers,&lt;/P&gt;&lt;P&gt;S&lt;/P&gt;</description>
      <pubDate>Wed, 08 Jul 2020 22:07:07 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/508194#M86484</guid>
      <dc:creator>season88481</dc:creator>
      <dc:date>2020-07-08T22:07:07Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/508196#M86485</link>
      <description>&lt;P&gt;Please ignore my question. Heavy Forwarder seems able to get time() as well. My Splunk version is 7.3.1&lt;/P&gt;</description>
      <pubDate>Wed, 08 Jul 2020 22:18:52 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/508196#M86485</guid>
      <dc:creator>season88481</dc:creator>
      <dc:date>2020-07-08T22:18:52Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/581874#M102541</link>
      <description>&lt;P&gt;Hi Guys,&lt;/P&gt;&lt;P&gt;This is a very interesting topic, for which I've made an app, not only for HF's but also for the IDX's, however I do see some challenges here...&lt;BR /&gt;First of all I took a little different approach in props.conf, as I used the [default] stanza, with the aim to hit ALL events coming in.&lt;BR /&gt;It works - to a curtain extend, but it's really wired (to me) how, as most UF's sends their data through the HF's, and some directly to the IDX's, and for some strange reason, that I've spend quite some time investigating - without a solution (nor explanation) yet.&lt;/P&gt;&lt;P&gt;Some hosts "hits" the transforms (props) and gets the new values, and some don't, even though the all pass the same HF's.&lt;/P&gt;&lt;P&gt;Of those host sending directly to the IDX's none of them "hits" the transforms.&lt;/P&gt;&lt;LI-CODE lang="c"&gt;transforms.conf
---------------------------
[ingest-eval-rule-timeskew]
INGEST_EVAL = timeSkew=time() - _time
WRITE_META=true

[ingest-eval-rule-evtsize]
INGEST_EVAL = evtSizeB=len(_raw)
WRITE_META=true

[ingest-eval-rule-tierhost]
INGEST_EVAL = tierHost=replace(splunk_server,"\..*","")
WRITE_META = true

props.conf
---------------------------
[default]
TRANSFORMS = ingest-eval-rule-timeskew, ingest-eval-rule-evtsize, ingest-eval-rule-tierhost

fields.conf
---------------------------
[timeSkew]
INDEXED = True

[evtSizeB]
INDEXED = True

[tierHost]
INDEXED = True&lt;/LI-CODE&gt;&lt;P&gt;Does anyone of you have an idea about:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Why none of the data parsing direct to the IDX's don't "hit" this transform?&lt;/LI&gt;&lt;LI&gt;Why some hosts (UF's) sending data through the HF's "hits" and some don't?&lt;/LI&gt;&lt;/OL&gt;</description>
      <pubDate>Thu, 20 Jan 2022 11:17:30 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/581874#M102541</guid>
      <dc:creator>BDein</dc:creator>
      <dc:date>2022-01-20T11:17:30Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to ingest-time eval _indextime field?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/581890#M102542</link>
      <description>&lt;P&gt;I actually just got this one into place by simply adding a wildcard to props.conf, so it now looks like this:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;[default]
TRANSFORMS = ingest-eval-rule-timeskew, ingest-eval-rule-evtsize, ingest-eval-rule-tierhost

[(?::){0}*]
TRANSFORMS = ingest-eval-rule-timeskew, ingest-eval-rule-evtsize, ingest-eval-rule-tierhost&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;And now all - except for a few internal sourcetypes, it's great.&lt;/P&gt;</description>
      <pubDate>Thu, 20 Jan 2022 13:41:07 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Is-it-possible-to-ingest-time-eval-indextime-field/m-p/581890#M102542</guid>
      <dc:creator>BDein</dc:creator>
      <dc:date>2022-01-20T13:41:07Z</dc:date>
    </item>
  </channel>
</rss>

