open-telemetry
/
semantic-conventions
mirror of https://github.com/open-telemetry/semantic-conventions.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Pin markdownlint-cli version and apply fixes (#2320) 

* Pin markdownlint-cli version

* Apply markdownlint fixes
This commit is contained in:
Armin Ruech 2022-02-07 19:24:33 +01:00 committed by GitHub
parent d62ad18c75
commit 8c9de82151
4 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Makefile
View File

@ -54,7 +54,7 @@ markdown-toc: $(MARKDOWN_TOC)
done done
$(MARKDOWN_LINT): $(MARKDOWN_LINT):
npm install markdownlint-cli npm install markdownlint-cli@0.31.0
.PHONY: markdownlint .PHONY: markdownlint
markdownlint: $(MARKDOWN_LINT) markdownlint: $(MARKDOWN_LINT)

2
specification/metrics/semantic_conventions/http-metrics.md
View File

@ -96,7 +96,7 @@ path.
* `http.scheme`, `net.peer.ip`, `net.peer.port`, `http.target` * `http.scheme`, `net.peer.ip`, `net.peer.port`, `http.target`
**[2]** For server metric attributes, `http.url` is usually not readily available on the server side but would have to be assembled in a cumbersome and sometimes lossy process from other information (see e.g. <https://github.com/open-telemetry/opentelemetry-python/pull/148>). **[2]** For server metric attributes, `http.url` is usually not readily available on the server side but would have to be assembled in a cumbersome and sometimes lossy process from other information (see e.g. <https://github.com/open-telemetry/opentelemetry-python/pull/148>).
It is thus preferred to supply the raw data that *is* available. It is thus preferred to supply the raw data that _is_ available.
Namely, one of the following sets is RECOMMENDED (in order of usual preference unless for a particular web server/framework it is known that some other set is preferable for some reason; all strings must be non-empty): Namely, one of the following sets is RECOMMENDED (in order of usual preference unless for a particular web server/framework it is known that some other set is preferable for some reason; all strings must be non-empty):
* `http.scheme`, `http.host`, `http.target` * `http.scheme`, `http.host`, `http.target`

2
specification/trace/semantic_conventions/http.md
View File

@ -28,7 +28,7 @@ HTTP spans MUST follow the overall [guidelines for span names](../api.md#span).
Many REST APIs encode parameters into URI path, e.g. `/api/users/123` where `123` Many REST APIs encode parameters into URI path, e.g. `/api/users/123` where `123`
is a user id, which creates high cardinality value space not suitable for span is a user id, which creates high cardinality value space not suitable for span
names. In case of HTTP servers, these endpoints are often mapped by the server names. In case of HTTP servers, these endpoints are often mapped by the server
frameworks to more concise _HTTP routes_, e.g. `/api/users/{user_id}`, which are frameworks to more concise *HTTP routes*, e.g. `/api/users/{user_id}`, which are
recommended as the low cardinality span names. However, the same approach usually recommended as the low cardinality span names. However, the same approach usually
does not work for HTTP client spans, especially when instrumentation is provided does not work for HTTP client spans, especially when instrumentation is provided
by a lower-level middleware that is not aware of the specifics of how the URIs by a lower-level middleware that is not aware of the specifics of how the URIs

4
specification/trace/semantic_conventions/messaging.md
View File

@ -178,7 +178,7 @@ For message consumers, the following additional attributes may be set:
| `process` | process | | `process` | process |
<!-- endsemconv --> <!-- endsemconv -->
The _receive_ span is be used to track the time used for receiving the message(s), whereas the _process_ span(s) track the time for processing the message(s). The *receive* span is be used to track the time used for receiving the message(s), whereas the *process* span(s) track the time for processing the message(s).
Note that one or multiple Spans with `messaging.operation` = `process` may often be the children of a Span with `messaging.operation` = `receive`. Note that one or multiple Spans with `messaging.operation` = `process` may often be the children of a Span with `messaging.operation` = `receive`.
The distinction between receiving and processing of messages is not always of particular interest or sometimes hidden away in a framework (see the [Message consumption](#message-consumption) section above) and therefore the attribute can be left out. The distinction between receiving and processing of messages is not always of particular interest or sometimes hidden away in a framework (see the [Message consumption](#message-consumption) section above) and therefore the attribute can be left out.
For batch receiving and processing (see the [Batch receiving](#batch-receiving) and [Batch processing](#batch-processing) examples below) in particular, the attribute SHOULD be set. For batch receiving and processing (see the [Batch receiving](#batch-receiving) and [Batch processing](#batch-processing) examples below) in particular, the attribute SHOULD be set.
@ -189,7 +189,7 @@ Instead span kind should be set to either `CONSUMER` or `SERVER` according to th
#### RabbitMQ #### RabbitMQ
In RabbitMQ, the destination is defined by an _exchange_ and a _routing key_. In RabbitMQ, the destination is defined by an *exchange* and a *routing key*.
`messaging.destination` MUST be set to the name of the exchange. This will be an empty string if the default exchange is used. `messaging.destination` MUST be set to the name of the exchange. This will be an empty string if the default exchange is used.
<!-- semconv messaging.rabbitmq --> <!-- semconv messaging.rabbitmq -->