Hi @man03359 , at first, in frozenTimePeriodInSecs, don't use commas. then, the meaning of the four statuses is the following: Hot: just indexed data, in a bucket with in progress tsdindexes creation and usable for on-line searches, Warm: data indexed from few days, that are used by the most searches and usable for on-line searches, they usually are located in high performances storage (at least 800 IOPS, better more), Cold: not so recent data, used by few searches and usable for on-line searches, they usually are located in less expensive storages, Frozen: data that are stored off line but that it's possible to recoved copying the entire bucket in the thawed folder, to have frozen data, you must configure Splunk to save them, by default dey are deleted. Data roll to frozed after the earliest event of a bucket exceeds the retention period, for this reason you could have , in your searches, data before the retention period. if you use a short retention period and you index few data, your bucket could directly pass from Warm to frozen or be deleted. It's very difficoult that a data directly pass from Hot to Frozed because a bucket rolls from Hot to Warm when it reaches 10 GB or after three days, you should have a retention period less than three days and have less than 10 GB in this period. For more details see at https://docs.splunk.com/Documentation/Splunk/9.2.0/Indexer/Setaretirementandarchivingpolicy and https://docs.splunk.com/Documentation/Splunk/9.2.0/Indexer/Howindexingworks Ciao. Giuseppe

Have a look at Replicate a subset of data to a third-party system You can modify it and do something like this props.conf [your-sourcetype-here] TRANSFORMS-routing = routeAll transforms.conf [routeAll] REGEX=(.) DEST_KEY=_TCP_ROUTING FORMAT=yourIndexer,ThirdParty outputs.conf [tcpout] defaultGroup=nothing [tcpout:yourIndexer] disabled=false server=10.1.12.1:9997 [tcpout:ThirdParty] disabled=false sendCookedData=false server=10.1.12.2:1234  

You need to include agent logs, and that will collect daemonset, clusterReceiver and gateway logs, you can configure it using this option - https://github.com/signalfx/splunk-otel-collector-chart/blob/main/helm-charts/splunk-otel-collector/values.yaml#L572

@kamlesh_vaghela  Sir,  May I ask for a help , If I want to limit user to use this method  Could u please teach me how tow set the least privilege I just know that config power user and edit-kvstore , but I don't want give the normal user to much  thanks for help  

Or, in the old fashioned extract (aka kv) and foreach ,   | rename _raw AS temp, provTimes AS _raw | rex mode=sed "s/\S+=/provTimes_&/g" | kv | foreach provTimes_* [eval sum = mvappend(sum, '<<FIELD>>')] | eval sum = sum(sum) ``` below are cleanups, only if you want to restore world order ``` | fields - provTimes_* | rex mode=sed "s/provTimes_//g" | rename _raw AS provTimes, temp AS _raw   Here is an emulation you can play with and compare with real data   | makeresults format=csv data="provTimes a=10; b=15; c=10; x=10; b=5;" ``` data emulation above ```   Output from this emulation is provTimes sum a=10; b=15; c=10; 35 x=10; b=5; 15

I cannot seem to reproduce your results.  I put your sample CSV into my laptop.  The setting is   [dhcp_timebased_lookup] batch_index_query = 0 case_sensitive_match = 1 filename = dhcp_timebased_lookup.csv max_offset_secs = 691200 time_field = time   Then, I run this search   | makeresults | eval dest_ip = "10.223.5.43" | stats values(dest_ip) as dest_ip by _time | lookup dhcp_timebased_lookup ip AS dest_ip output time hostname | eval lag = _time - time | eval time = strftime(time, "%F %T")   It gives _time dest_ip hostname lag time 2024-02-28 14:16:08 10.223.5.43 host-43 64871 2024-02-27 20:14:57 I had a suspicion about that time_format setting. (Splunk defaults to using second.)  But even after I add this, it still returns result. Could you try this on a spare instance?

IMO this might get a lot more fiddly than you think.  If the system is sending in logs all the time (like, let's use for example they're Apache web servers), then even if you restart one, it'll come back online and catch up almost immediately.  You can take that farther - even if you turn off the forwarder for a week, when it gets turned back on it'll catch back up (possibly in just a couple of minutes!).    A week of "not reporting" just gets swept under the rug. If you actually have *gaps* in your logs, this is ... an entirely separate issue and you should solve that, because that's not a thing that should really happen and it's generally fixable. A bit better might be to use some shenanigans with the _indextime field, but it's also unlikely to be easily converted to a proper "wasn't sending in data" type report.  It might be closer, but it's still a lot of extra work. Even better than that might be to read some of the _internal indexes (the metrics one comes to mind) to find out there which 30 second periods it wasn't responding in (or whatever).  That would be more accurate. But possibly best when it comes to that sort of information might be just getting the forwarder's messages that say "I'm restarting" and "I've restarted".  THOSE would be easier to calculate a proper "downtime" from.  You can start here: index=_internal source=*splunkd.log* ("shutdown complete" OR "Splunkd starting") As long as your internal retention is long enough, that should get you each stop/start sequence - you'll have to then eval some fields, do some stats with a 'by host' and so on, but it should get close.  You could also use the above by host and | collect it to a summary index to keep just that information around for longer than retention on _internal would normally allow. It will NOT tell you if the host was actually offline though - if you disconnect the network cable... well, you should try it and see what logs show up for that!  I don't think it can tell you it disconnected, only that it reconnected but maybe there's a "seconds I was unable to talk to you" in that message too.  (Don't think so). Anyway, I'm sure that's a lot more words than you were expecting, but I wanted to explain the pitfalls of some of the first attempts people make for this sort of answer, since they don't often work that well.  Also happy to continue helping once you've explored a bit on your own, so if you get stuck ... post again in here!

I'm not completely clear on what the question is asking, but for the sake of a) getting discussion started to determine that and b) maybe this is what you are looking for anyway, ... The big search for total time - those last three lines, try changing them to the following 5. ... | stats sum(time_difference) AS TOTAL, count as COUNT | eval AVERAGE_TIME_PER_EVENT = TOTAL / COUNT | fieldformat TOTAL = strftime(TOTAL, "%H:%M:%S") | eval AVERAGE_TIME_PER_EVENT = tostring(AVERAGE_TIME_PER_EVENT, "duration") | table COUNT, TOTAL, AVERAGE_TIME_PER_EVENT  I don't think I have any typos in the above, but maybe they exist.  Anyway, all I do differently is add the count into your stats, eval a new field that's the total / count.  Then I leave your fieldformat the same, but right after that I introduce you to "tostring" with a type of duration, that should do what you want just like the fieldformat (H:M:S) but will ALSO add "days" to the front when appropriate (like 1+14:21:54 for 1 day plus 14 hours, blah blah.).  You can change both to eval or use fieldformat for both - it's fine either way. Lastly I added the two new fields to the table. If this is no where near what you want the answer to, ... well, maybe clarify your question a bit!  Happy Splunking, Rich