096a73fb29
BREAKING: Remove http.status_code attribute from the http.server.active_requests metric ( #3366 )
2023-04-06 21:36:41 -07:00
46e47de82d
Change `db.statement` to only be collected if there is sanitization ( #3127 )
2023-04-06 10:35:33 -07:00
0902d5f429
Add semantic conventions for log record ID ( #3047 )
...
Fixes #597
## Changes
- Add a section for "generic attributes" to the log semconv
- Add an attribute `log_record.id` making use of ULID as discussed in
#597
Some additional notes:
- I kept the PR small, so I left out some other potential attributes,
e.g. something for pre-existing ID (like windows event logs) or for
storing the used logging/eventing system or even something like a
"signature" that might be worth discussing, etc.
- I followed the structure of "generic attributes" from the spans
semconv
- I took some of the existing wording from #597 &
https://github.com/open-telemetry/oteps/pull/97#discussion_r421865344 to
describe the field
---------
Signed-off-by: svrnm <neumanns@cisco.com>
Co-authored-by: Joao Grassi <joao@joaograssi.com>
Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
2023-04-06 13:14:26 -04:00
189cb12e7a
Add warning about net.* attributes which are used by HTTP semconv ( #3278 )
...
Fixes #3260
(a first try at least)
## Changes
Splits `net.*` attributes into two sections, and adds this warning to
the attributes in the first section:
> **Warning** Most of the attributes in this section are in use by the
HTTP semantic conventions.
Once the HTTP semantic conventions are declared stable, changes to the
attributes in this section will only be allowed
if they do not cause breaking changes to HTTP semantic conventions.
Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>
Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
2023-04-06 10:05:07 -04:00
7138e40aec
Add Trino to db.system semantic conventions ( #3347 )
2023-04-05 21:07:06 +02:00
dcd39bf86e
Mark `service` and `telemetry.sdk` resource attributes as stable. ( #3202 )
...
## Changes
This PR marks the set of resource semantic conventions, which a relied
upon in stable API / SDK specification, as stable themselves.
- Add a caveat that changing `service.*` and `telemetry.*` names need
MORE than just schema file changes.
- Mark core Resource attribute semconv document as MIXED stability
- Update key sections for Resource attribute semconv as stable
- Mark `telemetry.sdk` and `service` attribute groups as stable.
- Move `telemetry.auto` and `service.*` "contentious" attributes into
`{section}_experimental.yaml` file. This retains the reserved name, but
does not mark the convention as stable, allowing us to ensure stable
portions of our specification refer to stable semconv.
- Update examples for `service.instance.id` to include an example of the
preferred style instance id before the fallback.
Related issues #3177
## Usage in the Specification
One reason we should mark these attributes as stable is because they are
referenced from numerous stable portions of our specification, and they
are also leveraged from newly stabilizing portions of our specification.
- [Resource
SDK](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#sdk-provided-resource-attributes )
- stable
- [Environment
Variables](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#general-sdk-configuration )
- stable
- [Jaeger
Exporter](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/jaeger.md#resource )
- stable
- [Zipkin
Exporter](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/zipkin.md#service-name )
- Stable
- [Log
DataModel](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#rfc5424-syslog )
- Stable
- [Prometheus
compatibility](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#resource-attributes )
- still experimental
- [Performance Benchmark
Guidelines](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/performance-benchmark.md )
## A note on ECS compatibility
Here's [ECS service
definition](https://www.elastic.co/guide/en/ecs/current/ecs-service.html ).
They include more attributes than we do. The only possible conflict
between us is `service.instance.id` vs. `service.node.name`. In this
case, our `service.instance.id` has a fallback of generating UUID which
is inconsistent w/ `service.node.name` which requires a user-generated
name if another name cannot be provided.
There's an opportunity for us to unify here. However, I don't think
there's appetite in OTEL to require user-specified names in lieu of some
algorithm or generative specification.
2023-04-03 19:40:12 -07:00
80e42491fe
BREAKING: Change span statuses for gRPC server spans ( #3333 )
...
Fixes https://github.com/open-telemetry/opentelemetry-specification/issues/3110
## Changes
The idea behind the PR is to make the spam statuses gRPC convention
similar to HTTP semantic conventions.
The gRPC statuses -> HTTP status codes mapping is not anywhere strictly
defined.
However, there is are some approximations which can be found:
-
bb04e070b3 (diff-c94ff143c8f378e6925a985fa18528a8254a6d7fc34bc855e1de13f1e7f3e464)https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto
I got confused if we should treat `INTERNAL` as `Error` for
`SpanKind.SERVER` because of:
-
https://github.com/grpc/grpc/blob/master/doc/http-grpc-status-mapping.md
-
a02aae6168/internal/transport/handler_server.go (L90C8-L92)a02aae6168/internal/transport/http_util.go (L73)https://github.com/grpc/grpc/blob/master/doc/statuscodes.md )
of `INTERNAL` says:
> Internal errors. This means that some invariants expected by the
underlying system have been broken. This error code is reserved for
serious errors.
Therefore, I decided to leave it as `Error`. Also because this is
backwards compatible (at least for this gRPC status).
---------
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
2023-04-03 11:27:56 -06:00
64846c4035
Fix units in the Kafka metric semantic conventions ( #3300 )
...
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
2023-03-29 19:16:47 +02:00
e857d8146d
Cosmos DB attributes: fixes UserAgent description ( #3338 )
2023-03-29 09:44:40 -07:00
dcc954abd6
AWS Lambda - remove references to messaging.destination.kind and messaging.source.kind ( #3348 )
2023-03-28 18:14:27 +02:00
4e836b488f
Update JS environment variable compliance ( #3226 )
2023-03-27 13:16:40 -07:00
b3414fcb7f
Issue #3236 Update attribute requirement levels in hardware metrics semconv ( #3258 )
...
Fixes #3236
## Changes
* Update attributes requirement levels in
`specification\metrics\semantic_conventions\hardware-metrics.md`
* Minor wording corrections
2023-03-24 19:29:20 -05:00
13e82eae88
erlang/elixir: add stacktrace representation to table ( #3313 )
...
Adds the functions to use for stacktrace representation in Erlang/Elixir
to the semantic conventions table for exceptions.
2023-03-24 12:05:38 -06:00
efa4181f83
Added AWS S3 semantic conventions ( #3251 )
2023-03-22 08:29:16 -07:00
006e3b4091
Add Cosmosdb attributes for open telemetry ( #3097 )
2023-03-21 10:49:17 -07:00
139842c9e0
BREAKING: remove messaging.destination.kind and messaging.source.kind values ( #3214 )
...
Fixes #3170 , #3265 , #3249
## Changes
~~We currently allow `topic` or `queue` on `messaging.destination.kind`.
While it's common in messaging world to have one or another, messaging
semantic conventions can be applied to AMPQ communication (which does
not have topic/queue terminology), [socket.io](https://socket.io/ ), and
potentially other less traditional messaging use-cases.~~
It's unclear how `messaging.destination.kind` and
`messaging.source.kind` could be used. The distinction between queue and
topic is significant for messaging and distributed systems, but not for
tracing.
In either case, tracing backends should expect to process traces from 0+
messaging and 0+ messaging consumers. In either case, message consumers
can be simultaneous or consequent and there could be many of them.
The only known case (Solace) where it could be useful is when messaging
system allows having queues and topic with the same name on the same
broker, and it could be used to distinguish one from another.
Based on messaging SIG discussion, the attributes are removed for the
time being until we understand if and how they are useful.
Depending on messaging system queues or topics behavior vary a lot and
in future it would makes more sense to represent actual behavior with
individual attributes such as:
- auto-settlement (at-most-once or at least once guarantees)
- settlement for individual messages or offsets
- broadcast or unicast
- etc
2023-03-21 10:51:55 -06:00
e22e6d4674
Make markdown-link-check work again ( #3327 )
...
Link check is broken due to
https://github.com/tcort/markdown-link-check/issues/246 , pinning
previous version until it's fixed
2023-03-21 08:19:14 -06:00
1bae921042
Add `toc` for metric http semconv ( #3318 )
...
## Changes
Add `toc` for metric http semconv markdown file
Signed-off-by: Peter Liu <lpfvip2008@gmail.com>
Co-authored-by: Reiley Yang <reyang@microsoft.com>
2023-03-16 22:52:38 -04:00
b7e8b54419
BREAKING rename `net.app.protocol.(name|version)` to `net.protocol.(name|version)` and replace `http.flavor` with `net.protocol.(name|version)` ( #3272 )
2023-03-10 10:15:15 -08:00
ade0ab600a
[editorial] Use path, not external URL, for link to spec page; and fix broken link ( #3310 )
2023-03-10 07:39:32 -08:00
12328be1c2
Metric units should use UCUM case sensitive variant ( #3306 )
2023-03-08 10:57:55 -08:00
d28c963926
Fix grammatical number of metric semconv units ( #3298 )
2023-03-08 09:17:29 -08:00
40a91717ba
Show relationship between http target and route in example usage ( #3292 )
...
## Changes
Clarify relationship between `http.target` and `http.route` by using the
same pattern in the example usage. Having different patterns for the
attribute values distorts the relationship between the two attributes.
A similar pattern is seen in the docs for
[`aws-lambda.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/instrumentation/aws-lambda.md#api-gateway-request-proxy-lambda-tracing-passive ),
where `http.target` is `/pets/10` and `http.route` is `/pets/{petId}`.
It's a minor adjustment but should help provide clarity for new users.
---------
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
2023-03-08 09:12:28 -08:00
489fea52c8
net.peer.name clarification for HTTP client semconv ( #3276 )
...
Fixes #3273
## Changes
Clarifies that if an HTTP client request is explicitly made to an IP
address, e.g. `http://x.x.x.x:8080 `, then
`net.peer.name` SHOULD be the IP address `x.x.x.x`.
2023-03-06 09:33:35 -06:00
c7c60cae12
Expand pool.name in semantic conventions ( #3050 )
...
according to the discussion here:
https://github.com/open-telemetry/opentelemetry-specification/issues/3038
I'm updating the `pool.name attribute`
2023-03-03 10:59:56 -06:00
c9ff781e94
Make net.sock.host.port conditionally required ( #3246 )
2023-03-02 14:01:52 -08:00
6d7b233c80
Rename http.user_agent to user_agent.original ( #3190 )
...
Fixes #3180
## Changes
Renames `http.user_agent` to `user_agent.original`.
2023-03-02 14:47:29 -06:00
47cabcf799
Rename Optional attribute requirement level to Opt-In ( #3228 )
2023-03-01 15:13:24 -08:00
f839f1ed9a
clarify how to collect host.id for non-containerized systems ( #3173 )
2023-02-28 18:17:04 +01:00
90a7dae56c
Remove mention of net.transport from http semantic conventions ( #3244 )
...
Based on @lmolkova's
https://github.com/open-telemetry/opentelemetry-specification/issues/3215#issuecomment-1439068151
## Changes
Removes mention of `net.transport` from http semantic conventions.
---------
Co-authored-by: Reiley Yang <reyang@microsoft.com>
2023-02-28 10:52:04 -05:00
e9d9309590
Update build-tools to 1.16.0 ( #3259 )
...
build-tools 1.16.0 was just released and is necessary to unblock
https://github.com/open-telemetry/opentelemetry-specification/pull/3190
2023-02-27 17:39:23 -05:00
2447fb063f
Expand scope of `faas.id` to `cloud.resource_id` ( #3188 )
...
## Changes
As per the discussion on #3188 , we determined it is better to move
rather than remove as this attribute is still important for some systems
despite it containing duplicated information.
2023-02-27 12:13:13 -06:00
12481fef89
add semantic conventions for heroku ( #3075 )
...
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
2023-02-27 10:23:29 +01:00
a0691c65ed
Rename nonheap to non_heap ( #3250 )
...
Fixes
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7876
(the implementation used `non_heap`, which seems better)
## Changes
Renames JVM metric attribute value from `nonheap` to `non_heap`.
---------
Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
2023-02-24 09:59:43 -06:00
85ec713c1c
Metric requirement levels ( #3237 )
2023-02-23 08:22:54 -08:00
0f2a834cda
Add Connect RPC to semantic conventions ( #3116 )
...
* Add connect_rpc to rpc.yaml
* Add connect rpc into rpc-metrics and rpc markdown
* Add Connect RPC change to CHANGELOG.md
* Update CHANGELOG.md
---------
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
2023-02-21 09:50:35 -05:00
0d0b9d0a7d
Rename `faas.execution` to `faas.invocation_id` and change units for `faas.max_memory` ( #3209 )
2023-02-20 09:29:24 -06:00
1971550982
[editorial] Fix Tencent Cloud link ( #3231 )
2023-02-20 10:29:04 +01:00
702cf2cdf3
Rename Logs API to Logs Bridge API to prevent confusion ( #3197 )
...
We keep seeing confusion about what Logs API is. There was a proposal [1]
to use the term Bridge API to help prevent the confusion.
Please take a look and comment on whether you think this renaming helps
and is reasonable.
[1] https://github.com/open-telemetry/opentelemetry-specification/pull/3187#issuecomment-1424431424
2023-02-16 14:55:56 -05:00
6086a26696
Update exceptions.md ( #3217 )
2023-02-16 05:42:42 -06:00
8290599ccd
Get rid of double negation in Events semantic conventions ( #3159 )
...
* getting rid of double negation
* Update specification/logs/semantic_conventions/events.md
Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
---------
Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
2023-02-15 14:56:19 -05:00
a0f96da61f
Fix rpc examples to include grpc namespace ( #3211 )
2023-02-15 09:12:30 -08:00
3a0a197f4c
Use attribute_group for cross-signal HTTP attributes ( #3183 )
2023-02-13 16:00:14 -08:00
30ef366d8a
Update aws lambda spec to remove X-Ray Env propagation ( #3166 )
...
* Update aws lambda spec to remove X-Ray Env propagation
Per discussion in the FAAS SIG, we decided that the aws x-ray environment variable should be moved to a span link to avoid interfering with the configured propagators.
2023-02-10 10:57:34 -06:00
1781e9270e
Add 1.1.8.0 Schema. ( #3175 )
2023-02-07 13:01:58 -06:00
2165c692f9
Http route should contain application root ( #3164 )
2023-02-06 12:50:01 -08:00
27e087b3b6
Add http metrics yaml ( #3158 )
...
* Add http metrics yaml
* Update change log
* Fix notes
* Fix link
* Remove unnecessary field
2023-02-06 12:54:51 -05:00
9170ccaeeb
Changes to http span name ( #3165 )
2023-02-03 08:33:10 -08:00
912809fb42
Enable semantic convention tooling for metrics ( #3119 )
2023-01-24 08:52:53 -08:00
e35ad2b9d5
[semantic_conventions/resource] fix google platform openshift naming ( #3095 )
2023-01-23 14:56:48 -08:00
Trask Stalnaker