Settable global logger

[uablrek]

Description

It should be possible to set an own customizwd Logger to be used by NSM. Now the logger is hard-coded in some places, most notable the logruslogger.FromSpan() used for trace logging. The intention for this PR is to fix the most urgent needs in a backward compatible way with as little changes as possible.

This PR adds a global logger reachable with log.L() (same as zap) and settable with log.SetGlobalLogger(l Logger).

logruslogger.FromSpan() has been altered to become generic by using the log.Logger interface rather than a variation of logruslogger. It uses the global logger as base (calls log.L()) and thus allows users to specify the logger used for trace. For backward compatibility the global Logger is set to a logruslogger on init. If no logger is specified (logger is log.Default()) a backward compatible logger (logrus) is used.

The global logger should be set early in main(). Example;

	if config.LogLevel == "TRACE" {
		nsmlog.EnableTracing(true)
		// Work-around for hard-coded logrus dependency in NSM
		logrus.SetLevel(logrus.TraceLevel)
	}
	logger.Info("NSM trace", "enabled", nsmlog.IsTracingEnabled())
	nsmlogger := log.NSMLogger(logger)
	nsmlog.SetGlobalLogger(nsmlogger)
	ctx = nsmlog.WithLog(ctx, nsmlogger)

Tasks that should be done but are not backward compatible

• Move FromSpan() from package logruslogger to log (since it's not logrus specific any more)
• Rename FromSpan() -> NewTraceLogger()

I will not add these things since it affects code all over the place I guess. Also FromSpan() is a horrible hack IMHO and should be re-written.

Issue link

#1272

How Has This Been Tested?

• Added unit testing to cover
• Tested manually
• Tested by integration testing
• Have not tested

I have used this PR in our NSM application with trace and it works fine. The example above is from real code. I have also used a logruslogger/logruslogger_test.go unit test to exercise the code in a convenient way. I have not included it since it doesn't really make any automatic tests, it just emits logs in various ways to be eyeballed by the developer.

Types of changes

• Bug fix
• New functionallity
• Documentation
• Refactoring
• CI

[uablrek]

Example with a custom logger;

{
  "severity": "debug",
  "timestamp": "2022-09-08T18:13:49.429+00:00",
  "service_id": "Meridio-LB",
  "message": "(7)       ⎆ sdk/pkg/registry/core/trace/traceNetworkServiceEndpointRegistryFindClient.Recv()",
  "version": "1.0.0",
  "extra_data": {
    "subsystem": "NSM",
    "type": "registry"
  }
}

[uablrek]

About failed CI;

• I can't remove the init() function without breaking backward compatibility
• The FromContext() now returns log.L() if there is no log in the contexts. IMHO this is the right way, but apparetly it breaks CI. I can change it back

The others seem to be minor updates. I can fix those.

[edwarnicke]

@denis-tingaikin @edwarnicke

[denis-tingaikin]

@uablrek There is also failed build/tests. Could you have a look?

[denis-tingaikin]

I'm just interested in why we can't just declare a global context and put there a logger.

@uablrek Could you remind me why we can't use a global context?

[uablrek]

Could you remind me why we can't use a global context?

Not sure, but nobody else does that AFAIK so I suppose there are reasons. It is recommended to pass context as the first parameter (not using a global context) and context's are more often derived than a logger.