Windows services metric add this process id

[pytimer]

Feature Request

Opening a feature request kicks off a discussion.

Proposal:

Currently i use telegraf collect windows proccess metrics, and i also use it to gather windows the specific services. I want to select this service process metrics.

Current behavior:

Now i select measurement procstat and win_services, measurements have not related.

Desired behavior:

win_services add pid field or tag, make two measurements related.

Use case: [Why is this important (helps with prioritizing requests)]

Can use procstat.pid and win_services.pid to select the specified service process metrics.

[danielnelson]

The biggest problem with PIDs in procstat is that when they are used as a tag you could potentially be multiplying your series size by pid_max. Ideally you would use a different set of tags for uniqueness, ones that don't churn often, but in the case of procstat the only completely general purpose solution is the PID.

With Windows services, I believe the service name is also unique, and the PID is not needed for uniqueness. Because of this I think the PID should be added as a field and the converter plugin can be used to promote the field to a tag in Telegraf 1.7.

Another possibility would be to add a new lookup method to procstat that selects the PID based on the service name, it would be similar to the systemd_unit option. If we did this you could correlate the two series on the service name.

[pytimer]

I agree. :)

I like the second method, beacuse user can collect metrics about correlate the two series on the service name with this method.

I see procstat use pid_tag option to set PID as a tag, why win_services can not use like it?

Now in the Linux, i use procstat systemd_unit option to collect the related process metrics. But in Windows, i don't know which lookup method can do it.

In addition, systemd_unit only collect MainPID process, but i see some systemd no MainPID, can we collect all cgroup pids? I don't know my idea whether correct.

[danielnelson]

I see procstat use pid_tag option to set PID as a tag, why win_services can not use like it?

This option made sense when it was introduced, but following the pattern is problematic because if you were to add an option for every tag/field someone might want altered the configuration will grow out of control. This is why we have starting adding more processors that can tweak the schema, and in the future I hope to allow processors to be directly attached to plugins to help with the spatial problem of needing to configure them in another location.

Now in the Linux, i use procstat systemd_unit option to collect the related process metrics. But in Windows, i don't know which lookup method can do it.

Let's just add an option win_service = "<service name> which returns an empty slice of PIDs on other platforms? I guess I should mention that I think the bulk of the Windows users are using win_perf_counters for this type of data, but I'm still happy to improve procstat on Windows.

In addition, systemd_unit only collect MainPID process, but i see some systemd no MainPID, can we collect all cgroup pids? I don't know my idea whether correct.

You could probably use the cgroup option to get all processes.

[pytimer]

Let's just add an option win_service = " which returns an empty slice of PIDs on other platforms

Great! :)

I guess I should mention that I think the bulk of the Windows users are using win_perf_counters for this type of data

I know this, but i think use the same inputs plugin on different platforms is nice, and config is also easy.

You could probably use the cgroup option to get all processes.

I try cgroup option, but in my case, i use a application to create telegraf config file, when add a systemd, telegraf can monitor it. But i don't know systemd cgroup path, i only know system_unit name, so i hope use system_unit option to collect all cgroup processes.

[danielnelson]

On the systemd_unit issue, can you open a new issue with an example of the problem. Maybe we can find a way to solve that issue directly.

[pytimer]

ok, i will open a new issue to describe it.

[pytimer]

Hi, @danielnelson .

I send a PR to implement this issue. I hope you can review it if you have time.

Some checks were not successful for this pr. I am not very clear about how to make changes, if it can not ignore, can you tell me how to fix it? Thanks.

[glinton]

closed in #4811