Hi #1
Open
Hi #1
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
…#3538) Currently the specification seems to implicitly imply a duplicate instrument registration occurs across identical Meters from the same MeterProvider. This change makes that fact explicit. The alternative, having duplicate instrument registrations occur across all MeterProvides, seems unlikely the original intent. That would require global tracking beyond the scope of a MeterProvider, and the MeterProvider is stated to be the main source of configuration.
…3571) - Contributes to open-telemetry/opentelemetry.io#1170, because of OTel spec pages - Replaces `attribute["client.address"]` by `Attributes["client.address"]`, since `attribute` appears to be a **typo** - Fixes `<td>` spread across multiple lines with intervening blank lines, since that generates **invalid HTML** in some cases. - In most cases I replaced line breaks with `<br>`. - Replaces code tick markdown syntax in two places since those entries are in "HTML-only" format. For example: replaces \`Debug\` by `<code>Debug</code>` /cc @svrnm @cartermp
Added Python support for "The View instrument selection criteria supports a unit." According to open-telemetry/opentelemetry-python#3341
Clarifies that _total does not need to be added as a suffix to counters if it already exists. There was confusion in open-telemetry/opentelemetry-java#5304 (comment) if that was correct or not.
Currently the build is broken as location were massaged in the semantic-conventions repository.
- Followup changes for open-telemetry/opentelemetry.io#2793 - There are only changes to Hugo front matter - Adds `likeTitle`s for "Compatibility" pages - Adds aliases for pages that have moved or were renamed - Related: open-telemetry/opentelemetry.io#3013 -- the `compatibility/openmetrics` spec page is in the list because it was renamed /cc @svrnm @cartermp
…al spec page (#3591) Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
July Release.
…n prometheus counters (#3590)
This is only for prometheus language exporters, and doesn't cover collector components.
## Changes Looking at #3585, I found a typo. While looking through the page I found a few more. Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
- Make it normative that an SDK is recommended to include both types of default reservoirs. - Make the description of both default reservoirs their own sub-sections. - Correct the "SimpleExemplarReservoir" section to be titled "SimpleFixedSizeExemplarReservoir". - Loosen the SimpleFixedSizeExemplarReservoir to allow any uniformly-weighted sampling algorithm instead of just the naive one that is not optimal. - The current algorithm has an asymptotic running time of `O(n)`. There are other sampling algorithms that produce equivalent results and have more optimal asymptotic running times. Therefore, do not restrict implementations to only implementing the inefficient algorithm.
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
The link still pointed to the archived version of it. Also removing the APAC meeting, which is no longer accurate.
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
…4087) Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
## Why Fixes #4010 (read the issue for more details) The SDK SHOULD offer a way to make independent log processing. I find it as a missing feature that should be covered by by the specification. ## What This PR tries to achieve it in the following way: - SDK SHOULD provide an isolating processor allowing independent log processing pipelines. Source: #4010 (comment) This approach should be solving the issue at least for Java, .NET, Python, JavaScript, Go. This proposal should not make any existing log SDKs not compliant with the specification. I think that the same approach could be also adopted in tracing for span processors (but I have not yet investigated it in depth). ## Remarks I created a separate issue for specifying whether (by default) a change to a record made in a processor is propagated to next registered processor. See #4065
…rding links after span creation (#4101)
Closes #3303 ## Changes From @tigrannajaryan in #3303 (comment): > I think the conclusion in #3518 was that we keep the names. It has been a while and there is no new evidence that we need to do something else so I suggest that we submit a PR that declares https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/logging_trace_context.md "Stable" and closes this issue. This marks the specification for using `trace_id`, `span_id`, and `trace_flags` in non-OTLP logging formats stable.
July 2024 release.
Fixes #2095 ## Changes State that sampler description can change over time. Provide examples. --------- Signed-off-by: Yuri Shkuro <github@ysh.us> Co-authored-by: Robert Pająk <pellared@hotmail.com>
Splitting off a portion of #4142. This PR makes the host and port configuration options explicit for the prometheus exporter. Currently, they're [implied from the corresponding env vars](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#prometheus-exporter) `OTEL_EXPORTER_PROMETHEUS_HOST` and `OTEL_EXPORTER_PROMETHEUS_PORT`. See this [convo](https://github.com/open-telemetry/opentelemetry-specification/pull/4142/files#r1674675871) for more details. --------- Co-authored-by: Robert Pająk <pellared@hotmail.com> Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
… default aggregation (#4142) Reviewing @dashpole's [comments](#4124 (review)) on #4124, I realize that a key clarification is missing for the contract between readers and exporters, and for the configuration of built-in exporters. We [state that](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#metricreader) MetricReaders should be constructed with: - "The default output aggregation (optional), a function of instrument kind. If not configured, the [default aggregation](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#default-aggregation) SHOULD be used." - "The default output temporality (optional), a function of instrument kind. If not configured, the Cumulative temporality SHOULD be used." And for MetricExporters, we [state that](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#metricexporter) "The aggregation and temporality properties used by the OpenTelemetry Metric SDK are determined when registering Metric Exporters through their associated MetricReader." But we don't connect the dots that the `aggregation` and `temporality` options for the MetricReader should be obtained from a MetricExporter. I think this is understood, since the whole reason these are configurable at the MetricReader level is that MetricExporters and their associated backends have different requirements around temporality and default aggregation (especially in the case of base2 exponential histogram). This PR clarifies that the MetricReader `aggregation` and `temporality` options SHOULD come from the associated MetricExporter, NOT from the caller. Furthermore, because these are now clearly spelled out as preferences of MetricExporter, I've updated all the built-in metric exporter definitions to make expectations clear around what defaults and configuration of `aggregation` and `temporality` should be supported. This achieves the goals of #4124 in a more generic way. | Exporter | default `aggregation` | `temporality` | |---|---|---| | Prometheus | configurable | always cumulative | | OTLP | configurable | configurable | | Standard Output | configurable | configurable | | InMemory | configurable | configurable |
Fixes #1089. In addition to the comments on the issue, this was discussed in the spec SIG Meeting on 2024/23/04: * The filtering use-case explained in [this comment](#1089 (comment)) should rather be solved by the upcoming samplerV2 instead of `SpanProcessor`s due to better conceptual fit * The buffering use-case also explained in [this comment](#1089 (comment)) seems to be not relevant enough to influence the design decision * Apparently there was a discussion around building the `SpanProcessor`s in a chaining fashion during the initial SDK spec design and it was actively decided against it. However, no one could recall the reason why.
Follows #4062 ## Why 1. There is a need to make a deep copy of a `ReadWriteRecord` in order to implement an experimental isolating processor outside of the SDK (as it is experimental, we prefer to land it to contrib repository first). 2. Allow fine-grained control for the users to make a deep copy only when necessary. This allows users to have more control on the processing e.g. pass a clone to asynchronous processor to avoid race conditions or make performance improvements.
Leftover after #4035 which changed `Payload` into `Body` in Events API
Fix after open-telemetry/community#2051 CC @austinlparker @svrnm _May be good checking if this does not affect other repos._
Fixes #4053 ## Changes This PR extends the metric data model with data point flags, which were added to the protocol in open-telemetry/opentelemetry-proto#316.
August 2024 Release.
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.
Thanks