Overhaul process command-line resource conventions. #1137
Conversation
Oberon00
added
area:semantic-conventions
Oberon00
changed the title
This comment has been minimized.
This comment has been minimized.
| On Windows and other systems where the native format of process commands is a single string, | ||
| `process.command_args` can additionally (or instead) be used. | ||
|
|
||
| At least one of `process.executable.name`, `process.executable.path`, `process.command`, `process.command_line` or `process.command_args` is required. |
There was a problem hiding this comment.
What if someone only wants to report the PID for whatever reason? What about:
| At least one of `process.executable.name`, `process.executable.path`, `process.command`, `process.command_line` or `process.command_args` is required. | |
| At least one of `process.executable.name`, `process.executable.path`, `process.command`, `process.command_line` or `process.command_args` is required to allow back ends to identify the executable. |
There was a problem hiding this comment.
This paragraph was already there previously, I just added the command_args alternative.
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
|
||
| For backwards compatibility with older versions of this semantic convention, | ||
| it is possible but deprecated to use an array as type for `process.command_line`. | ||
| In that case it MUST be interpreted as if it was `process.command_args`. |
There was a problem hiding this comment.
I added this paragraph to keep the change non-breaking but I would be happy to remove it if deemed unnecessary.
|
|
||
| For backwards compatibility with older versions of this semantic convention, | ||
| it is possible but deprecated to use an array as type for `process.command_line`. | ||
| In that case it MUST be interpreted as if it was `process.command_args`. |
There was a problem hiding this comment.
| For backwards compatibility with older versions of this semantic convention, | |
| it is possible but deprecated to use an array as type for `process.command_line`. | |
| In that case it MUST be interpreted as if it was `process.command_args`. |
I'm not sure if we want to keep backwards compatibility here since the previous solution was a bit unclean IMHO. We don't have multiple types (string and array of strings in this case) for the same attribute anywhere else, which is also why we weren't able to pour these into YAML definitions for the markdown and constants generator tool yet. While not making interpretation impossible, I think it would still be easier for consumers and overall cleaner if we can stick to one well-defined type per attribute.
I would be +1 for a breaking change here if we can settle on this before GA (which I hope we can). The strict trace spec freeze does not apply to semantic conventions as far as I know.
There was a problem hiding this comment.
I think we would still declare command_line as non-array string in the YAML and have this text just there in the markdown as prose. We should clarify that the MUST only applies for those that choose to support this at at all (which should be a MAY).
There was a problem hiding this comment.
I will register that I don't understand why it matters if a value can take on more than one type. I didn't see a problem with command_line being a string or a list. I really wish I knew how people plan on using this information such that the this distinction matters. 😁
There was a problem hiding this comment.
For one, this is not supported by the current semantic convention tool, which is why this file has no corresponding YAML yet.
|
|
||
| For backwards compatibility with older versions of this semantic convention, | ||
| it is possible but deprecated to use an array as type for `process.command_line`. | ||
| In that case it MUST be interpreted as if it was `process.command_args`. |
There was a problem hiding this comment.
I will register that I don't understand why it matters if a value can take on more than one type. I didn't see a problem with command_line being a string or a list. I really wish I knew how people plan on using this information such that the this distinction matters. 😁
jmacd
changed the title
|
This PR formally fulfills the requirements for being merged. So I guess if you want to still review (@anuraaga?) please do so quickly. |
|
@anuraaga On https://github.com/pulls ("Pull requests" in Github's title bar) there is a filter called "Mentioned". That one shows all PRs on which you were mentioned at any point, thus also PRs where you were only mentioned in the description or an old comment, but it's better than nothing 🙂 |
|
@arminru Yeah I generally use github.com/notifications and it has a link for mentions. I need to get used to clicking it at least once a day :D |
Fixes #831, fixes #997
Changes
requiredproperty forprocess.*semantic conventions #997)requiredproperty forprocess.*semantic conventions #997, but this is mainly for languages where the pid is not available)