General

Status: Experimental

The conventions described in this section are HTTP specific. When HTTP operations occur, metric events about those operations will be generated and reported to provide insight into the operations. By adding HTTP attributes to metric events it allows for finely tuned filtering.

Disclaimer: These are initial HTTP metric instruments and attributes but more may be added in the future.

Metric Instruments

The following metric instruments MUST be used to describe HTTP operations. They MUST be of the specified type and units.

HTTP Server

Below is a table of HTTP server metric instruments.

NameInstrumentUnitUnit (UCUM)Description
http.server.durationHistogrammillisecondsmsmeasures the duration of the inbound HTTP request
http.server.active_requestsAsynchronous UpDownCounterrequests{requests}measures the number of concurrent HTTP requests that are currently in-flight

HTTP Client

Below is a table of HTTP client metric instruments.

NameInstrumentUnitUnit (UCUM)Description
http.client.durationHistogrammillisecondsmsmeasures the duration of the outbound HTTP request

Attributes

Below is a table of the attributes that SHOULD be included on duration metric events and whether they should be on server, client, or both types of HTTP metric events:

NameTypeRecommendedNotes and examples
http.methodclient & serverYesThe HTTP request method. E.g. "GET"
http.hostclient & serversee attribute alternativesThe value of the HTTP host header. When the header is empty or not present, this attribute should be the same.
http.schemeclient & serversee attribute alternativesThe URI scheme identifying the used protocol in lowercase: "http" or "https"
http.status_codeclient & serverOptionalHTTP response status code. E.g. 200 (String)
http.flavorclient & serverOptionalKind of HTTP protocol used: "1.0", "1.1", "2", "SPDY" or "QUIC".
net.peer.nameclientsee [1] in attribute alternativesSee general network connection attributes
net.peer.portclientsee [1] in attribute alternativesSee general network connection attributes
net.peer.ipclientsee [1] in attribute alternativesSee general network connection attributes
http.server_nameserversee [2] in attribute alternativesThe primary server name of the matched virtual host. This should be obtained via configuration. If no such configuration can be obtained, this attribute MUST NOT be set ( net.host.name should be used instead).
net.host.nameserversee [2] in attribute alternativesSee general network connection attributes
net.host.portserversee [2] in attribute alternativesSee general network connection attributes

The following attributes SHOULD be included in the http.server.active_requests observation:

NameRecommendedNotes and examples
http.methodYesThe HTTP request method. E.g. "GET"
http.hostsee attribute alternativesThe value of the HTTP host header. When the header is empty or not present, this attribute should be the same
http.schemesee attribute alternativesThe URI scheme identifying the used protocol in lowercase: "http" or "https"
http.flavorOptionalKind of HTTP protocol used: "1.0", "1.1", "2", "SPDY" or "QUIC"
http.server_namesee [2] in attribute alternativesThe primary server name of the matched virtual host. This should be obtained via configuration. If no such configuration can be obtained, this attribute MUST NOT be set ( net.host.name should be used instead).

Parameterized attributes

To avoid high cardinality the following attributes SHOULD substitute any parameters when added as attributes to http metric events as described below:

Attribute nameTypeRecommendedNotes and examples
http.urlclient & serversee attribute alternativesThe originally requested URL
http.targetclient & serversee attribute alternativesThe full request target as passed in a HTTP request line or equivalent, e.g. "/path/{id}/?q={}".

Many REST APIs encode parameters into the URI path, e.g. /api/users/123 where 123 is a user id, which creates high cardinality value space not suitable for attributes on metric events. 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 recommended as the low cardinality attribute values. However, the same approach usually does not work for HTTP client attributes, especially when instrumentation is provided by a lower-level middleware that is not aware of the specifics of how the URIs are formed. Therefore, HTTP client attributes SHOULD be using conservative, low cardinality names formed from the available parameters of an HTTP request, such as "HTTP {METHOD_NAME}". These attributes MUST NOT default to using URI path.

Attribute alternatives

[1] For client metric attributes, one of the following sets of attributes is RECOMMENDED (in order of usual preference unless for a particular web client/framework it is known that some other set is preferable for some reason; all strings must be non-empty):

  • http.url
  • http.scheme, http.host, http.target
  • http.scheme, net.peer.name, 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). 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):

  • http.scheme, http.host, http.target
  • http.scheme, http.server_name, net.host.port, http.target
  • http.scheme, net.host.name, net.host.port, http.target
  • http.url