If there is a log like below that have time zone "+00:00", how can I set different time zone?
2018/5/9 3:00:00+00:00 this is test
If I input this log, system time zone of my splunk server is
JST and difference of UTC and JST is +9 hours, so normally
_time will be
But I want
splunk to recognize this log's time zone is JST, so I configured
TZ = Asia/Tokyo in props.conf of
*In my environment there are
Then I was thinking that
_time would be
2018/5/9 3:00:00, but
_time wasn't changed.
Did I set
TZ in wrong place?
Or if the time zone is described in the log, does it override the
TZ setting and there is no way to avoid it?
Please someone tell me about it.
If the log says it is in 00:00 TZ, why would you want to tell Splunk the log is in another timezone? Sounds like that would mess up the timestamping.
Thank you for answer.
Yeah normally I don't have to do such a thing.
But there is logs have wrong timezone info, so I should have to do first aid until data source will be corrected.
Ah, ok, if the +00:00 in the log is really incorrect, then indeed try what xpac suggested.
If there's a timezone in the timestamp, it will override whatever is being set in TZ.
Therefore, you have two options:
- Manually configure the timestamp recognition, and do NOT include the timezone part in the TIME_FORMAT setting, so it should work with your example and
- If this is syslog, you can have that log timestamp just being rewritten with a proper timestamp, and let Splunk just do it's thing. I've done it with syslog-ng before, you can read about it here: https://spice.areafunky.net/2017/07/08/bye-rsyslogd-here-comes-syslog-ng-fixing-timestamps-without-t...
Hope that helps - if it does I'd be happy if you would upvote/accept this answer, so others could profit from it. 🙂
Thank you for answer.
It is very helpful.
I will try TIME_FORMAT settings excluding time zone info until syslog settings will be corrected.
I know that this question already has an accepted answer but @yutaka1005, there is another nice option.
You can use the
TZ_ALIAS to tell the Indexers that when it sees TZ =
foo, to swap that out for TZ =
bar. In your case
JST, probably in a
host-based stanza header.
My answer is better because it is fully future/fix-proof. When the TZ is fixed to anything other than
TZ_ALIAS will stop functioning and the normal interpretation will work. If you remove the TZ from the
TIME_FORMAT, then you will have to remember to come around and put it back after the real fix is in place. That is why this answer is a MUCH better option.
Thank you for answer!
I tried to use
TZ_ALIAS option, but I couldn't change timestamps...
2018/5/11 03:00:00+00:00 this is test for TZ_ALIAS
[test_for_tz] DATETIME_CONFIG = NO_BINARY_CHECK = true SHOULD_LINEMERGE = true category = Custom pulldown_type = true TZ_ALIAS = UTC=JST disabled = false
Eventually, the time-stamp was 9 hours plus the time on log.
Am I something wrong about that option?