Hi,  I am having an issue with my data ingestion. I have a xml log file that I am ingesting that is 1GB in size but is taking up to 18GB of my ingestion license. How do I correct this. I did a test to convert the data to json but I am still seeing mix matches between the log file size and the data being ingested into Splunk.  I am checking on the daily ingestion vs daily log size 

What I am trying to do is graph / timechart active users.   I am starting with this query: index=anIndex sourcetype=perflogs  | rex field=_raw "^(?:[^,\n]*,){2}(?P<LoginUserID>\w+\.\w+)" | timechart distinct_count(LoginUserID) partial=false This works and the resulting graph appears to be correct for 120 mins resulting in 5min time buckets.  Then if I shorten the time period down to 60 mins resulting in 1 min buckets then I have a question. In the 120 min graph with 5 min buckets @ 6:40-6:45 I have 318 Distinct Users but in the 90 min graph with 1 min buckets each 1 min bucket has 136, 144, 142, 131, 117 Distinct Users. I understand that a user can be active one minute and inactive the next min or two and then active again on the 4th/5th min which is what is happening? My question is how to get this to show across the one minute bin's users that were active in the previous 5, 1 min buckets resulting in a # that represents users that are logged in and not just active ? I believe I can add minspan=5min as a kludge but am wondering if there is a way to get this do what im trying to show at the 1min span ? I believe what I need to do is run two queries the first one as is above, then use an append that will query for  events from -5min to -10min.   But, from what I have been trying it either is not working or not doing it correctly. Basically im trying to find those userID's that are active in the first time bucket (1 min) that were also active in the previous time bucket(s) then do a distinct_count(..) on the usersID's collected from both queries ?

We have a Splunk v9.1.1 cluster with a three search head SHC running on EC2 instances in AWS. In implementing disaster recovery (DR) for the SHC, I configured AWS Autoscaling to replace the search heads on failure. Unfortunately with Autoscaling, it does NOT re-use the IP of the failed instance on the new instance, probably due to other use cases of up- and down-scaling. So new replacement instances will always have new/different IPs than that of the failed instance. Starting with a healthy cluster with an elected search head captain and RAFT running, I terminated one search head. During the minute or two that it took AWS Autoscaling to replace the search head instance, RAFT stopped and there was no captain. I was then unable to add a NEW third search head to the cluster. OK, so then I created a similar scenario but this time had Autoscaling issue the commands to force one of the remaining two search heads to be an UN-ELECTED static captain - and then confirmed this had worked; I had two search heads, one being a captain. In the Splunk documentation, it mentions using a Static Captain for DR. However, when I again tried to add the new instance as the third search head, I again received the error that RAFT was not running, there was no cluster, and therefore the member could not be added! So what is Splunk's recommendation for Disaster Recovery in this situation? I understand this is a chicken-and-egg scenario, but how are you expected to recover if you can't get a third search head in place in order TO recover? It seems counter-intuitive that Splunk would disallow adding a third search head, especially with the static search head captain in place. There are some configurable timeout parameters in server.conf in the [shcluster] stanza - would increasing any of these values keep the SHC in place long enough for Autoscaling to replace that third search head instance such that it can then join the SHC? If so, which timeouts should I use, and which values would be appropriate that they wouldn't interfere with the day-in, day-out usage? I'm stuck on this and haven't been able to progress any further. Any and all help is greatly appreciated!