[procstat] Provide "rollup" per process to avoid lots of threads causing high cardinality problems in InfluxDB

[daviesalex]

Troubleshooting InfluxDB performance with @jwilder , @toddboom , @benbjohnson , @pauldix and @fred-influx we have realized that under the default config, the "pid" tag in the procstat plugin in real world environments is too high cardinality and produces pathological performance. For us the number of processes isnt crazy (we are choosing specific processes, such as MySQL to target). The issue is that the number of threads that can be produced is extremely high and thus the number of PIDs is extremely high. In almost all cases, when using this data, we only care about the sum of all threads at any one time.

Moving this to a field makes the data difficult to query, so we eliminated that as a solution on its own[1]. We discussed some options internally:

1. Compute a per-runtime thread_number based on sorting each thread by time created
2. Provide an option to roll up all threads into a process, i.e. capture one element per process with rolled up data
3. Move PID to a field (perhaps still providing an option to "roll up" to one metric per process rather than thread)

Our preference is (3):

1. Move PID to a field
2. Provide an option to do a "rollup" per process, which sums the values that make sense to sum, passes through the values that dont, and adds a metric like num_threads [in reality, we are doing this at query time most of the time]

RFC from others

[1] but in #1460 others suggested that a field would be a good solution for them on its own. If we can build a consensus on what to do in this issue (perhaps several options with config file settings), we are happy to adjust this plugin and send a PR.

[daviesalex]

Closing as #1460 is better written