Adding gormtrace plugin

[rizkybiz]

Wanted to add a plugin to ease the implementation of tracing around GORM ORM.

[rghetia]

@rizkybiz thanks for writing the gorm plugin.

Given that we have more plugins like this in coming weeks/months, I am thinking of creating a contrib repo for such plugins.

[rizkybiz]

@rghetia No problem. I think a contrib repo is a great idea, it will help keep the API/SDK more clean/manageable in the long run. Just let me know if you'd like me to move anything once you create it, I have some other stuff inspired by older OpenCensus and OpenTracing projects/wrappers I've found and reworked for Otel so I'll stay tuned.

[jmacd]

@rghetia I've heard we are discussing a per-language contrib repository at the OTel governance level. Do you know if that has been decided?

[rghetia]

@rghetia I've heard we are discussing a per-language contrib repository at the OTel governance level. Do you know if that has been decided?

I don't know the status of that discussion.
@lizthegrey do you have any insight?

[achew22]

Would it be better instead to add the tracer to the sql.DB? That would be generic to all the various ways people talk to databases.

[wingyplus]

@achew22 i didn’t see any plugin around sql.DB but i remember that opencencus have this kind of plugin callled ocsql https://github.com/opencensus-integrations/ocsql/blob/master/README.md. I think it’s not too much hard to convert to otel.

[rizkybiz]

I’d say people generally reach for either an ORM or they roll their own SQL using sql.DB. GORM implements it’s own DB type so it may be of merit to have both a GORM wrapper and a wrapper around the standard lib sql.DB

[achew22]

Under the covers gorm uses sql.DB and will even provide it back to you if you ask for it[1]. If we are looking to be inspired by ocsql, which is where I first ran into this delightfully clever idea, they provide ocsql.Wrap and ocsql.Register methods, which returns an object that embeds the normal sql.DB object and pass the calls through to that driver, after calling trace and then registers it under a new driver name. Then you can that driver name when you establish your connection. This means that ocsql is compatible with GORM out of the box.

Additionally, targeting a tracer to one of the stdlib interfaces seems, to me, like something that should be a part of the core opentelemetry-go instead of in a contrib which reduces the overhead of adding something like this in.

[1] Note: this only works for connections that actually go through sql.DB. It wouldn't work for, as an example, MongoDB. Due to this incompatibility it may be worth pursuing a GORM wrapper in addition.

[rghetia]

@rizkybiz you can move this to Contrib repo.

[rizkybiz]

@rghetia I'm assuming I'll have to pull in the master of the Go SDK and update to not be under that umbrella correct?

[glerchundi]

Additionally, targeting a tracer to one of the stdlib interfaces seems, to me, like something that should be a part of the core opentelemetry-go instead of in a contrib which reduces the overhead of adding something like this in.

I completely agree with this, otsql or something similar being part of the core implementation would be a step forward and would avoid incompatibility issues.

[rghetia]

Closing this as it is moved to open-telemetry/opentelemetry-go-contrib#2