-
Notifications
You must be signed in to change notification settings - Fork 896
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
Add process.start_time
resource attribute to semantic conventions
#2825
Add process.start_time
resource attribute to semantic conventions
#2825
Conversation
1de5b2e
to
1831a95
Compare
@@ -35,6 +35,7 @@ | |||
| `process.command_line` | string | The full command used to launch the process as a single string representing the full command. On Windows, can be set to the result of `GetCommandLineW`. Do not set this if you have to assemble it just for monitoring; use `process.command_args` instead. | `C:\cmd\otecol --config="my directory\config.yaml"` | Conditionally Required: See alternative attributes below. | | |||
| `process.command_args` | string[] | All the command arguments (including the command/executable itself) as received by the process. On Linux-based systems (and some other Unixoid systems supporting procfs), can be set according to the list of null-delimited strings extracted from `proc/[pid]/cmdline`. For libc-based executables, this would be the full argv vector passed to `main`. | `[cmd/otecol, --config=config.yaml]` | Conditionally Required: See alternative attributes below. | | |||
| `process.owner` | string | The username of the user that owns the process. | `root` | Recommended | | |||
| `process.start_time` | int | The start time of the process in UTC, expressed as number of seconds since the Unix epoch. | `1663931438` | |
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.
Is second good enough or a higher precision is desired?
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 the ECS's process.start is the better option here?
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.
Related to open-telemetry/oteps#199 (comment).
1831a95
to
2b837e4
Compare
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.
Semantic conventions on Resource Attributes that can affect metric identity should be held off for now.
Additionally, I'd really like to understand the use case for including start_time
in the resource better. I don't think the justification in the PR is enough. Can you outline the use case / expected use of this compared to metric start times, and an actual metric recording process start time?
There are two reasons for proposing the process start time as an attribute of the process resource:
Does adding this resource attribute cause cardinality explosion? I don't think so. It causes a "serial" split of timeseries rather than a "parallel" one (I wonder if this description makes sense). As a side note, please note the comments on this PR's issue about the Elastic Common Schema's |
10b66c3
to
653fd71
Compare
653fd71
to
44efdde
Compare
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
44efdde
to
f8da4ee
Compare
@jsuereth any update on this? |
f8da4ee
to
11045a6
Compare
Rebased the PR. |
b4d8494
to
51f3e0a
Compare
51f3e0a
to
0e24dc3
Compare
Process identity isn't in a vacuum. All telemetry from OTEL includes a timestamp when it was created, and metrics specifically include start/now timestamps. Additionally, process isn't the only identity we'll attach. We'll include VM, pod, container, etc. instance metadata. Is pulling process start time something we want all SDKs doing via an external mechanism? I realize you're taking the process-metric view, but this also impacts SDKs. E.g. Java's ProcessResource. Do you have a way to do this for all languages? At a minimum, I think process.start_time should be "optional" not "recommended".
Almost every metric produced by a metric SDK will (effectively) include a start_time that is likely the process start time. I'm not suggesting you create a new metric I'm asking about the (inherent) duplication that will likely occur here. More importantly, it's likely that most SDKs just assume a start timestamp of the first timestamp they grab on startup. Is this ok to use for process start_time? Do we expect consistency for SDK-reported metrics and process.start_time to align with the metric start_time?
Yes. I can understand this argument. However, even if it does a serial split, it can still cause load on TSDBs in other ways. This why, even for serial splits, OpenMetrics still encourages being frugal and minimal with labels. My main question here is whether or not process start time adds enough value to justify its weight?
I think we should aim for compat with ECS when there's no clear advantage one way or another. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Fixes #1273
Changes
Adds a new resource attribute
process.start_time
to the semantic conventions.Here's a related pull request that adds
process.uptime
andsystem.uptime
metrics: #2824.I also wanted to add a
system.start_time
resource attribute, but I'm not sure where to put it - there's nosystem
namespace in the resource attributes at the moment; the closest I could find is theos
namespace. Should I add anos.start_time
attribute?