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.
SQLAlchemy spans were missing kind field and it was being set to
internal instead of client. This commit changes sqlalchemy spans to have
kind set to "client" instead.
* adding README
adding sample app
adding examples readme
fixing lint errors
linting examples
updating readme tls_config example
excluding examples
adding examples to exclude in all linters
adding isort.cfg skip
changing isort to path
ignoring yml only
adding it to excluded directories in pylintrc
only adding exclude to directory
removing readme.rst and adding explicit file names to ignore
adding the rest of the files
adding readme.rst back
adding to ignore glob instead
reverting back to ignore list
converting README.md to README.rst
* addressing readme comments
* adding link to spec for details on aggregators
* updating readme
* adding python-snappy to setup.cfg
If a Flask request doesn't have an active span, it just means that it
was initialized via a mechanism that doesn't run `before_request`, like
`app.test_request_context` or even manually. It is okay and
instrumentation still works.
Fixes#196
This marks the test case as flaky, making it run at most 3 times. It is
enough for one of this runs to pass to consider this test case passed
and ran no more. If 3 consecutive runs of this test case fail, the test
case will be considered failed. It has been reported that running this
test case again makes it pass, usually. This approach is preferred over
marking it as xfail(strict=False) because most of the times the test
ends up passing after another run, so that in most of the cases we
can still benefit from running this test case (since if it is actually
failing because of a bug it will be reported as such after failing 3
times, making the team aware of an actual issue happening here).
