-
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
Metricbeat: store only top N processes by CPU/memory #4127
Conversation
CmdLine string `json:"cmdline"` | ||
Cwd string `json:"cwd"` | ||
Mem sigar.ProcMem | ||
Cpu sigar.ProcTime |
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.
[golint] reported by reviewdog 🐶
struct field Cpu should be CPU
@@ -216,7 +221,7 @@ func getProcState(b byte) string { | |||
return "unknown" | |||
} | |||
|
|||
func (procStats *ProcStats) GetProcessEvent(process *Process, last *Process) common.MapStr { | |||
func (procStats *ProcStats) GetProcessEvent(process *Process) common.MapStr { |
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.
[golint] reported by reviewdog 🐶
exported method ProcStats.GetProcessEvent should have comment or be unexported
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 unexported this one, i don't think it needs to be exported.
return procs, nil | ||
} | ||
|
||
func (p *ProcStats) includeTopProcesses(processes []Process) []Process { |
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.
[golint] reported by reviewdog 🐶
receiver name p should be consistent with previous receiver name procStats for ProcStats
As a follow up, I added in #4112 a point to add new metrics for the "total number of processes" and similar, and update the dashboards to use these metrics instead of aggregating them based on the row process values. |
@@ -36,6 +36,21 @@ | |||
# if true, exports the CPU usage in ticks, together with the percentage values | |||
#cpu_ticks: false | |||
|
|||
# These options allow you to filter out all processes that are not |
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.
Perhaps add a note that it is a union?
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 added a note at the section start.
6b72ad0
to
1eb3167
Compare
Added CHANGELOG entry, cleaned up and rebased to master. |
"testing" | ||
"time" | ||
|
||
"github.com/elastic/beats/libbeat/common" | ||
"github.com/elastic/gosigar" | ||
sigar "github.com/elastic/gosigar" |
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.
it's tests but it seems like gosigar is imported twicw?
This adds the option to only report on the top N processes by CPU and/or memory. It is useful because storing metrics about each and every process from every host can be fairly expensive from the storage point of view. Previously it was possible to filter processes by name, which was useful if one knew in advance which are the most interesting processes. This adds a new option which should be quite convenient in practice, because the number of per-process documents gets limited while still allowing to display the top processes. Closes elastic#4126.
*`process.include_top_n`*:: These options allow you to filter out all processes | ||
that are not in the top N by CPU or memory, in order to reduce the number of | ||
documents created. If both the `by_cpu` and `by_memory` options are used, the | ||
reunion of the two tops is included. |
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.
s/reunion of the two tops/union of the two sets/
?
@@ -32,17 +32,31 @@ type MetricSet struct { | |||
cacheCmdLine bool | |||
} | |||
|
|||
// includeTopConfig is the configuration for the "top N processes | |||
// filtering" feature | |||
type includeTopConfig struct { |
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.
For some reason I thought the struct needed to be exported in order for go-ucfg to work on it via reflection. Researching further, I guess since Go 1.6 this isn't necessary.
@@ -336,7 +339,7 @@ func (procStats *ProcStats) GetProcStats() ([]common.MapStr, error) { | |||
return nil, err | |||
} | |||
|
|||
processes := []common.MapStr{} | |||
processes := []Process{} |
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.
It's best to declare the empty slice as var processes []Process
because it avoids the allocation if the slice goes unused. https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices
processes = procStats.includeTopProcesses(processes) | ||
logp.Debug("processes", "Filtered top processes down to %d processes", len(processes)) | ||
|
||
procs := []common.MapStr{} |
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.
We know the size a priori, so this could do the full allocation at once with procs := make([]common.MapStr, 0, len(processes))
.
return processes | ||
} | ||
|
||
result := []Process{} |
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.
Same issue with the empty slice declaration.
Follow up for elastic#4127 to address comments.
@andrewkroh thanks, I addressed your comments in #4173 |
This adds the option to only report on the top N processes by CPU and/or memory. It is useful because storing metrics about each and every process from every host can be fairly expensive from the storage point of view. Previously it was possible to filter processes by name, which was useful if one knew in advance which are the most interesting processes. This adds a new option which should be quite convenient in practice, because the number of per-process documents gets limited while still allowing to display the top processes.
Closes #4126.
Configuration wise it looks like this:
Remaining TODOs: