You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kubernetes Provider (and add_kubernetes_metadata processor) if configured with the following block:
add_resource_metadata:
cronjob: true
add the kubernetes.cronjob.name metadata field to a log event of a pod that is handled by a job, which is handled by a cronJob.
This behaviour was by default disabled after a certain stack version because it can lead to increase in elastic-agent's memory consumption.
This happens in environments with many cronJobs that generated a lot of ephemeral pods. The API requests are increased but also the data stored in memory are increased as well.
The addition of the cronJob name is achieved by creating a new watcher-informer mechanism for Jobs. Then the cronJob name is extracted by the Job object and added in pod log event.
The code as it is right now, stores the whole Job object in memory although we just need its name and the cronJob name that created it, if it exists.
As a follow up of the work done for replicaSets we can use the same mechanism of only keeping the necessary data for the Job resource.
This issue is a continuation of #5623.
Kubernetes Provider (and add_kubernetes_metadata processor) if configured with the following block:
add the
kubernetes.cronjob.name
metadata field to a log event of a pod that is handled by a job, which is handled by a cronJob.This behaviour was by default disabled after a certain stack version because it can lead to increase in elastic-agent's memory consumption.
This happens in environments with many cronJobs that generated a lot of ephemeral pods. The API requests are increased but also the data stored in memory are increased as well.
The addition of the cronJob name is achieved by creating a new watcher-informer mechanism for Jobs. Then the cronJob name is extracted by the Job object and added in pod log event.
The code as it is right now, stores the whole Job object in memory although we just need its name and the cronJob name that created it, if it exists.
As a follow up of the work done for replicaSets we can use the same mechanism of only keeping the necessary data for the Job resource.
Related Issues:
The text was updated successfully, but these errors were encountered: