Describe the enhancement:
Currently Beats are adding metadata about the kubernetes resource controlling the monitored resource. In the case of pods created by deployments, the resource controlling the pod is actually a replica set, that is controlled by the deployment. Beats add the metadata about the replica set (e.g. the kubernetes.replicaset.name field), but not about the deployment.
Users are usually more interested in the deployment, than in the intermediary replica set, add this information to the added metadata.
I think this metadata is being added from here:
|
// Add controller metadata if present |
Not sure if there are other cases with intermediary objects like the case of deployments and replicasets, maybe a general option is to recursively get all owners.
Describe a specific use case for the enhancement or feature:
As a user I may want to be able to monitor pods per deployment creating them.
Describe the enhancement:
Currently Beats are adding metadata about the kubernetes resource controlling the monitored resource. In the case of pods created by deployments, the resource controlling the pod is actually a replica set, that is controlled by the deployment. Beats add the metadata about the replica set (e.g. the
kubernetes.replicaset.namefield), but not about the deployment.Users are usually more interested in the deployment, than in the intermediary replica set, add this information to the added metadata.
I think this metadata is being added from here:
beats/libbeat/common/kubernetes/metadata/resource.go
Line 85 in 44e281f
Not sure if there are other cases with intermediary objects like the case of deployments and replicasets, maybe a general option is to recursively get all owners.
Describe a specific use case for the enhancement or feature:
As a user I may want to be able to monitor pods per deployment creating them.