Depending on the time range of a Dashboard Data Panel, it can take time for a Panel to display the complete results. Panels are built as data is ingested. So if you create a one-hour Panel, it will take one hour to see the full results; for a 30-day Panel, it will take 30 days.
If you see the Dashboard error "No Data to Display," this issue is usually due to a time zone misconfiguration within your Source configuration(s) or a timestamp problem in your logs.
Sumo Logic applies UTC as the time zone if the time zones in your messages if:
- Time zones are not parsed automatically.
- A time zone is missing in your messages.
- A time zone value is missing.
- The Source is not configured with a default time zone.
This results in the "parsed time" showing as either hours in the future or hours behind the actual message time in the logs. This affects how Panels interpret these messages. (Find more information on common time parsing problems see Timestamps, Time Zones, Time Ranges, and Date Formats.)
Panels are active queries that only query data as it is being received into the system prior to messages being indexed, and they only look for messages with a parsed timestamp 10 minutes forward in time or within the window of the current Panel time. Basically, as messages are received, the Panel asks, "Are these messages between X hours/minutes ago to 10 minutes from now?" If they are, then the message gets added to the Panel. If the message parsed time does not fall within the current Panel range, they are excluded.
So if your message times are in PST, but Sumo Logic thinks they are UTC, then the Panels will skip the messages as not being current. For example, if the current time is 17:00 UTC, and the log messages coming in have a timestamp of 10:00 (PT), and the service parsed them as 10:00 (UTC) due to a time zone misconfiguration, then the Panel will not show these messages, as the parsed time is 7 hours behind the current time and may be outside the current Panel window.
Interactive mode is different. Interactive searches query the log messages after processing and indexing, and will find messages that have a parsed timestamp that falls within the selected time range, regardless of when they were received by the service. With an interactive search, a message that was received 7 hours prior to the parsed message time, which now falls within the query time range, will still be found by the current query.
The easiest way to check if a timestamp parsing problem or delayed ingest could be causing this problem is to compare the parsed time "Time" field to the time the service received the message. On the Panel showing no data, click the Panel or click the Show in Search button to open the query in the Search tab. (Make sure that the Dashboard is not in Edit mode. If it is, the Show in Search button will not work.)
Once the query is opened on the Search page, Sumo Logic provides an option just under the time range selector called Use Receipt Time. Run the query with this option checked. With this option, you can search by the time Sumo Logic received the messages (or the receipt time in Sumo Logic) instead of the time parsed from the logs. This option displays both the parsed time as well as the receipt time, so you can compare the values. If you see hours of difference between these values, then you most likely have a time parsing problem and may need to update your Source configurations, especially the Source or Collector level setting for Use time zone from log file. If none is present use:. The most common issue is that this setting defaults to UTC, when your Source log messages may be generated in a different timezone.
Query to Check Offset of Receipt Time and Message Time
The following query can be run within your account and will display a count of Collectors, Sources, and sourceNames that have a receipt time and parsed message time which are greater than 1 hour. This query should be run over a very small time range with the Use Receipt Time option for the query selected. This query can identify the Sources and sourceNames that could be susceptible to the "No data to display" error in a Dashboard Panel.
* | _receipttime - _messagetime as difference
| difference/1000/60 as diff_minutes
| where diff_minutes < -60 or diff_minutes > 60
| count by _collector, _source, _sourceName