forked from open-telemetry/semantic-conventions
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fix docfx checks #1
Open
pyohannes
wants to merge
482
commits into
main
Choose a base branch
from
fix-docfx-checks
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…etry#1197) This topic has come up at least 3 times now. I believe a clarification is warranted. The clarification is aligned with previous recommendations: open-telemetry/opentelemetry-specification#789 (comment) open-telemetry/opentelemetry-specification#882 (comment) open-telemetry/opentelemetry-specification#1194 (comment)
* Nulls SHOULD NOT be allowed in arrays. * Fill in CHANGELOG link Co-authored-by: Armin Ruech <[email protected]>
* Declare freeze of Trace Specification 1.0 We want to freeze Trace specification 1.0 so that we no longer accept substantial changes (unless a fundamental problem is found in the spec). Resolves open-telemetry/opentelemetry-specification#1120
I noticed developers adding their own attributes to this namespace without going through the specification. We need to regulate this namespace through the specification, just like we do it for other semantic conventions.
Resources are not susceptible to scenarios where excessive attributes can be recorded unlike Spans. Resources are also immutable and it can be hard for some SDKs to apply the limits at source at the time the attributes are added to a resource. Furthermore, limits and Resources both are generally defined and passed on to a TracerProvider which forces a TracerProvider to either mutate the resource or generate a new one with duplicate attributes in order to apply the limits to it. Co-authored-by: Tigran Najaryan <[email protected]>
…tributes (plural) (#2123) * Provide a normative definition of Attribute (singular) - Providing a normative definition of **attribute** (singular) - Other copyedits /cc @austinlparker @tedsuo * Move anchor to make markdown checker happy
* Prohibit usage of retired names in semantic conventions This change adds a prohibition clause that requires that no old metric or attribute name is used for a new attribute. This is important to ensure reversibility of schema transformation (converting from a new version to an old version of schema). Without this restriction the following is possible: Schema version 1. Attribute A exists. Schema version 2. Attribute A is renamed to B. Appropriate schema file is created. Schema version 3. Attribute A is introduced (a completely different new attribute). Now attempting to go from Version 3 to version 1 is impossible since it requires renaming B to A (for the change in version 2), but a different attribute A already exists. * Fix based on comments * Add changelog entry Co-authored-by: Carlos Alberto Cortez <[email protected]>
Attributes keys must be unique. The key/value pair collections in the specification was always intended to model a map. There was a recent confusion about this. This change clarifies the spec. Resolves open-telemetry/opentelemetry-specification#2245
…2276) * Clarify that Trace/Meter are associated with Instrumentation Scope This is a slightly different take on open-telemetry/opentelemetry-specification#2203 Instead of renaming instrumentation library to instrumentation scope everywhere this PR suggests targetted editing of wording of the Trace/Meter obtaining API to allow not just instrumentation library but other instrumentation scopes to be used as a parameter. This change does not force renaming of API parameters and is not a breaking change. We consider it a clarification of usage to match the intent that we had for the "name" field. If this PR is accepted there will be a follow up PR that will suggest to rename InstrumentationLibrary* messages in OTLP proto to InstrumentationScope* message. Such a change will not be a breaking change for the OTLP wire format and is acceptable. If this PR is accepted we will also close open-telemetry/opentelemetry-specification#1236 since it will be no longer necessary. The logger name will be recorded as the instrumentation scope. This clarification will be a follow up PR that clarifies the behavior in https://github.com/open-telemetry/oteps/blob/main/text/logs/0150-logging-library-sdk.md
…y support strings (#2343) * Describe how to handle converting non-string primitives for protocols that only support strings * update wording to make clear that only non-string values are converted to strings * unify language * Update specification/common/common.md Co-authored-by: Joshua MacDonald <[email protected]> Co-authored-by: Joshua MacDonald <[email protected]> Co-authored-by: Bogdan Drutu <[email protected]>
OTEP 0178 [0] proposed this mapping. This PR merges the proposal into specification. The content of this PR is mostly copy/paste of the text of the OTEP minus the irrelevant sections such as "Alternates", etc. 0 - https://github.com/open-telemetry/oteps/blob/main/text/0178-mapping-to-otlp-anyvalue.md
* nits * review comments * No exceptions for Required attributes, clarifications on performance * Conditional clarifications * nits * Conditional -> required conditionally and minor fixes * Align requirement levels with RFC levels better * Clarify Note on required attributes * Update specification/common/attribute-requirement-level.md Co-authored-by: Tigran Najaryan <[email protected]> * Clarify Note on required attributes * Remove performance from conditionally required attributes * Clarify Conditionally Required case when condition is false * Apply suggestions from code review Co-authored-by: Tigran Najaryan <[email protected]> * Apply suggestions from code review Co-authored-by: Christian Neumüller <[email protected]> * headings for levels and moving things around * nits: formatting Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: Christian Neumüller <[email protected]> Co-authored-by: Reiley Yang <[email protected]>
Resolves #2752. This aligns log SDK and API concepts which have diverged after the merged of #2676. This PR brings alignment to the log API and SDK, and in brings the log signal into alignment with tracing and metrics where there is conceptual overlap. There shouldn't be any new concepts introduced here. - Rename `../logs/logging-library-sdk.md` to `../logs/sdk.md` - Remove wording from SDK that implies that an API doesn't exist, like [this](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/logging-library-sdk.md#L60-L62). - Move [How to Create Log4j Style Appender](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/logging-library-sdk.md#L219) to `api.md` since it describes an API use case. - Move [Implicit / Explicit Context Injection](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/logging-library-sdk.md#L270-L288) sections to `api.md` since they describe API level considerations. - Rename Logger [create](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/api.md#L133) method to be emit, to align with SDK concept of `LogRecordProcessor#onEmit(..)`. - Rename `LogProcessor`, `LogExporter` to `LogRecordProcessor`, `LogRecordExporter`. - Fill in various SDK level TODOs related to shutdown and flushing. The language from these was taken directly from the metrics / tracing SDK - no new concepts were introduced.
* Define semantic conventions yaml for non-otlp conventions Signed-off-by: Bogdan Drutu <[email protected]> * Update semantic_conventions/trace/exporter/exporter.yaml Co-authored-by: Christian Neumüller <[email protected]> * Update semantic_conventions/scope/exporter/exporter.yaml Co-authored-by: Joao Grassi <[email protected]> * Rename otel to otel_span Signed-off-by: Bogdan Drutu <[email protected]> Signed-off-by: Bogdan Drutu <[email protected]> Co-authored-by: Christian Neumüller <[email protected]> Co-authored-by: Joao Grassi <[email protected]>
Fixes #2860 Adds log attribute limit configuration. These new environment variables bring more consistency between spans and logs.
Co-authored-by: Armin Ruech <[email protected]>
…attributes, remove common (open-telemetry#931)
…metry#909) Co-authored-by: Joao Grassi <[email protected]> Co-authored-by: Trask Stalnaker <[email protected]> Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Joao Grassi <[email protected]>
…en-telemetry#794) Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Trask Stalnaker <[email protected]> Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Armin Ruech <[email protected]>
…lemetry#945) Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Liudmila Molkova <[email protected]>
) Co-authored-by: Trask Stalnaker <[email protected]>
Co-authored-by: Joao Grassi <[email protected]> Co-authored-by: Joao Grassi <[email protected]> Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Alexandra Konrad <[email protected]>
…ute (open-telemetry#968) Co-authored-by: Liudmila Molkova <[email protected]>
…telemetry#933) Signed-off-by: ChrsMark <[email protected]>
…and rename `db.client.connection.usage` to `db.client.connection.count` and adapting units (open-telemetry#966) Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Trask Stalnaker <[email protected]> Co-authored-by: Joao Grassi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.