Requests Module
The SDK should auto-instrument all outgoing HTTP requests, regardless of the library that issues the requests. Each outgoing request should result in a span. The Requests module is technology agnostic, it only cares about span data properties.
Attribute | Description | Notes |
---|---|---|
op | Always "http.client" | Required |
description | A string including the HTTP request method, and the full URL. e.g., "GET https://example.com/data.json?filter=all" | Required 1 |
data | A key-value mapping of span attributes. (e.g., {"http.query": "filter=all", "server.address": "prod-2.example.com"} ) | Required for full experience. See Span Data for details |
None of the span data fields are hard requirements, but attaching as many of them as possible is a more future-proof approach. We recommend that the SDK adds every attribute listed in the HTTP Span Data Conventions. The minimal requirements are:
server.address
must be set to allow correct domain grouping for descriptions containing relative URLs. e.g., the description"GET /data.json"
is missing a domain. In this case,server.address
must be set. If the span description contains the full URL,span.server
can be omittedhttp.response.status_code
must be set to enable response code breakdowns
Consider a website called "App Ex", running on app.example.com
. This JavaScript code that issues an HTTP request from the browser:
fetch("/data.json?user=1");
Should result in the following span, assuming the request was successful:
{
"description": "GET /data.json?user=1",
"op": "http.client",
"data": {
"http.query": "user=1",
"http.request_method": "GET",
"http.response.status_code": 200,
"http.fragment": "",
"server.address": "app.example.com",
"server.port": 8080,
... other span properties
}
}
The HTTP method must be one of the known HTTP request methods ↩
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").