Sumo Logic supports several options for timestamps, time zones, time ranges, and dates.
The timestamp is the part of a log message that marks the time that an event occurred. During ingestion, Sumo Logic detects the message timestamp, converts it to Unix epoch time (the number of milliseconds since midnight, January 1, 1970 UTC), and indexes it. The timestamp is parsed either using the default timestamp parsing settings, or a custom format that you specify, including the time zone.
When configuring a Source you can choose to use the Sumo Logic default timestamp parsing settings, or you can specify a custom format for Sumo Logic to parse timestamps in your log messages. The Enable Timestamp Parsing option is selected by default. If it's deselected, no timestamp information is parsed at all. Instead, Sumo Logic stamps logs with the time at which the messages are processed.
The following considerations apply to timestamps:
- It’s expected that all timestamps in logs sent to Sumo Logic from a single Source will follow the same format. If they do not, the timestamps could be incorrect.
- It’s expected that individual log messages will contain only one timestamp. If multiple timestamps are detected within a single message, only the timestamp that appears earliest in the message will be considered.
By default, Sumo Logic will automatically detect the timestamp format of your logs. However, in cases where timestamps are not detected correctly, you can manually specify a timestamp format for a Source.
Specifying a timestamp format
In the majority of cases Sumo Logic automatically parses timestamps without any issues, but if you're seeing timestamp parsing issues you can manually specify the parse format. The steps are the same if you're configuring a new Source or if you're editing the timestamp information for an existing Source.
To manually specify a timestamp format for a Source:
- Do one of the following:
- If you're configuring a new Source, continue to step 2.
- To edit the timestamp settings for an existing Source, click Manage> Collection. Then click Edit to the right of the Source name.
- Click Advanced.
- For Timestamp Format, select Specify a format.
- In the Format text box, type the timestamp format that Sumo Logic should use to parse timestamps in your logs.
- To verify that the format is supported, and that it can be properly parsed, copy and paste a timestamp string from your log file in the Log Sample text box. Then click Test.
Sumo Logic looks at the format to make sure it's supported, then tests the sample timestamp against the format to make sure it's valid, and that it can be parsed. You'll be notified if the test is successful or if there are any issues that need to be addressed before continuing.
- Click Save.
If the following conventions are followed, Sumo Logic can parse timestamps from log messages:
|Token||Date or Time Component||Example|
|yyyy||4-digit year||2012; 2016|
|yy||2-digit year||12; 16|
|MMM||3-character month||Jan; Mar; Dec|
|MM||1- or 2-digit month (in a year)||1; 01; 9; 09; 12|
|dd||1- or 2-digit day (in a month)||1; 01; 16; 30|
|a||AM/PM (case insensitive)||AM; PM; am; pm|
|HH||1- or 2-digit hour (in a day, 0-23)||2; 02; 14; 23|
|hh||1- or 2-digit hour (in a day, 1-12 with AM/PM)||2; 02; 11; 12|
|mm||1- or 2-digit minute (in an hour)||8; 08; 55|
|ss||1- or 2-digit second (in a minute)||5; 05; 35|
|SSS||1-3 digit subsecond or millisecond (in decimal)||4; 58; 944|
|zzz||3- letter time zone||UTC; PST; EDT|
|ZZZZ||RFC 822 time zone||-0900; +0500|
|'Z'||Literal Z character||Z|
|'T'||Literal T character||T|
In addition to custom formats using the components listed above, any of the following timestamp formats can be parsed by Sumo Logic:
|dd/MMM/yyyy:HH:mm:ss ZZZZ||19/Apr/2010:06:36:15 -0700|
|dd/MMM/yyyy HH:mm:ss||09/Mar/2004 22:02:40 08691|
|MMM dd, yyyy hh:mm:ss a||Dec 2, 2010 2:39:58 AM|
|MMM dd yyyy HH:mm:ss||Jun 09 2011 15:28:14|
|MMM dd HH:mm:ss yyyy||Apr 20 00:00:35 2010|
|MMM dd HH:mm:ss ZZZZ||Sep 28 19:00:00 +0000|
|MMM dd HH:mm:ss||Mar 16 08:12:04|
|yyyy-MM-dd HH:mm:ss,SSS ZZZZ||2011-02-11 16:47:35,985 +0000|
|yyyy-MM-dd HH:mm:ss ZZZZ||2011-08-19 12:17:55 -0400|
|yyyy-MM-dd HH:mm:ssZZZZ||2011-08-19 12:17:55-0400|
|yyyy-MM-dd HH:mm:ss zzz||2016-09-06 10:51:18 PDT|
|yyyy-MM-dd HH:mm:ss,SSS||2010-06-26 02:31:29,573|
|yyyy-MM-dd HH:mm:ss||2010-04-19 12:00:17|
|yyyy/MM/dd HH:mm:ss||2006/01/22 04:11:05|
|yy-MM-dd HH:mm:ss,SSS ZZZZ||11-02-11 16:47:35,985 +0000|
|yy-MM-dd HH:mm:ss,SSS||10-06-26 02:31:29,573|
|yy-MM-dd HH:mm:ss||10-04-19 12:00:17|
|yy/MM/dd HH:mm:ss||06/01/22 04:11:05|
|MM/dd/yyyy hh:mm:ss a:SSS||8/5/2011 3:31:18 AM:234|
|MM/dd/yyyy hh:mm:ss a||9/28/2011 2:23:15 PM|
Unix epoch timestamps
Unix epoch timestamps are supported in the following formats:
- 10 digit epoch time format surrounded by brackets (or followed by a comma). The digits must be at the very start of the message. For example,  or [1234567890, other] followed by the rest of the message.
- 13 digit epoch time. The 13 digits must be at the very start of the message. For example, 1234567890123... followed by the rest of the message.
Sumo also recognizes the time format for the Akamai log delivery service. The format is 13 digits with a period before the last three (ms) digits: 1234567890.123
- Comma separated values where the 5th value from the start of the message is a 10 digit epoch time. For example, field1, field2, field3, field4, 1234567890
- JSON formatted property called "timestamp" followed by a 13 digit epoch time. For example, "timestamp":"123456789013".
- Format of Cisco Fortigate/Meraki log message:
<134>1 1439277406.903768018 Store_020026 flows src=<redact> dst=126.96.36.199 protocol=udp sport=62118 dport=53 pattern: 1 all
- Format of Linux audit message:
type=PATH msg=audit(1439992022.365:83931889): item=0 name="/usr/sbin/ss" inode=91193416 dev=08:02 mode=0100755 ouid=0 ogid=0 rdev=00:00
When configuring a Source, you can choose either of the following options:
- Use the time zone present in your log files, and then choose an option in case time zone information is missing from a log message.
- Have Sumo Logic completely disregard any time zone information present in logs by forcing a time zone.
It's important to have the proper time zone set, no matter which option you choose. If the time zone of logs can't be determined, Sumo Logic stamps them with UTC.
Time zone considerations
The following considerations apply to time zones:
- We highly recommend that the time zone be set explicitly on all Sources. Sumo Logic always attempts to determine the time zone for the Source. However, if that isn’t possible, the time zone will revert to UTC. In these cases, the time zone will be incorrect, and that could significantly affect forensic analysis and reporting.
- Sumo Logic does not support all available ISO8601 time zones. For example -00:00 and -00 are not supported. So any timezones written in this format are undetectable by the system. For cases of these formats you will need to supply the proper default timezone to use when one is not detected by the service.
Default time zone
By default, Sumo Logic uses the time zone from your web browser set by the operating system to display hours and minutes everywhere in the Sumo Logic user interface. You can change the default time zone that the user interface displays by adjusting the Default Timezone setting on the Preferences page. This option overrides the time zone from your web browser, and changes how hours and minutes are displayed in the UI. But this is a personal setting, and does not change the time zone for anyone else in your organization.
UI elements that are affected by this setting include the Search page Time Range field, the Time column of the Messages pane, Dashboards, and Anomaly Detection.
Changing the Default Timezone setting affects how the UI displays messages, but not the actual timestamp in the log message.
For example, the following screenshot shows the time zone set to PST in the UI, in the Time column. The logs were collected from a system that was also configured to use the PST time zone, which is displayed in the timestamp of the Message column. The timestamps in both columns match as they are set to the same time zone.
The next screenshot shows the same search result after changing the Default Timezone setting to UTC. Now the Time column is displayed in UTC, while the Message column retains the original timestamp, in PST.
In another example, if your time zone is set to UTC, and you share a Dashboard with another user who has their time zone set to PST, what will they see?
They will see the same data, just displayed using their custom set time zone. For example, if you have a Panel that uses a time series, the timeline on the X axis of your chart is displayed in your time zone, UTC. The other user will see the timeline on the X axis displayed in their time zone, PST. But the data displayed in the chart is exactly the same.
The Time Range field on the Search page uses the time zone that is set for the Sumo Logic user interface. This is either the default time zone used in the web browser and set by the operating system, or the Default Timezone setting on the Preferences page, if you have set this option.
When you create a Scheduled Search or a Real Time Alert, the time range of the search that you save uses the time zone that is set for the Sumo Logic user interface. If you have changed the time zone using the Default Timezone setting, this time zone will be used for your Scheduled Searches and Real Time Alerts.
The Default Timezone setting does not automatically update the configurations of existing Scheduled Searches or Real Time Alerts. So it is important to note that if you would like your Scheduled Searches and Real Time Alerts to use the same time zone as your user interface, you will need to edit them to do so, and save them.
For more information on time ranges, see Set the Time Range of a Search.
Search Time Ranges can also search all data with any and all timestamps. For details, see Use Receipt Time.
If the browser used to access Sumo Logic is in a location that uses the day/month/year format instead of month/day/year, dates are presented in that format.