Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

k8sprocessor: add host.name and container.name fields #188

Conversation

pmalek-sumo
Copy link

Description:

This PR adds option to tag data with host.name and container.name fields.

@pmalek-sumo pmalek-sumo self-assigned this Sep 30, 2020
}

sort.Strings(names)
tags[conventions.AttributeContainerName] = strings.Join(names, ",")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've been using ", " (with space) previously. But! Perhaps a better option would be to use native array structure for this if several values are present. OTLP model supports it

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How exactly would you like to serialize it? tags is a map[string]string. Something like fmt.Sprintf(names)?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intermediate layer (tags) might need some rethinking but eventually it might be stored as this: https://github.com/open-telemetry/opentelemetry-proto/blob/master/opentelemetry/proto/common/v1/common.proto#L36

Copy link

@pmm-sumo pmm-sumo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall. Take a look at some nits I observed

@pmalek-sumo pmalek-sumo merged commit 9fc15db into k8s-processor-hostname-and-containername-tags-pr Oct 1, 2020
@pmalek-sumo pmalek-sumo deleted the k8s-processor-hostname-and-containername-tags branch October 1, 2020 09:50
sumo-drosiek pushed a commit that referenced this pull request Jun 1, 2022
In some circumstances, a log entry could be unsuccessfully parsed.
It is intended that a failure can result in an entry being "sent"
to the next operator, but when this happens, the parser should
cease execution immediately. Prior to this change, this was not
always the case, as some parsers would continue on and "send" the
entry again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants