-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Glog file separation by year #516
Comments
This PR fixes issue google#516 by prepending the year to each glog line. Previous format of each line in a log file: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg New format: [IWEF]yyyymmdd hh:mm:ss.uuuuuu threadid file:line] msg
* Prepend the year to each glog line (#516) This PR fixes issue #516 by prepending the year to each glog line. Previous format of each line in a log file: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg New format: [IWEF]yyyymmdd hh:mm:ss.uuuuuu threadid file:line] msg * Fix logging_unittest for PR #530 Since the format of each glog line has been changed, the logging_unittest must also be updated.
Fixed in #530. |
FWIW I think doing this was a mistake. It changes the log line format and is no longer compatible with Google's internal log line format. Processes are never intended to be running for more than a year anywhere (regular software and infrastructure updates being a thing). Anything parsing log lines should not blindly assume "current year" when parsing a line. |
Include a : separator in the time, and include the year to match a recent glog change: google/glog#516
Agree with @gpshead . Adding year seems to have broken GKE's built-in regex-based parsing for glogs. |
@cnsgsz Could you please create a new issue? The year prefix could be made optional. |
Hello! There seems to be an edge case that occurs when the year switches while we are in the midst of writing glogs.
For instance, if we are writing glogs at 11:59 pm on 12/31/2019, and the year switches to 2020, the mmdd timestamp written on each line of the glog will not capture this year difference. Therefore, it looks like the glogs jump from 12/31/2019 to 01/01/2019 if we are only extrapolating the year from the file name, or the file creation date written at the top of each glog file.
I think some possible solutions include:
Was there a reason for not including the year in the line-by-line output format?
The text was updated successfully, but these errors were encountered: