15f3e529f1
BREAKING: Remove `messaging.consumer.id`, make `messaging.client_id` generic ( #3336 )
...
Fixes #2015
## Changes
Based on discussions in the messaging workgroup and in issue #2015 , this
PR proposes to remove `messaging.consumer.id`, and to replace both
`messaging.kafka.client_id` and `messaging.rocketmq.client_id` with a
generic `messaging.client_id`.
`messaging.consumer.id` is defined to always be set to the `client_id`
of the used messaging system, except for Kafka, where it was defined to
be a combination of `messaging.kafka.client_id` and
`messaging.kafka.consumer.group`, or just the latter if
`messaging.kafka.client_id` is not available. With this definition, the
semantics of `consumer.id` are different between messaging systems, and
even different for different Kafka scenarios.
The proposed `messaging.client_id` has consistent semantics ("an unique
client id, when it is available"), and can be used instead of
`messaging.consumer.id` in almost all cases.
In addition to have consistent semantics, this also simplifies the
semantic conventions, as instead of
`messaging.consumer.id`
`messaging.kafka.client_id`
`messaging.rocketmq.client_id`
there is now just:
`messaging.client_id`.
2023-04-24 17:13:21 -06:00
92a5b9ef64
Fix JVM buffer pool attribute description ( #3423 )
...
Follow-up to #3413
---------
Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com>
2023-04-21 09:59:59 -05:00
e4613f98af
Converts JVM metrics to yaml ( #3413 )
...
Converts JVM metrics to yaml
2023-04-20 13:56:48 -05:00
aa873f0a9b
add k8s.cluster.uid resource attribute semconv ( #3267 )
...
Fixes #3266
## Changes
Kubernetes doesn't have a formal way to identify a cluster, but a
pseudo-id can be derived by taking the `uid` of the `kube-system`
namespace. This PR adds a convention for `k8s.cluster.uid` to be set to
the `kube-system` namespace uid.
2023-04-18 15:21:28 -06:00
bce030702e
Adds a note about not splitting UpDownCounter timeseries ( #3367 )
2023-04-18 09:14:04 -07:00
bb42c33451
Change http.server.duration and http.client.duration units to seconds ( #3390 )
2023-04-14 20:46:53 -07:00
3250d03e49
Specify seconds unit for measuring durations ( #3388 )
2023-04-14 10:34:54 -07:00
7a74f7ae79
Clarification about when to use UCUM c/s variant ( #3393 )
2023-04-14 09:32:04 -07:00
b94251d236
Mark "Instrumentation Units" and "Instrumentation Types" sections of the general metric semantic conventions as stable ( #3294 )
2023-04-14 09:18:01 -07:00
711413a4d7
HTTP client span clarification ( #3290 )
...
Related to
https://github.com/open-telemetry/opentelemetry-specification/issues/3155
and
https://github.com/open-telemetry/opentelemetry-specification/pull/3234
## Changes
This PR contains the less controversial parts of
https://github.com/open-telemetry/opentelemetry-specification/pull/3234 ;
it describes how the `http.resend_count` attribute should be used, and
proposes two ways of instrumenting HTTP clients.
2023-04-14 09:16:33 -06:00
cf52340b6a
Add recommendation to use non-prefixed units for metric instruments ( #3312 )
2023-04-12 15:56:32 -07:00
6080d1a569
Issues #3132 , #3133 : Semconv for hardware metrics, network metrics and attributes ( #3344 )
...
Fixes #3132 , #3133
## Changes
In semantic conventions for hardware metrics:
* Updated network adapter description
* Changed `type` to `hw.error.type` for the `hw.errors` metric
2023-04-11 17:18:48 -06:00
26b305941d
Update the description of the `host.image` attribute ( #3194 )
2023-04-11 18:29:16 +02:00
07721f339c
Add back refs to cloud.resource_id lost in FaaS renaming. ( #3329 )
...
These places were removed when #3188 in its original form removed
faas.id without replacement and weren't added back after changing it to
introduce cloud.resource_id instead.
Editorial change, no CHANGELOG or issue.
2023-04-11 07:13:14 -06:00
df32f2ef4c
Clarify parameters for emtting a log record ( #3354 )
...
Supersedes #3350
Clarifies the parameters for emitting a log record.
Context was particularly confusing. Context is not a property of the
`LogRecord` data model. Cleans up section of bridge API spec that seems
to suggest that Context is a field of `LogRecord`. Also, clarifies that
Context can be associated with an emitted LogRecord. We have similar
language in the trace API that leaves room for languages to achieve this
in an idiomatic way. See
d25734a47e/specification/trace/api.md
2023-04-08 10:42:13 -05:00
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
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
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
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
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
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
b45d32f1ed
Add cloud spanner and mssql compact to db specifications ( #3105 )
2023-01-23 16:18:51 -06:00
ebcf353c33
Remove rogue bracket ( #3108 )
2023-01-17 09:54:55 -08:00
708df51809
Add ClickHouse in the database group ( #3011 )
2023-01-03 19:40:09 -06:00
4de43114a4
Suggest column # as an extra source code attribute ( #3029 )
2023-01-02 18:01:32 -06:00
a7ede6fbfa
Refactor messaging attributes and specify per-message attributes ( #2957 )
2022-12-22 17:04:53 -06:00
41f5b5508b
Clarify common HTTP attributes apply to both clients and servers ( #3044 )
2022-12-16 21:48:49 +01:00
90a6aeee14
[editorial] Metrics hardware sem. conv. front matter ( #3045 )
2022-12-16 13:17:23 -06:00
656644592a
[resource] add openshift platform to all supported cloud providers ( #2985 )
2022-12-06 16:52:30 +01:00
0204860d46
Update semconv for hardware metrics to use `direction` attributes ( #2942 )
2022-12-06 00:17:54 +01:00
0adf032cf1
Add feature flagging semantic conventions ( #2529 )
2022-12-01 12:13:48 -08:00
e37e300610
Add `messaging.kafka.message.offset` attribute ( #2982 )
2022-12-01 19:21:38 +01:00
84bc1e50fc
Fix net peer name IP example address ( #2995 )
2022-12-01 18:38:24 +01:00
6f0cadac7e
List the machine-id as potential source for a unique host.id ( #2978 )
2022-11-29 10:06:04 -08:00
fa6cef115c
Rename grpc metadata attribute names to reflect that they are grpc-specific ( #2981 )
2022-11-22 15:53:34 -08:00
b901d9dd76
add ibm cloud as a cloud provider ( #2965 )
2022-11-21 10:31:32 -08:00
f517f6b17b
Make http.status_code an int ( #2943 )
2022-11-17 13:33:59 -08:00
fce78ebfc5
Move Prometheus/OpenMetrics compatibility to its own file ( #2952 )
2022-11-17 13:22:10 -08:00
43804f56d2
Track JVM gc time in histogram ( #2903 )
2022-11-15 12:53:05 -08:00
0644776443
Split out Event API from Log API ( #2941 )
...
Resolves #2917 .
Depends on #2940 .
2022-11-14 18:07:56 -05:00
acb0d5db18
Move event.domain from InstrumentationScope to LogRecord ( #2940 )
...
Resolves #2939 .
2022-11-14 10:34:49 -05:00
b334f6b070
Clarification on what an Event is, and what the event.domain and event.name attributes represent ( #2848 )
...
* Remove language around uniqueness of event names within a domain
This came up in
https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/14474
where it was highlighted that just `name` is not sufficient to provide
for uniqueness of a Kubernetes Event.
The attribute `event.domain` is only meant to be a logical separation
across different event systems, so it allows for similar looking names
in different domains but with a completely different purpose. However,
within each domain we don't have to have any uniqueness constraints on
the `name` and leave it to whatever is idiomatic to the particular event
system the domain represents.
2022-11-09 14:01:28 -05:00
07ef735d2f
s/cpu/CPU ( #2931 )
...
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
2022-11-09 17:10:44 +01:00
f9a0472bb3
Add metric for jvm memory usage after gc ( #2901 )
2022-11-08 14:02:14 -08:00
63343b5fbb
Add more semantic convention attributes for Apache RocketMQ ( #2881 )
2022-11-08 16:48:17 +01:00
9f4bd4c0b6
Add gRPC request/response metadata as span attributes ( #2874 )
2022-10-20 13:32:31 -07:00
ace15c86b6
Fix typo in http semantic conventions ( #2896 )
2022-10-20 12:36:13 -07:00
a2e925d05f
Add `process.paging.faults` metric to semantic conventions ( #2827 )
2022-10-18 15:16:37 -07:00
34093ed204
Clarify the HTTP client `http.retry_count` spec ( #2743 )
2022-10-18 10:46:16 -07:00
7c53a4e646
add daemon attribute to jvm threads metric ( #2828 )
2022-10-06 23:46:02 -07:00
7cc726cb55
Link to RPC in Metrics Semantic Conventions ( #2831 )
2022-10-06 10:27:20 -07:00
99e7370387
Changes to messaging.kafka.max.lag ( #2837 )
2022-10-04 17:02:59 -07:00
bfb8bd7a27
Fix inconsistent metric usage of http.target ( #2818 )
2022-10-03 11:16:31 -07:00
e2856b8feb
Make messaging context propagation requirements explicit ( #2750 )
2022-09-30 09:05:54 -07:00
3ce713d52b
[Logs] Add semantic conventions for writing exceptions ( #2819 )
2022-09-29 21:38:40 -07:00
ad82c3556e
Add additional process metrics to the metrics semantic conventions ( #2706 )
...
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
2022-09-21 19:24:12 +02:00
c359bd372c
Add mobile and language semconv for browser resource ( #2761 )
2022-09-20 21:19:02 +02:00
8db8131112
Fix nits: incorrect unit for CPU utilization ( #2807 )
2022-09-16 10:49:58 -07:00
090f94ceb0
fix typo ( #2803 )
2022-09-15 08:32:40 -07:00
c01963c823
Revert #2617 , #2675 , #2688 : "add metrics to replace metrics with `direction`" ( #2748 )
...
Please review this carefully. It is not an automatic reverting, I had to fix merge conflicts manually and may have made mistakes, so a thorough review is needed.
Changes:
- This reverts https://github.com/open-telemetry/opentelemetry-specification/pull/2617 . We are reverting it until we are certain how to resolve issue #2726
- Also reverts the corresponding schema file changes done in https://github.com/open-telemetry/opentelemetry-specification/pull/2688
- Also reverts https://github.com/open-telemetry/opentelemetry-specification/pull/2675
~Note that this does not revert https://github.com/open-telemetry/opentelemetry-specification/pull/2675 which I believe to still be valid. If you think otherwise please speak.~ [UPDATE: discussed in Spec SIG and decided to revert 2675 too].
Contributes to https://github.com/open-telemetry/opentelemetry-specification/issues/2726
2022-09-02 10:00:11 -04:00
2503e776b0
Events and logs api ( #2676 )
...
This PR is a follow up to the OTEP [Events and Logs API](https://github.com/open-telemetry/oteps/blob/main/text/0202-events-and-logs-api.md ). It describes the specification for an Events and Logs API and also defines semantic conventions for attributes to be used for Events that are represented using Log Records.
For non-trivial changes, follow the [change proposal
process](../CONTRIBUTING.md#proposing-a-change) and link to the related issue(s)
and/or [OTEP(s)](https://github.com/open-telemetry/oteps ), update the
[`CHANGELOG.md`](../CHANGELOG.md), and also be sure to update
[`spec-compliance-matrix.md`](../spec-compliance-matrix.md) if necessary.
Related [OTEP(s)](https://github.com/open-telemetry/oteps ) #
[Events and Logs API](https://github.com/open-telemetry/oteps/blob/main/text/0202-events-and-logs-api.md )
2022-08-31 14:05:37 -04:00
Johannes Tax