Request URL is not consistent with Transaction name?

[fr0der1c]

Kibana version: 6.6.0

Elasticsearch version:6.6.0

APM Server version:6.6.0

APM Agent language and version: python 4.1.0

My application is a Flask web application. When I'm discovering data in Kibana, I found some documents where the context.request.url.full seems inconsistent with the transaction.name. Is this normal?

[beniwohli (Benjamin Wohlwend @ APM)]

Hi @fr0der1c

this definitely doesn't look normal, and I don't really have an idea what could cause this. But it does look like there might be some issues with context tracking. Do you per chance use threaded workers (e.g. gunicorn with --threads N)?

[fr0der1c]

I use uWSGI with gevent (preforking+async), here is my configuration:

uwsgi.ini (unrelated code omitted):

[uwsgi]
# launcher
wsgi-file = server.py
callable = app

# workers
master = true
processes = 4
gevent = 100
thunder-lock = true

lazy-apps = false

server.py (unrelated code omitted):

from gevent import monkey
monkey.patch_all()

import gc
from my_application import create_app

app = create_app()

my_application/__init__.py (unrelated code omitted):

__app = None

try:
    import uwsgidecorators

    @uwsgidecorators.postfork
    def init_log_handlers():
        from elasticapm.contrib.flask import ElasticAPM
        global __app

        # Elastic APM
        if __app.config['CONFIG_NAME'] in __app.config['APM_AVAILABLE_IN']:
            ElasticAPM(__app)
            logger.info('APM is inited because you are in {} mode.'.format(__app.config['CONFIG_NAME']))
except:
    pass

def create_app() -> Flask:
    app = Flask(__name__)

    from my_application.config import get_config
    _config = get_config()
    app.config.from_object(_config)

    global __app
    __app = app

    return app

It might be a thread-local-related issue, but I didn't run into another similar issue except for this one.

[fr0der1c]

Hi @beniwohli ,
I can confirm this is a gevent-related issue. After removing gevent monkey-patch and removing gevent = 100 in uwsgi.ini, this weird situation disappeared and spans are available again (my APM didn't have any spans since some time and I was not aware that this is related to applying gevent monkey-patch).
I'll read the python APM agent source code and try to find the root cause. It would be nice if you can give me some hints related to the issue. Is there any other known compatibility issues in the past between APM agent and gevent?

[beniwohli (Benjamin Wohlwend @ APM)]

Hey @fr0der1c

to be honest, we don't have a huge amount of experience with the agent under gevent/eventlet/etc. While we have some feedback from users that are generally happy with it, we don't officially support it yet and don't have proper test coverage for it.

One issue that I saw creeping up a couple of times was when gevent monkeypatching happened after initialization of the agent. In that case, we get an un-monkeypatched version of the threading module, which can lead to confusing results.