ext/{dbapi,pymysql}: Implement methods to (un)-instrument connections #624
Conversation
mauriciovasquezbernal
added
ext
instrumentation
Implement to helper methods to allow users to enable / disable instrumentation in a single connection object.
|
|
||
| def test_uninstrument_connection(self): | ||
| connection = mock.Mock() | ||
| # Avoid get_attributes failing because can't concatenate mock |
There was a problem hiding this comment.
There is a function inside the instrumentation that concatenates "connection.database" to another string, if I don't set it here it fails because mock cannot be concatenated. I'll update the comment to make it more clear.
ext/opentelemetry-ext-dbapi/src/opentelemetry/ext/dbapi/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-dbapi/src/opentelemetry/ext/dbapi/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-dbapi/src/opentelemetry/ext/dbapi/__init__.py
Outdated
Show resolved
Hide resolved
…__.py Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>
…__.py Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>
codeboten
added
the
needs reviewers
| conn = getattr(connect_module, connect_method_name, None) | ||
| if isinstance(conn, wrapt.ObjectProxy): | ||
| setattr(connect_module, connect_method_name, conn.__wrapped__) | ||
|
|
||
|
|
||
| def instrument_connection( |
There was a problem hiding this comment.
Is there a need for wrap_connect anymore now that we have this? It seems this allows for better control of instrumentation, and we can recommend it as the only way to instrument DBApi connections.
There was a problem hiding this comment.
Oh it seems that wrap_connect is the path that should be taken for auto-instrumentation, and instrument_connection should be used for programmatic correct? Similar to what we do for flask?
There was a problem hiding this comment.
That's right. wrap_connect is used to instrument the whole library, so every new connection created is instrumented, this can be used by the autoinstrumentation and also by users that want to enable that a the library level. On the other hand, instrument_connection allows a more granular control by enabling the instrumentation in a single connection.
| database_type, | ||
| connection_attributes=connection_attributes, | ||
| ) | ||
| db_integration.get_connection_attributes(connection) |
There was a problem hiding this comment.
I feel like get_connection_attributes should be renamed to something that implies action, as it actually modifies the db_integration object itself in the process.
Maybe something like "load_connection_attributes"?
Draft until #611 is merged, to avoid solving many conflicts later on.
The current integrations based on dbapi allow to patch the
connectfunction on those libraries to return an instrumented connection, however it's not possible to enable instrumentation on a connection previously created or to disable instrumentation in an instrumented connection.This PR adds two convenience functions,
instrument_connectionanduninstrument_connectionthat allow to enable / disable instrumentation in specific connection objects.This PR only implements the logic in PyMySQL, it can be easily done in other instrumentations once we think it's worth to be done.
@hectorhdzg @lzchen since you folks have worked in these instrumentations before I'd like to get your opinion on this.