TZ only works if there is no time zone information in the event itself. The provided sample event clearly has a time zone value (+0000), so TZ = UTC is disregarded. ... View more

Hi @hemendralodhi , When Splunk writes a timestamp to an index at index time, it gets written as an epoch time value, which is unaware of time zone information. At that point, it is up to the search head to present that epoch time value in way that is relevant to the time zone of the user. As per the docs (https://docs.splunk.com/Documentation/Splunk/latest/Admin/Propsconf) your time zone setting in props.conf of TZ = UTC does not do anything because there is time zone information in the event itself, which takes precedence. From your image, it looks like the event is being displayed by a user who has their time zone set to GMT (UTC). But it's also confusing because the date_zone value suggests that the events have been written as GMT+11:00. There is something odd going on there. If it were written as GMT+11:00 the time stamp in your event would not match the event time value. I understand that you may not want to set the time zone in the web interface, but that is the best way to do it. If you modify the timestamp values as they're written at index time, you're not going to have good results down the road because this is not best practice, and is inconsistent with the way Splunk tracks time. If the search head is set as AEDT, then by default any user who does not set his time zone setting will be using the time zone of the search head. ... View more

You'll need to write that more clearly, and use the backticks around your rex statement so special characters don't get removed. What's the whole search? And what does an event look like for that search where the rex matches? ... View more

Much clearer... Definitely no need for 2 rex statements for that. The one I provided above in the answer works on that. ... View more

Ok, but if v1 = abcdef.us12345 and v2 = abcdef.us:12345 do you really need to differentiate between v1 & v2, or are you just trying to capture the data? If you don't care you would use: | rex ".*(?<v1>abc\S+\d{1,5})$" If you DO care then you would use: | rex ".*(?<v2>abc[^:]+:\d{1,5})|(?<v1>abc\S+\d{1,5})$" ... View more

Yes, you can have it accelerated for all time. You would still be limited to the retention period of the index that contributes to the data model. I would be careful with setting it to all time though, because of the disk space usage as you've mentioned. You could probably get a better answer if you provided a specific use case. Or were you just curious? ... View more

Hi @cthulhucalling , As some of the others have said, you can have wildcards in your lookups, but you have to specify it in the advanced settings in the web interface (UI). Here is an example of how you would do that: Once you have the lookup configured, you can use the following search logic: | lookup web_attack_sigs uri_path OUTPUT description Here is what it looks like: ... View more

In most cases, yes. Could you clarify what v1 is and what v2 is in your raw line? Is v1 an ip address? Give me an example of v1 and v2. Thanks. ... View more

That's a bad assumption. In SplunkCloud the indexers & search heads are usually separate. If you installed the TA on the search head, then you will still need to install it on the indexer. ... View more

Use the backtick before and after your line to show all special characters ... View more

Hi reverese, Can you please modify your question using a backtick character before and after your sample line? But here's what you can do with the rex command: | rex "^(?<v1>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*(?<v2>abc\S+\d{5})$" ... View more

No. You don't have to install the data model on any search peers. You only configure it on the search head. If you accelerate the data model, the indexers (search peers) will automatically create the associated accelerated summaries. Nothing needs to be modified on the indexers. ... View more

Hi Badoomi, You're using the lookup in the wrong way to achieve your results. @richgalloway is almost right in his answer: index=fw OR index=waf | lookup mal_ip mal_ip as src OUTPUT category product port | stats count by src category However, if you want to match more than src, and you need to check the product and the port as well it would be written as follows: index=fw OR index=waf | lookup mal_ip mal_ip as src product as product port as port OUTPUT category | stats count by src category This will match against src, product, and port. But product and port have to be extracted/defined before using the | lookup in that search. ... View more

As I explained in my original response, that's not a bug. The stanza names are the same, so Splunk has to choose settings from the one that takes precedence. That's the way Splunk works with .conf file precedence. crcSalt works. If you have two stanzas that reference the same group of files, Splunk uses crcSalt to determine if it has read a particular file previously to prevent double ingestion (as in the case if you have symlinked files/folders, by default it will NOT ingest the file if it sees it has encountered it previously). If you're going with the symlink idea, would you mind selecting the correct answer for your request? ... View more

Hi verbal_666, Your solution will not work because of the way Splunk reads .conf files. It uses .conf file precedence to pick only one of those two stanzas, because the stanza name is exactly the same. There are a couple of ways to do what you're asking: 1. Run a collect command to "copy" the events from the main index to the text index 2. Install a second UF on the same box with different management ports to monitor the same file, but put it in a different index 3. Duplicate the file at the OS level and create two different stanzas in Splunk (ie; Create a symlink for the folder) <-- This is probably the best way I was able to verify this works: mkdir /tmp/test-ingest ln -s /tmp/test-ingest /tmp/duplicate-ingest Splunk inputs.conf : [monitor:///tmp/test-ingest/*.txt] index=test sourcetype=TMP:TXT crcSalt = one [monitor:///tmp/duplicate-ingest/*.txt] index=main sourcetype=TMP:TXT_BIS crcSalt = two Create dummy data from OS: echo Testing data to two indexes. > /tmp/test-ingest/testing.txt ... View more

Hi Brycewe22, It would be helpful for you to post a sample of what your events with HTTP response codes look like. ... View more

maxWarmDBCount is number of buckets as per the Splunk documentation: maxWarmDBCount = [Non-negative Integer] * The maximum number of warm buckets. * Warm buckets are located in the for the index. * If set to zero, Splunk will not retain any warm buckets (will roll them to cold as soon as it can) * Highest legal value is 4294967295 * Defaults to 300. Therefore, your original thought would be valid, where you have a 200 day bucket for 50MB / day in a 10GB bucket. If you want to have something span a time period instead of the size of the buckets, you have to use maxHotSpanSecs . That is the only way to limit a bucket by time range. ... View more

Hi, If you're NOT using maxHotSpanSecs AND maxDataSize = auto_high_volume (not maxTotalDataSizeMB, which relates to the total size of an index. This defaults to 500GB.), then yes, the hot buckets will wait to fill up to 10GB (~200 days of your 50MB / day), unless you restart Splunk (at which point, all hot buckets get rolled to warm) frequently. This is probably not the behavior you want, because you'll have cold buckets that can stay almost 200 days past the archive date, and they will be 10GB in size. As for maxWarmDbCount, according to the latest .spec documentation: maxWarmDBCount = * The maximum number of warm buckets. * Warm buckets are located in the for the index. * If set to zero, Splunk will not retain any warm buckets (will roll them to cold as soon as it can) * Highest legal value is 4294967295 * Defaults to 300. This DEFINITELY means the number of buckets, and not the number of days. In your configuration, it means you'll have at most 10 buckets in warm that are 10GB in size (or about 2,000 days in length). This means these buckets will not get rolled to cold, because for this index you have 100GB of bucket space for a 50MB / day data source. The buckets will only get removed after the frozenTimePeriodInSecs limit is reach for the MOST RECENT EVENT in that bucket. Therefore, if you don't use maxHotSpanSecs in your configuration your data retention for your index will look like this: 3 hot buckets for 90 days (default maxHotSpanSecs is 90 days, default hot buckets is 3) roll to 3 warm buckets 3 hot bucket for 90 days + 3 warm bucket for 180 days roll to 3 warm buckets 3 hot buckets for 90 days + 3 warm buckets for 180 days + 3 warm buckets for 270 days roll to 3 warm buckets 3 hot buckets for 90 days + 3 warm buckets for 180 days + 3 warm buckets for 270 days + 3 warm buckets for 360 days roll to 3 warm buckets & delete 3 warm buckets 3 hot buckets for 90 days + 3 warm buckets for 180 days + 3 warm buckets for 270 days + 3 warm buckets for 360 days This is just an estimate of what will happen, because you'll have reboots and other things that roll hot buckets before they reach the 90 day limit. Ultimately, I'm not sure that this is the behavior you want for your bucket strategy. ... View more