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

Allow easy support for different time formats #35

Open
mobileben opened this issue Nov 17, 2014 · 7 comments
Open

Allow easy support for different time formats #35

mobileben opened this issue Nov 17, 2014 · 7 comments

Comments

@mobileben
Copy link

I'd like to use epoch time in my log files since I happen to be using epoch time within the server. Is it possible to have this natively supported as opposed to having to make a specific formatter for this? It seems useful in the sense of being able to reuse the existing formatter code versus adding a new formatter to modify only one field.

@ChrisHines
Copy link
Collaborator

I think this is worth considering. I have also wanted to change the time format. In my case I want to add fractional seconds for more precision.

Also, we recognize that writing custom formatters is more burdensome that it should be and would like to improve that in the future.

@inconshreveable
Copy link
Owner

You could write a simple handler to add this for you, but it's going to be a separate key instead of 't':

func epochHandler(nextHandler log.Handler) log.Handler {
    return log.FuncHandler(func(r *log.Record) {
        r.Ctx = append(r.Ctx, "time_epoch", r.Time.Unix())
        nextHandler.Log(r)
    })
}

@mobileben
Copy link
Author

That works, but the only drawback is it is redundant data. I try and log everything, or rather as much as possible. Over time, this translates to more network as well as disk bandwidth.

@inconshreveable
Copy link
Owner

Yep, I agree. It's a temporary work around. We'd like to make formatters more flexible to tweaking, like Chris said in a future release.

@grahamking
Copy link

In my case I want to add fractional seconds for more precision.

I would like this too.

I could see a range of ways to do this:

  • I could make my own formatter, but I'd have to copy-paste formatLogfmtValue and formatShared.
  • Make these const into public variables. No-one likes public globals, but it would be simple and effective. This seems the most intuitively appealing to me.
  • Make a package level SetTimeFormat (or SetFormats(...) for all of them)
  • Refactor LogfmtFormat to take them as parameters (and keep a default so the API doesn't change).

Is there a better way? If any of the above appeal I'd be happy to submit a pull request.

@ChrisHines
Copy link
Collaborator

To date I've just modified the timeFormat constant in my internal fork of log15.

If we just want to resolve the issue of customizing the time format produced by LogfmtFormat—not worrying about the larger issue of making formatters more flexible—then I think the way forward is to add support for functional options to LogfmtFormat and provide an option to control the time format.

@grahamking I'll gladly review the code if you want to submit a pull request along those lines.

grahamking added a commit to grahamking/log15 that referenced this issue May 15, 2015
Can now configure the following in LogfmtFormat using functional options style:
 - time format
 - float format
 - float precision

Discussion in inconshreveable#35.
@jerome-laforge
Copy link

Hello,
Currently, the simple way I found for modifying the time format (for example for millisecond precision) is to change these constants, but that seems to me little weird.

Does it exist another way?
Thx in adv

ashearer added a commit to ashearer/log15 that referenced this issue Jun 4, 2016
Replace +0000 suffix for UTC timestamps in log files with .nnnZ, gaining millisecond precision. Terminal format is unaffected.

Unfortunately, changing the time format currently requires modifying the code. See inconshreveable#35 for discussion.
kormat added a commit to kormat/log15 that referenced this issue Aug 8, 2016
This is a very basic approach, but it is pretty non-invasive, doesn't
have a runtime overhead, and provides a fix until inconshreveable#35 is resolved in a
more comprehensive way.
kormat added a commit to kormat/log15 that referenced this issue Aug 8, 2016
This is a very basic approach, but it is pretty non-invasive, doesn't
have a runtime overhead, and provides a fix until inconshreveable#35 is resolved in a
more comprehensive way.
kormat added a commit to kormat/log15 that referenced this issue Aug 21, 2019
This is a very basic approach, but it is pretty non-invasive, doesn't
have a runtime overhead, and provides a fix until inconshreveable#35 is resolved in a
more comprehensive way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants