httpx: `http.client.duration` has no `net.peer.name` in the default semconv mode
Maintainers usually reply within 2 days
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 86/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- observability
Research direction
Start in instrumentation/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/init.py at _apply_request_client_attributes_to_span and _apply_response_client_attributes_to_metrics, then compare the corresponding setters in the requests instrumentation. Update the default-mode metric attributes so the httpx data point includes the expected host, peer, port, and protocol values, and adjust tests/test_httpx_integration.py::test_basic_metrics to verify the completed attribute set.
Written by the indexing model from the issue text.
Description
Describe your environment
OS: macOS
Python version: 3.10.18
Package version: opentelemetry-instrumentation-httpx 0.65b0, opentelemetry-sdk 1.44.0, httpx 0.28.1
What happened?
With OTEL_SEMCONV_STABILITY_OPT_IN unset, http.client.duration from the httpx instrumentation has only http.method, http.scheme, and http.status_code. There is no net.peer.name, http.host, net.peer.port, or http.flavor. net.peer.name is Required on this metric.
The host and port metric writes are inside if _report_new(semconv): in _apply_request_client_attributes_to_span. The protocol version write is inside if http_version and _report_new(semconv): in _apply_response_client_attributes_to_metrics. _report_new is False in the default mode, so none of these writes run.
The requests instrumentation calls the same host setters outside the mode check, so its http.client.duration has net.peer.name in the default mode.
Steps to Reproduce
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
import httpx
import requests
from opentelemetry import metrics
from opentelemetry.instrumentation.httpx import HTTPXClientInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import InMemoryMetricReader
class Handler(BaseHTTPRequestHandler):
protocol_version = "HTTP/1.1"
def do_GET(self):
self.send_response(200)
self.send_header("Content-Length", "2")
self.end_headers()
self.wfile.write(b"ok")
def log_message(self, *args):
pass
server = HTTPServer(("127.0.0.1", 0), Handler)
threading.Thread(target=server.serve_forever, daemon=True).start()
url = f"http://localhost:{server.server_port}/"
reader = InMemoryMetricReader()
metrics.set_meter_provider(MeterProvider(metric_readers=[reader]))
HTTPXClientInstrumentor().instrument()
RequestsInstrumentor().instrument()
httpx.get(url)
requests.get(url, timeout=5)
for resource_metrics in reader.get_metrics_data().resource_metrics:
for scope_metrics in resource_metrics.scope_metrics:
for metric in scope_metrics.metrics:
for point in metric.data.data_points:
print(scope_metrics.scope.name, metric.name, dict(sorted(point.attributes.items())))
Expected Result
The httpx data point has the same keys as the requests one:
opentelemetry.instrumentation.httpx http.client.duration {'http.flavor': '1.1', 'http.host': 'localhost', 'http.method': 'GET', 'http.scheme': 'http', 'http.status_code': 200, 'net.peer.name': 'localhost', 'net.peer.port': 50636}
Actual Result
opentelemetry.instrumentation.httpx http.client.duration {'http.method': 'GET', 'http.scheme': 'http', 'http.status_code': 200}
opentelemetry.instrumentation.requests http.client.duration {'http.flavor': '1.1', 'http.host': 'localhost', 'http.method': 'GET', 'http.scheme': 'http', 'http.status_code': 200, 'net.peer.name': 'localhost', 'net.peer.port': 50636}
With OTEL_SEMCONV_STABILITY_OPT_IN=http/dup, the httpx http.client.duration point has all seven keys.
Additional context
The existing test_basic_metrics asserts a set with only three keys. That test passes today but probably shouldn't?
Would you like to implement a fix?
Yes
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 1.1k
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 30
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-telemetry/opentelemetry-python-contrib
-
jinja2: tracing ignores suppress_instrumentation()Possibly taken @RichardoMrMu claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
open-telemetry/opentelemetry-python-contrib#5167 · 2 comments ·
Maintainers usually reply within 2 days
-
opentelemetry-instrumentation-tornado: server metrics recorded twice when a handler raises, http.server.active_requests goes negativePossibly taken @sivakumar-mahalingam claimed this 24 days ago. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
open-telemetry/opentelemetry-python-contrib#5113 · 2 comments · 2 reactions ·
Maintainers usually reply within 2 days
-
Logging: don't include injected trace context attributes in emitted recordsPossibly taken @RichardoMrMu claimed this 33 days ago. Openfeature-request
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-telemetry/opentelemetry-python-contrib#5071 ·
Maintainers usually reply within 2 days
-
`LoggingInstrumentor` `log_hook` only runs when there is an active spanPossibly taken @git-jxj claimed this 34 days ago. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
open-telemetry/opentelemetry-python-contrib#5069 ·
Maintainers usually reply within 2 days
-
[grpc] AIO server spans record uncaught exceptions twicePossibly taken @somuai claimed this 33 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
open-telemetry/opentelemetry-python-contrib#5068 · 1 comment ·
Maintainers usually reply within 2 days
All issues in open-telemetry/opentelemetry-python-contrib
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
CLIMADA-project/climada_python#1337 ·
Maintainers usually reply within 3 days
-
tail without reverseOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
8go/matrix-commander#233 ·
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
-
documentation enhancement priority:high size:M
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backendPossibly taken @debesh-biswas claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100