-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Migrate add_docker_metadata to ECS #9412
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,7 +39,7 @@ import ( | |
|
||
const ( | ||
processorName = "add_docker_metadata" | ||
dockerContainerIDKey = "docker.container.id" | ||
dockerContainerIDKey = "container.id" | ||
cgroupCacheExpiration = 5 * time.Minute | ||
) | ||
|
||
|
@@ -89,7 +89,7 @@ func buildDockerMetadataProcessor(cfg *common.Config, watcherConstructor docker. | |
"field": "source", | ||
"separator": string(os.PathSeparator), | ||
"index": config.SourceIndex, | ||
"target": "docker.container.id", | ||
"target": dockerContainerIDKey, | ||
}) | ||
sourceProcessor, err = actions.NewExtractField(procConf) | ||
if err != nil { | ||
|
@@ -168,10 +168,6 @@ func (d *addDockerMetadata) Run(event *beat.Event) (*beat.Event, error) { | |
container := d.watcher.Container(cid) | ||
if container != nil { | ||
meta := common.MapStr{} | ||
metaIface, ok := event.Fields["docker"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Remove this one as I felt it's not needed anymore when using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. while that's true, I think that will create more unneeded allocations? this is the kind of code that runs lots of times There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure I can fully follow here. You are mostly worried about the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Going to merge for now. @exekias Let's revisit this next year to make sure we have the correct optimisations in place. |
||
if ok { | ||
meta = metaIface.(common.MapStr) | ||
} | ||
|
||
if len(container.Labels) > 0 { | ||
labels := common.MapStr{} | ||
|
@@ -187,9 +183,9 @@ func (d *addDockerMetadata) Run(event *beat.Event) (*beat.Event, error) { | |
} | ||
|
||
meta.Put("container.id", container.ID) | ||
meta.Put("container.image", container.Image) | ||
meta.Put("container.image.name", container.Image) | ||
meta.Put("container.name", container.Name) | ||
event.Fields["docker"] = meta.Clone() | ||
event.Fields.DeepUpdate(meta.Clone()) | ||
} else { | ||
d.log.Debugf("Container not found: cid=%s", cid) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graphaelli Have you found a good way to migrate such fields?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can. I'm assuming this is user-populated, including key names? If that's the case, then the list of fields to migrate is unknowable.
Perhaps if some fields are often present by default, we can create aliases for those, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not found a good way. Can the migration assistant create those aliases dynamically? That is, iterate over the source labels and create aliases on the old indices for each one? Another option is to inform users to include both fields with an or clause in searches and aggregations.
APM has the same issue where
context.tags
are moving tolabels
. It may be possible there to introduce an APM UI-only concept of"tags""labels" and make thecontext.tags.$key=$value or labels.$key=value
query on behalf of the user - we have not discussed this possibility but I'd be curious what you think.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graphaelli Indeed that is something that the migration assistant could potentially do. I think in this case it's more important for apm-server as you probably need it for the 6.x compatiblity layer and in our case it's nice to have as we can also break it in 7 and inform the user about this one. If we can use then the same feature to, that is great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think the migration assistant will be our best bet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graphaelli Can you take this up with the Kibana team working on the migration assistant to see what they think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They've added it to their use cases for the migration assistant, there will be hooks for us to handle it there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great news. Thanks for following up.