[Chore] Add functions required for single logger instance

[khushijain21]

What does this PR do?

Required for https://github.com/elastic/ingest-dev/issues/5251

This PR adds some existing methods (on logp package) but with Local appended to the method name. These are required by libbeat to use single logger instance. It does not remove any existing methods not to break any code dependent on the logp library

Why is it important?

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works

Related issues

• Part of https://github.com/elastic/ingest-dev/issues/5251

[AndersonQ]

@khushijain21 for the function which need docs, if the doc would be the same as for the non-local version you can refer to the non-local and point out the difference. Like that:

// SomeFunction performs a specific operation and logs relevant information using the global logger.
//
// It takes an input string and processes it, logging the input and the result of the processing.
func SomeFunction(input string) string {


// SomeFunctionLocal is the same as SomeFunction but returns a logger instance instead.
func SomeFunctionLocal(input string, logger *log.Logger) (string, *log.Logger) {

[khushijain21]

With new local methods, we will lose the observerLogs parameter available on global config.

Unless we change Logger struct to include

type Logger struct {
	logger       *zap.Logger
	sugar        *zap.SugaredLogger
	observerLogs *observer.ObservedLogs. // additional
}

This would change many API's that depend on Logger.

Instead, users can get similar functionality with this

	observed, zapLogs := observer.New(zapcore.DebugLevel)
	observer, err := logp.ConfigureWithCoreLocal(defaultConfig, observed)

Any thoughts? I prefer going with the second option.

[mauri870]

Any thoughts? I prefer going with the second option.

I like the second option too. First option would require a testing-only struct field wich does not make much sense for production code. Second option is more pluggable as well.

[rdner]

@khushijain21 I thought [observerLogs](https://github.com/elastic/elastic-agent-libs/blob/main/logp/core.go#L63) was just for testing purposes and validating logs after a test? Is it used elsewhere?

If we change all our interfaces to accept a local logger, testing should also do so and everything should be recorded in the local logger instead.

[khushijain21]

observerLogs was just for testing purposes and validating logs after a test? Is it used elsewhere?

Yes it is used only for testing. It is used in 9 files in beats https://github.com/search?q=repo%3Aelastic%2Fbeats%20ObserverLogs&type=code

If we change all our interfaces to accept a local logger, testing should also do so and everything should be recorded in the local logger instead.

Yes, so users can create an observer core and access "testing logs" on the local logger. As described on the second part here #297 (comment)

[leehinman]

I'd really like @belimawr to take a look before we merge. I think it is safe since we are only adding functions, but logp has a history of unexpected behavior.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 4aa9df0

History

• 💚 Build #662 succeeded 2758278
• 💚 Build #661 succeeded 7c13c93
• 💚 Build #659 succeeded 33c681b
• 💚 Build #658 succeeded 7fffe75
• 💚 Build #657 succeeded 27c3ee4
• 💚 Build #655 succeeded 3811fd7