-
Notifications
You must be signed in to change notification settings - Fork 888
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
Rename "Label" concept to "Attribute" for consistency with OpenTelemetry tracing #1113
Comments
|
I am not sure I understand this motivation. For me there are 2 different concepts that do not belong to any signal (which is a major part of my confusion):
Once we define these concepts, different signals can use one of them (that best fit the requirements). I am not sure what is the confusion, and not sure that making metrics using What is the problem that we solve if we rename the metrics key-values with |
Next steps, suggested from from today's Spec meeting:
|
We also briefly considered including TraceState in this discussion, but decided that since we couple it to W3C TraceState and it has quite a few special rules and because it will typically have values that consist of multiple sub-keys per vendor/entry (serialized as string) it does not make sense to allow non-string values there. |
Not completely sure what the remaining questions are but: Can metrics just be defined to only have "String Attributes"? Then anything else is dropped if it isn't a string. This gets rid of the multiple names for things while makes clear only strings are allowed. Or is the issue that dropping isn't an option and thus have to define string representations of everything? Maybe reopen as an issue titled "How to Convert Non-String Attribute Values as Strings" :) |
@bogdandrutu want to reassign this to me? I'm getting to work on a string conversion OTEP. |
At the SIG today, we are going to move forwards at this time by:
|
We discussed this heavily today at the Metrics Data Model SiG. The three proposals discussed are here. I'm including the "consensus proposal" of that group here for implementation (volunteered by @bogdandrutu ): Use Attribute and treat different types values as different things.In this proposal, we alter OTLP to leverage the same KeyValue proto on metrics and drop the use of Label / StringKeyValue in the specification. The API/SDKs will export metric "Attributes" that have string keys and multi-typed values (can be anything supported by AnyValue in OTLP). The collector will not attempt to unify types between attributes of the same name. If two attribute keys on the "same metric" are received that have different types, this is considered an error.
Note: Metric identity specification may need more clarity in the (pending) data model specification. Pros
Cons
|
I wasn't able to make it to the Model SIG, what was actual blocker here? |
Give opentelemetry-proto#283 is merged here, I think remaining work is in the metrics API specification. Does that sound right @reyang ? |
The API spec is also done (addressed by #1557). |
What are you trying to achieve?
The resolution from #948 is that "Label" should be renamed "Attribute" for consistency across OpenTelemetry. This has been discussed widely and there are no objections on the Metrics SIG to this renaming.
This renaming will introduce a breaking change for JSON-format exporters using OTLP v0.5, but will not introduce a binary-format incompatibility when this change is released as OTLP v0.6.
The specification will be updated to explain that although we use a single concept and term to describe attributes, sometimes we choose to limit their values to only strings. To address this across OpenTelemetry, we will specify how to handle the situation whenever requesting a string-valued attribute in a context where it would be prohibitively expensive to support. These cases are:
In both cases, I think a simple text-value replacement like "unrepresentable" would satisfy me.
Additional context.
Issue #948 contains a lengthy discussion of this topic. The terms "Attribute", "Label", "Tag", "Property", and "Association" are all very close in meaning, and we have come to agree that having more than one of these terms in use causes more trouble than it helps with.
The text was updated successfully, but these errors were encountered: