spire icon indicating copy to clipboard operation
spire copied to clipboard

Evaluate logging library, potentially abstract away logging choice

Open amoore877 opened this issue 5 years ago • 3 comments

#137 brought on https://github.com/sirupsen/logrus as core logging library. However, logrus is not very performant compared to other options.

  • http://hackemist.com/logbench/
  • https://github.com/uber-go/zap#performance

As an infrastructure-level system, SPIRE should be optimized where possible for better performance and scalability; time spent in processing overhead things like sending logs and GC is wasted.

A more performant option should be used. A good first step may be to abstract away logging choice in the source code, so that future changes to the actual core logging library do not require refactoring most files in the repo.

amoore877 avatar Aug 27 '19 21:08 amoore877

It's probably not performant enough to do this in a plugin architecture. I think the best option is make sure there's as little code as possible in the package main, and then users can pick and choose what bits they want (logrus, zerolog, or zap, for log examples) or even different cli / config parsers (yaml instead of json/hcl config)

mcpherrinm avatar Aug 27 '19 21:08 mcpherrinm

FWIW, the logrus maintainers recommend using something like zap as the logrus project is now in maintenance mode. See https://githubhelp.com/sirupsen/logrus.

zmt avatar Jan 28 '22 00:01 zmt

From Zack's logrus link:

Logrus is in maintenance-mode. We will not be introducing new features. It's simply too hard to do in a way that won't break many people's projects, which is the last thing you want from your Logging library (again...). ... I believe Logrus' biggest contribution is to have played a part in today's widespread use of structured logging in Golang. There doesn't seem to be a reason to do a major, breaking iteration into Logrus V2, since the fantastic Go community has built those independently. Many fantastic alternatives have sprung up. Logrus would look like those, had it been re-designed with what we know about structured logging in Go today. Check out, for example, Zerolog, Zap, and Apex.

Possibly this issue should be extended, or replaced with a new one, to use a logging library that is under active usage

amoore877 avatar Jan 28 '22 00:01 amoore877

This issue is stale because it has been open for 365 days with no activity.

github-actions[bot] avatar Jul 11 '23 22:07 github-actions[bot]

This issue was closed because it has been inactive for 30 days since being marked as stale.

github-actions[bot] avatar Aug 10 '23 22:08 github-actions[bot]