Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp stage add a fudged timestamp for lines missing a timestamp #1093

Closed
slim-bean opened this issue Oct 1, 2019 · 1 comment · Fixed by #1123
Closed

Timestamp stage add a fudged timestamp for lines missing a timestamp #1093

slim-bean opened this issue Oct 1, 2019 · 1 comment · Fixed by #1123
Labels
good first issue These are great first issues. If you are looking for a place to start, start here! help wanted We would love help on these issues. Please come help us! keepalive An issue or PR that will be kept alive and never marked as stale. type/enhancement Something existing could be improved

Comments

@slim-bean
Copy link
Collaborator

If using the timestamp stage and processing multi-line log lines, (or log lines that might not have a timestamp), the behavior could be a bit unpredictable.

If the timestamp stage fails to match the timestamp, the promtail system time will be used for the log line, this creates a race between the last processed log lines timestamp and the system time, potentially leading to Loki rejecting the log line which had no timestamp as being older than the previous, or possibly the next log line with a timestamp being rejected if it's timestamp is older than what the system time applied was.

I am suggesting an option be added to the timestamp stage to allow fudging a timestamp onto log lines which do not have one. The stage should keep track of the previous lines timestamp and if the next line coming in doesn't have a timestamp, increment the previous timestamp by one nanosecond and use that as the timestamp.

Fudging a timestamp is not great and could potentially lead to problems however, with nanosecond precision I would hope this to be very unlikely.

I also think the default for this behavior should be enabled, with an option to disable it

@slim-bean slim-bean added help wanted We would love help on these issues. Please come help us! good first issue These are great first issues. If you are looking for a place to start, start here! type/enhancement Something existing could be improved keepalive An issue or PR that will be kept alive and never marked as stale. hacktoberfest labels Oct 1, 2019
@pracucci
Copy link
Contributor

pracucci commented Oct 6, 2019

I'm working on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue These are great first issues. If you are looking for a place to start, start here! help wanted We would love help on these issues. Please come help us! keepalive An issue or PR that will be kept alive and never marked as stale. type/enhancement Something existing could be improved
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants