The test was actually generating 2 spans but on very fast systems we
only saw one as the test ran faster than the message would travel
through the broker, trigger a task and generate 2nd span.
Switched from .delay() to .apply() so only one span is generated which
is enough for the test in question.
It seems the same in memory span exporter was being reused by multiple
tests. This change _should_ create a new instance of memeory exporter
per test/function.
Fixes#2067
* redis: fix default port KeyError, wrong attr name
* fix docker tests and another ip/port issue in asyncpg
Co-authored-by: Alex Boten <aboten@lightstep.com>
Changes:
- Update dbapi instrumentation to use the SQL statement name as the span
instead of the entire SQL query.
- Renamed TracedCursor with CursorTracing. The class was not a valid
Cursor so the name was confusing.
- Updated CursorTracing's (previously TracedCursor) traced_execution
method to accept the cursor instance as the first argument. This is
required as for some dbapi implementations, we need a reference to the
cursor in order to correctly format the SQL query.
- Updated psycopg2 instrumentation to leverage dbapi's `cursor_factory`
mechanism instead of wrapping the cursor with wrapt. This results in a
simpler instrumentation without monkey patching objects at runtime and
allows psycopg2's type registration system to work. This should make it
possible to use psycopg2 instrumentation when using the JSONB feature or
with frameworks like Django.
Current instrumentation uses the entire SQL query as the operation name
which makes traces very hard to read and understand in addition to
introducing high-cardinality issues. This commit fixes the problem by
using only the SQL operation name and the DB name instead of the entire
query.
Here is an example snippet that will not report tracing without this patch:
with psycopg2.connect(...) as conn, conn.cursor() as cursor:
cursor.execute("select 1;")
Co-authored-by: Carl Bordum Hansen <carl@bordum.dk>
