EMF as Map

[prozz]

Hey @gaeste!

I noticed you had the need to introduce EMF datastructure exposure, instead of logging.
Could you please share your requirements for it and how is it used in practice?

Regards :)

[gaeste]

Hey @prozz!
Sorry for not getting back to you.

We're having a log implementation with a fluent interface where we added a withMetrics(m emf.Metrics) kind of operation. But in order to use this library - which has most of what we need, so kudos! - we wanted to take the emf-part and build it in order to use our log implementations fluent interface.

Something in the lines of:

	metrics := emf.New().
		Namespace("MyNamespace").
		Dimension("aDimension", "dim1").
		MetricAs("counter", 1, emf.Count).
		Build()

	log.WithMetrics(metrics).With("named_key", "a_value").Info("this is my log message including emf")

It is just an enabler for us to use this library in multiple ways.
Hope it helps 👍

[jsvensson]

Hi! I work with @gaeste and just came across this. I'm working on our internal log package and I was looking at dependencies, which is how I ended up here.

Our use case is that we have, as mentioned, our own package for logging. It's due for some overhaul, and one new feature is proper JSON support, which we need for EMF. EMF in general is new to me, so I'm still getting my bearings on it.

Our log package has a .With("key", val) function to add structured data. Apart from primitives, it can take a map and marshal it to JSON and add that to the log. We have a mildly hacky .WithMetrics() that takes the EMF map, ensures that it contais the _aws key, and inserts the values. That's the main reason for needing the map directly.

(mildly edited for brevity)

func WithMetrics(emf map[string]any)Logger {
	metrics := emf["_aws"]
	if metrics == nil {
		return log.With("emf_error", "no EMF structure available")
	}

	logger := log.With("_aws", metrics)
	for k, v := range emf {
		if k != "_aws" {
			logger = logger.With(k, v)
		}
	}

	return logger
}

However, just slinging bare maps around can leave room for mistakes when you want a specific structure to it, and you need to actually check the logs for that emf_error to spot any issues. I think it would be preferrable to have the EMF package handle all of that instead, maybe with an actual EMF type.

...so that was a long-winded way of saying that we're not using the logger part of this package, but we didn't want to reinvent the wheel for the EMF format.

[prozz]

@gaeste I'd merge it, but this points to your branch, similar in the README. thanks for understanding