Implement tracing for pyroscope components #2185
Conversation
|
|
| @@ -228,6 +241,9 @@ func (t *scrapeLoop) scrape() { | |||
| ) | |||
| defer cancel() | |||
|
|
|||
| scrapeCtx, span := t.tracer.Tracer("").Start(scrapeCtx, "scrape") | |||
There was a problem hiding this comment.
Naming spans is the most difficult thing. This is the only span I create explicitly in this PR, so there's not much naming convention to do, but it would be good to have one.
|
New spans:
|
|
I'm seeing segfaults during reload related to tracing, will need to investigate |
There was a problem hiding this comment.
Hi, thank you for the PR! I do wonder to what extent traces will be useful here. Tracing is mostly handy when there is a chain of network calls - one service calling another, calling another, calling another, etc. But with the profiling calls there are only two services involved in every call. The only use case I can think of is spanmetrics generation from the traces?
I implemented this to debug the root cause of the issue that eventually resulted in #2201. It was very useful to have traces to see what is actually happening. Btw there are more services involved - the client, alloy, traefik, pyroscope-distributor, pyroscope-ingester. |
|
Hi @madaraszg-tulip, Thank you for your contribution and for taking the time to enhance observability in Alloy. My two cents: while the instrumentation could be valuable, I believe we should align with Alloy's observability choices for now. If they decide to adopt Thanks again for your contribution! |
|
Closing for now, might revisit in the future |
PR Description
Implement tracing for the
pyroscope.scrape,pyroscope.receive_httpandpyroscope.writecomponents.Spans are created for http server and http client calls in these components.
PR Checklist