Add semantic conventions for process resource

[james-bebbington]

Adds semantic conventions for process as a resource which represents a regular operating system process.

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ James Bebbington (1de8bf1)

[arminru]

Please make sure to add an entry in the changelog:
https://github.com/open-telemetry/opentelemetry-specification/blob/master/CHANGELOG.md#unreleased

[Oberon00]

I don't think using "nil" is clear here. Also, this is ambiguous. If I have only a single string with spaces but no nil, it is impossible to determine if I have some\ command\ with/spacesinpath and no arguments, or a GetCommandLineW-encoded command line.

[james-bebbington]

There is also concern around using two different data types to represent the same attribute value: #635 (comment). It might create additional complexity on back end systems to have to manage potentially different data types for the same attribute, though I'm not sure how much of a concern this would be? I guess parsing null-characters on the back end would likely be equivalently complex.

Note this isn't strictly ambiguous btw. If that was a command with no arguments, and you were looking at the Unix representation, it would have a null-character as the last character in the string. On Windows it would not. Admittedly that is not a great representational difference, and could be difficult to distinguish in some programming languages.

After thinking about this some more, I think I do prefer the list of strings approach, but I'm not sure I'm aware of all the pros/cons. For now I have changed it back to that, and updated the example for each OS accordingly. But for the record here's the three options considered and pros/cons:

1. Join arguments with a string:
   Advantages: Most consistent representation across OSs.
   Disadvantages: Potentially lossy/non-trivial conversion on Unix - do we need to enquote parameters with spaces in them (and escape internal quotes), etc?
2. Pass through string returned from OS as is (null-delimited on Unix):
   Advantages: No processing needed by code producing telemetry, can just provide what OS returns.
   Disadvantages: Back end needs to parse null-characters.
3. Convert to list of strings (for Unix only):
   Advantages: Clean ("properly typed") representation.
   Disadvantages: Inconsistent data type for the same attribute between OSs, and back end needs to handle this differently.

FYI @arminru note I've reverted the changes based on your last comment since you approved. Please take another look.

@igorpeshansky you may also be interested.

[jrcamp]

Interestingly ps on Mac and Linux doesn't appear to apply any quoting so if there are spaces or quotes in in your argument (e.g. app --set "foo bar") ps doesn't appear to quote them. We could quote them (https://godoc.org/github.com/gonuts/go-shellquote#Join [1]). I can't think of any downsides in particular when it comes to filtering on quoted values. I think in most cases you're not going to be doing filtering on values that have quotes in them or other escaped characters. I imagine the common case is you're searching for commands that have basic things like "repl-factor" or some such in it.

[1] Not endorsing it, just searched for a shell escape library in go.

[MrAlias]

In favor of the addition. Only questions are around specific naming, i.e. just bikeshedding.

[MrAlias]

I usually see commandline as two words. Do we want to build naming hierarchy here as well? Or, just insert a separator?

[james-bebbington]

Changed this to process.command_line for now. I'm not sure if process.command.name would be a reasonable name for the "command"

[MrAlias]

SGTM 👍