Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uninstrumented modules in New Relic agent initialization #7372

Open
jgmize opened this issue Jul 3, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@jgmize
Copy link
Member

commented Jul 3, 2019

Description

Getting the following error on https://rpm.newrelic.com/accounts/1299394/applications/57236602 since the latest prod deploy:

Some modules were uninstrumented during the current time window: meinheld.server, gunicorn.app.base. Make sure newrelic.agent.initialize() is called before any of these modules are imported. Visit the documentation for more information.

This appears to be a regression since the Django-2.2/Python3 upgrade.

@jgmize jgmize self-assigned this Jul 10, 2019

@ipmb

This comment has been minimized.

Copy link

commented Jul 11, 2019

I think this is unrelated to the upgrade and was probably always the case with how newrelic is currently being invoked, but just now being reported.

The only way around it I know of is to use the wrapper newrelic-admin run-program to start the gunicorn process (probably here). Right now, gunicorn starts, then imports the WSGI app, which then invokes newrelic.initialize, so we expect it can't instrument gunicorn which was executed before newrelic was initialized.

All that being said, it's also probably safe to ignore this warning. Newrelic is instrumenting your Django code, and it not being able to instrument those modules probably won't have any significant effect on the reports you see.

@jgmize

This comment has been minimized.

Copy link
Member Author

commented Jul 11, 2019

Thanks @ipmb. I agree with your reasoning that it is probably safe to ignore this warning, and using the newrelic-admin wrapper is likely the only way to remove it. In fact, I shared very similar thoughts last week in a discussion with @SmileyChris & @metadave.

For background, we ran into similar issues before, and after a couple of iterations that issue had not reappeared until the Django 2.2/Python3 upgrade was deployed. When I first saw this appear during the initial deployment of the upgrade to our development & staging environments, I decided it was not a blocker for going to production for those same reasons you described above, and as I mentioned in slack earlier, I consider this to be a very low priority issue and as far as I'm concerned the upgrade work is complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.