@lonewolf3739 @aabmass Thanks for supporting the community to make better software
Oh I see someone added it 21 days ago! w00t! https://github.com/open-telemetry/opentelemetry-python/blame/5eb0533c66356401214ccc6f3cbdc01d7e1961d6/opentelemetry-sdk/src/opentelemetry/sdk/trace/propagation/jaeger_propagator.py
(is it possible to tag a release and push this to pypi :pray: )
Unsupported instrument/aggregator combo, types ValueRecorder and MinMaxSumCountAggregator, ignoring it
Is there a way for me to specify an aggregator? Here's how I create the valuerecorder:
response_latency = meter.create_valuerecorder(
name="response_latency_python",
description="response latency",
unit="ms",
value_type=int,
)
10 replies
hi guys again. Did you try this in the documentation?
https://opentelemetry-python.readthedocs.io/en/stable/api/trace.html
It seems that is outdated
As the source code does not have the keywork ‘parent’
https://github.com/open-telemetry/opentelemetry-python/blob/master/opentelemetry-sdk/src/opentelemetry/sdk/trace/__init__.py#L768
tracer.start_span(“child”, parent=parent)https://opentelemetry-python.readthedocs.io/en/stable/api/trace.html
It seems that is outdated
As the source code does not have the keywork ‘parent’
https://github.com/open-telemetry/opentelemetry-python/blob/master/opentelemetry-sdk/src/opentelemetry/sdk/trace/__init__.py#L768
Also in the docs is written:
By default the current span will be used as parent, but an explicit parent can also be specified, either a Span or a opentelemetry.trace.SpanContext. If the specified value is None, the created span will be a root span.
I tried it, but it did not work
I tried to initialize a Context class instead of using span.get_current_context(), and it did not give an error, but the parent_id is null
I was reading the source code and I found the solution, I can use trace_id, span_id, …etc and pass them to other services and from there I can use to start a new span and use the Context as parent as follows:
# Suppose that this is in Service - 1
with tracer.start_as_current_span('service 1') as span:
span.set_attribute('module', str(inspect.getmodule(f)))
span.set_attribute('function_name', f.__name__)
span.set_attribute('function_args', f'args = {str(args)}, kwargs = {str(kwargs)}')
c: SpanContext = span.get_span_context()
# Suppose that this is in service - 2
# trace_id, span_id, is_remote, trace_flags, and trace_state need to be sent to the service 2
ctx = trace.set_span_in_context(
trace.DefaultSpan(
trace.SpanContext(
# trace an span ids are encoded in hex, so must be converted
trace_id=c.trace_id,
span_id=c.span_id,
is_remote=c.is_remote,
trace_flags=c.trace_flags,
trace_state=c.trace_state,
)
)
)
with tracer.start_span('service 2', context=ctx) as span:
span.set_attribute('module', str(inspect.getmodule(f)))
span.set_attribute('function_name', f.__name__)
span.set_attribute('my new stuff is ok, function_args',
f'args = {str(args)}, kwargs = {str(kwargs)}')
It should be looked into once to make those change live.
You probably saw this, but there is grpc insturmentation https://opentelemetry-python.readthedocs.io/en/stable/instrumentation/grpc/grpc.html
2 replies
Is anyone with merge rights back from holidays? Would be great to have this merged. Have a couple of other PRs that build on top of this with the new lint rules. open-telemetry/opentelemetry-python-contrib#248
Generally, maintenance of components is the responsibility of contributors who authored them. If the original author or some other contributor does not maintain the component it may be excluded from the default build. The component will be excluded if it causes build problems, has failing tests or otherwise causes problems to the rest of the repository and the rest of contributors.
@codeboten @lzchen @jaitaiwan_gitlab @aabmass ^
Is there a schedule for the next beta release? The jaeger trace parser would be nice to have from a tagged version on pypi. It was merged on 8 Dec (open-telemetry/opentelemetry-python#1219) I also see that the code is being moved: open-telemetry/opentelemetry-python#1525
2 replies
need one more review on this one: open-telemetry/opentelemetry-python#1525
and would love some reviews on this: open-telemetry/opentelemetry-python#1482
and would love some reviews on this: open-telemetry/opentelemetry-python#1482
Would love to have another appoval on this: open-telemetry/opentelemetry-python-contrib#254
Also, I know everyone is focusing on getting 1.0 out but this is pretty important as it makes django (which is probably the most popular python framework) projects crash: open-telemetry/opentelemetry-python-contrib#246
5 replies
Hi there. I'm docker-composing my app with the jaegertracing all-in-one image. I have the application up and running. If I use this minimum example on my sys, I see traces. If I do basically the same thing in the application, I don't. Is there something I should know about with regard to jaeger and communicating between containers?
haven't had an issue like this before. all other composed services a-ok, like db and messaging sys
so the problem is feeling fairly jaeger specific
Updated both PRs and took care of latest round of comments. Thanks everyone. Each PR has one stamp. Would be great to get another and have these as part of the next release.
open-telemetry/opentelemetry-python-contrib#246
open-telemetry/opentelemetry-python-contrib#254
open-telemetry/opentelemetry-python-contrib#246
open-telemetry/opentelemetry-python-contrib#254
6 replies
Hello, i'm trying to work out why my traces for 404s (well, all 400-level responses so far) are looking like 200s in AWS X-Ray using OpenTelemetry for an ASGI (FastAPI) application. Here's a raw trace from the X-Ray console, for a 404:
https://gist.github.com/smcoll/b28d39bc83533c38b45a9f1d78dbdf88
Some notables:
- root span seems to inherit the fault/error values from the subsegment for "http.response.body" rather than "http.response.start"
content_lengthshows as 0 although the actual value in the header is 22, for a JSON response- i'm using auto-instrumentation:
opentelemetry-instrument --exporter otlp_span --ids-generator aws_xray uvicorn my.main:app --port 80 --host 0.0.0.0 --access-log --no-use-colorswith opentelemetry-instrumentation-fastapi 0.16b1 - my sanity checks seemed to show that the raw traces for a FastAPI request/response cycle show
status.status_codeas "ERROR" for the "http.response.start" span and "UNSET" for the other two. So it seems that whatever is stitching the spans together is deciding which status to apply? Where in the toolchain does that happen?
3 replies
Hello,
I was working on issue open-telemetry/opentelemetry-python#1108
Before I implement this, thought of clarifying some points from spec
Following from the spec:
https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/protocol/otlp.md#concurrent-requests
The maximum achievable throughput is max_concurrent_requests * >max_request_size / (network_latency +
server_response_time). For example if the request can contain at most 100 spans, network roundtrip latency is 200ms and server response time is 300 ms, then the maximum achievable throughput with one concurrent request is 100 spans / (200ms+300ms) or 200 spans per second. It is easy to see that in high latency networks or when the server response time is high to achieve good throughput the requests need to be very big or a lot concurrent requests must be done.
I had some questions regarding the spec before i start the implementation:
- number of spans in a single request? Do we have any number that we are targeting?
- Say for eg out of 5 concurrent request, one did not get acknowledgment, the export function should "FAILURE" ?
- if client configured to "NOT WAIT FOR ACK" during shutdown export function should return "SUCCESS" ?
Recently
Resource.merge is updated to have similar behaviour like dict.update. Created a PR open-telemetry/opentelemetry-python#1544 to update that change.