Snippets

[jack-berg]

First take on #393.

Details:

• Introduces a new /snippets directly with files named <JsonSchemaType>_<snake_case_snippet_description>.yaml
• Each file is a fully valid OpenTelemetryConfiguration type, but is meant to emphasize a particular snippet of a specific type, indicated by the <JsonSchemaType> in the file naming convention
• A new task make validate-snippets validates each snippet file against OpenTelemetryConfiguration, and the snippet being emphasized (as indicated by # SNIPPET_START) against its corresponding JSON schema type
• Snippets may include comments which describe a very narrow use case being demonstrated.
• The make generate-markdown task outputs snippets in schema-docs.md. For example, I've added a snippet demonstrating how to use a view to change the default histogram bucket boundaries for a specific instrument via a view. See screenshot below, or generated markdown here:

If we like this direction, we can open followup PRs which chip away at kitchen-sink.yaml, and delete it.

[breedx-splk]

Thanks @simplekjl. Would you mind opening another separate issue about the multi-auth-token multi-threaded thing? I think it would be good to track that separately and for us to better understand this use case. Thanks!

As far as the coroutine context-switching goes, I don't think we have anything that does this automatically. Did you try passing the context manually? Would you be able to share a more complete but minimal example that demonstrates your problem?

It's interesting to think about eventually doing some build-time bytecode manipulation to make context tracking, especially for threads/coroutines, simpler for developers.

[LikeTheSalad]

Seems related to https://github.com/open-telemetry/opentelemetry-android/issues/239

[breedx-splk]

Yeah, we should decide which issue we want to keep.

[simplekjl]

Hi @breedx-splk @LikeTheSalad, I think it’s the same issue. I’ve tried both the automated approach and also passing the Otel context to my coroutines, but neither is working at the moment—the parent span doesn’t reflect some of the traces.

For more context: my application has two internal clients, one authorized and the other not. I need to communicate with both systems for different purposes during operations. I’ve noticed that only the calls made through one client go into the span in context. The other client’s traces are recorded, but they appear outside the span.

[marandaneto]

probably would need something similar to https://github.com/getsentry/sentry-java/blob/main/sentry-kotlin-extensions/src/main/java/io/sentry/kotlin/SentryContext.kt so you can copy-pass the context across coroutines docs https://docs.sentry.io/platforms/java/enriching-events/scopes/#kotlin-coroutines

[LikeTheSalad]

Hi @simplekjl

We discussed this issue in the previous SIG meeting and we found out that it's not clear what could be causing it, based on the description alone. So we're going to need more info to provide better support.

Based on what you mentioned in the description, you're making HTTP calls using OkHttp and you'd like to have spans automatically created for them that should come with any previously created trace context (if any). In other words, you'd like to do something like the following:

fun someFunction() {
   val span = tracer.spanBuilder("Parent span").startSpan()
   val scope = span.makeCurrent()
   
   coroutineScope.launch(ioDispatcher + Context.current().asContextElement()) {
     okhttpClient.newCall(/*...*/).execute()
   }

   scope.close()
   span.end()
}

And as a result, you're looking to get the following spans:

Parent span
├─ HTTP span // OkHttp span as child of "Parent span"

But instead you're getting 2 independent spans. Is that correct?

Please confirm if that's the issue, otherwise let us know more details of what you're trying to achieve and provide some more code that covers your OTel Android setup and span creation logic. If possible, a demo project where the issue is reproduced could help a lot as well.