You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add the ability to recognize events where the timestamp field is using the time the message was received by Graylog and does not reflect the time the event described in the message occurred. Additionally:
it would be helpful to have an indication in the message view, and log view if possible, that provides a visual cue to customers indicating the timestamp value does not reflect the event time. This could be a distinct icon next to the timestamp, a color-coded highlight, or other visual indication.
it may be helpful to have a dashboard that shows the status of the timestamp operation, by source.
Why?
This feature can reduce confusion during incident response and post-mortem analysis, helping teams trust their log data more fully.
When conducting an investigation it is often important to build a timeline of events, sometimes across multiple sources/log types.
The standard behavior in Graylog is that the timestamp value reflects the time the event occurs but that cannot be the case in all events. In some cases the receipt time is used, such as when the syslog input may not be able to parse the header or there is no timestamp in the header, or when it is just not practical to attempt an extraction with inputs such as the raw HTTP input.
This solution should be adjustable in processing time, allowing the indication to be removed for cases where messages can be parsed by pipeline rules, and the event time can be extracted and applied to the timestamp field.
Your Environment
Graylog Version:
OpenSearch Version:
MongoDB Version:
Operating System:
Browser version:
The text was updated successfully, but these errors were encountered:
tellistone
changed the title
Recognize and Indicate Messages Where timestamp Reflects Receipt Time (Not Actual Event Time)
Add a dashboard that tracks timestamp issues
Feb 3, 2025
What?
Add the ability to recognize events where the
timestamp
field is using the time the message was received by Graylog and does not reflect the time the event described in the message occurred. Additionally:timestamp
value does not reflect the event time. This could be a distinct icon next to the timestamp, a color-coded highlight, or other visual indication.Why?
This feature can reduce confusion during incident response and post-mortem analysis, helping teams trust their log data more fully.
When conducting an investigation it is often important to build a timeline of events, sometimes across multiple sources/log types.
The standard behavior in Graylog is that the
timestamp
value reflects the time the event occurs but that cannot be the case in all events. In some cases the receipt time is used, such as when the syslog input may not be able to parse the header or there is no timestamp in the header, or when it is just not practical to attempt an extraction with inputs such as the raw HTTP input.This solution should be adjustable in processing time, allowing the indication to be removed for cases where messages can be parsed by pipeline rules, and the event time can be extracted and applied to the
timestamp
field.Your Environment
The text was updated successfully, but these errors were encountered: