Use OpenTelemetry Semantic Conventions#1255
Conversation
76cf10c to
b1e5558
Compare
1fb5ce0 to
c52e9fb
Compare
| object Otel { | ||
|
|
||
| // TODO the current snapshot used does not have the new `From` instance, | ||
| // and I cannot update the otel4s dependency since skunk depends on SN 0.5 |
There was a problem hiding this comment.
Is this still true with the snapshot we just upgraded to last week?
There was a problem hiding this comment.
I rebased on main yesterday and it was still the case. Maybe we need another snapshot @iRevive?
There was a problem hiding this comment.
Here are updated snapshots:
lazy val otel4sVersion = "0.16-83b6f7b-SNAPSHOT"
lazy val otel4sSdkVersion = "0.17-c767f1d-SNAPSHOT"|
|
||
| trait FTest extends CatsEffectSuite with FTestPlatform { | ||
|
|
||
| implicit val meter: Meter[IO] = Meter.noop |
There was a problem hiding this comment.
Can we tie this in with the other test machinery (withinSpan, tracedTest, etc)
There was a problem hiding this comment.
I didn't have time to push this change, I will do it in a follow-up PR, then.
| * @param parseCacheSize size of the pool-level cache for parsing statements; defaults to 2048 | ||
| */ | ||
| final class Builder[F[_]: Temporal: Network: Console] private ( | ||
| final class Builder[F[_]: Temporal: Meter: Network: Console] private ( |
There was a problem hiding this comment.
Curious if we should just take a Tracer here too and drop support for explicitly passing a Tracer? Or alternatively, should we support explicitly passing a Meter using a similar pattern? Explicit passing was added back when tracing was done via Natchez: #650
There was a problem hiding this comment.
I think the implicit Tracer is the more idiomatic way of doing it in otel4s. This could be done in a follow-up PR?
There was a problem hiding this comment.
It would be nice to use MeterProvider so you can explicitly define and control the instrumentation scope. Then, you can create a Meter inside the pooled / single:
val meter: F[Meter] = MeterProvider[F].tracer("skunk").withVersion(BuildInfo.version).getOpenTelemetry generally recommends that libraries own their instrumentation scopes.
We follow a similar approach in http4s-otel4s-middleware or fs2-grpc-otel4s.
If possible, I would do the same with Tracer.
If users don't need tracing or metering capabilities, they can use given MeterProvider[F] = MeterProvider.noop.
There was a problem hiding this comment.
Happy to do that in a follow up PR. Same for TraceProvider, right?
There was a problem hiding this comment.
If that works for you, We can integrate the metrics and then I can do a cleanup PR with TracerProvider and MeterProvider, and get rid of the explicit Tracer API. TO avoid blowing up the size of this PR. I'd like also to follow-up with metrics for the pool, as per the semantic convention.
This is an attempt at #1127 and an opportunity to align the existing traces with the ones defined in semantic conventions.
The current PR:
PostgresErrorExceptionThere currently are some limitations with this implementation:
queryorexecute)db.client.response.returned_rowsor connection pool metrics are not added)Histogramhas to be propagated, I think it is not an issue, correct me if I'm wrong.