New Relic 'logtype' attribute is not set correctly in batches that have a mix of container logs and syslogs

[steventine]

I very much appreciate the great work that was done in a2f9eb8 per #209 to decorate the container logs from ktranslate with the logtype of ktranslate-health however I was seeing situations where sometimes the logs were decorated (and hence nicely parsed) while other times they weren't.

For example, in New Relic:
SELECT `container_service`,`plugin.type`,`severity`,`message` FROM Log WHERE `collector.name` = 'ktranslate' AND `device_name` IS NULL

(notice the first two are decorated, while the last two aren't)

After lots of searching through code and debugging, I think the problem is that the logtype attribute is set as a Common.Attribute (applying to the entire batch) and it's only set if NONE of the logs in the batch being sent are a syslog. However, in the situation where at least one log in the batch IS a syslog, the container logs aren't properly decorated and hence aren't parsed :-(

ktranslate/pkg/sinks/nr/nr.go

Lines 400 to 403 in f18e227

	if !hasSyslog {
	ls.Common.Attributes["plugin.type"] = kt.PluginHealth
	ls.Common.Attributes["logtype"] = "ktranslate-health"
	}

Would it make sense to never mix syslogs and non-syslogs in the same batch since they have to share the Common.Attribute?

Maybe in the code below (which is already copying each log to a new logset) create a syslog_logset and a non_syslog_logset...then send them independently, with the latter getting the logtype of ktranslate-health?

ktranslate/pkg/sinks/nr/nr.go

Lines 391 to 396 in f18e227

	for i, l := range logs {
	ls.Logs[i] = log{
	Timestamp: ts,
	Message: l,
	}
	if !hasSyslog && strings.Contains(l, kt.PluginSyslog) {

[steventine]

Maybe something like steventine@089887e ?

(my apologies as I've never written any go code before so this might be totally wrong, but hopefully it's a conceptual example of the idea I was proposing)

[steventine]

Or is there an easy way to apply the plugin.type and logtype at the individual log level (instead of inside the Common.Attributes that applies to all logs in the batch)?

[steventine]

Here is a draft PR for discussion. It seems to be working well in my system - #844

[i3149]

Closed with #845