On this page:
This topic describes how to prepare the application environment and install the AppDynamics Python Agent.
If you are using uWSGI, set enable-threads=1 in the uWSGI configuration file. The agent requires multi-threading.
There is a known incompatibility between the Python Agent and versions of uWSGI installed via OS packages managers such as ‘apt-get’. For this reason AppDynamics recommends installing uWSGI from pip to avoid this issue.
If the application that you will monitor runs in a virtual environment, activate the virtual environment. For example, the following source command activates a virtual environment:
Activating a virtual environment is not necessary if the application runs in the global Python environment.
Log in to the machine on which the Python application runs using appropriate user credentials, as follows:
To install or upgrade to the latest version of the agent, run the pip install command as follows:
When there are multiple packages, you can locate the agent using the
pip list command or using the List packages facility at https://pypi.python.org/pypi and then find "appdynamics" in the output. Here is sample output:
For production deployments, AppDynamics recommends that you freeze the versions of dependencies so that they are not upgraded in production without first being deployed to your test/staging environments. The command to install (or upgrade to) a particular version of the AppDynamics Python Agent is:
This command always installs the exact same version of the agent each time it is run.
Provide a configuration file that specifies the required AppDynamics settings for agent-Controller communication. The file should be in Python ConfigParser format. The Python application user must have read access on the configuration file.
Note that lines in the configuration file must not start with spaces. Lines that begin with a # are comments and are ignored by the agent.
The following is a simple sample configuration file with minimum required settings.
Note the following points in the configuration:
When you instrument an application using
pyagent run, you pass the configuration file's path as a parameter to the pyagent run command. In other deployments set the APPD_CONFIG_FILE environment variable as illustrated below in the samples for uWSGI with Emperor and Apache with mod_wsgi.
Which instrumentation instructions to use depends on how the application is deployed, from these deployment options:
Irrespective of your Python environment, if you built your application using PasteDeploy, you can install the Python Agent by modifying the PasteDeploy configuration. See PasteDeploy.
If you can control the way your WSGI server is invoked, you can instrument the application using
pyagent run. This command runs your WSGI server with the Python agent enabled. This option is generally possible if you use a process launcher/manager that takes a command to execute; for example, frameworks managed by Supervisor, uWSGI without Emperor, init.d scripts, and so on.
To use the
pyagent run command, prepend to your existing application run command the
pyagent run command, passing the AppDynamics configuration file described in Configure the Agent as a parameter.
Do not overwrite PYTHONPATH for any reason. Doing so will prevent the
pyagent run command from loading the agent. If you need to add to PYTHONPATH, use the pythonpath configuration variable. For example, these commands add /foo and /bar to the PYTHONPATH instead of overwriting it:
Do not add the values to PYTHONPATH using this syntax:
If you use supervisorctl, after updating your Supervisor configuration you must use the supervisorctl reload command to have the Python agent loaded. Supervisor does not re-read its configuration files when you use the supervisorctl restart command.
To verify that the agent was loaded, look for the Python agent log file. Its default location is /tmp/appd/logs/<app_name>-<node_name>.log. For example, if your application name is "myapp" and your node name is "mynode" as specified in the agent configuration file, and you have not changed the location of the log file, the log file will be /tmp/appd/logs/myapp-mynode.
If the log file exists, the agent was loaded. If the log file does not exist, the agent was not loaded, in which case you should try reloading the Supervisor configuration with supervisorctl reload.
If your framework is Django or Flask, simply prepend the
pyagent run to your run command. For example, if your current run command looks like this:
Replace it with the following:
If you use a WSGI-based framework that is not Django or Flask:
pyagent runto your run command.
For example if your run command looks like this:
Replace it with these two commands:
If your environment is uWSGI with Emperor, you need to modify your WSGI configuration files and then manually launch the proxy.
Modify the uWSGI configuration file. Do one of the following, depending on whether the configuration uses a module directive or a wsgi-file directive:
If the uWSGI configuration has a module directive like so:
modify that configuration by changing the module setting and adding the APPD_WSGI_MODULE and APPD_CONFIG_FILE settings to look like this, assuming that you have stored the configuration file in /etc/appdynamics.cfg:
If the uWSGI configuration has a wsgi-file directive:
Modify the configuration to look like this, assuming you have stored the configuration file in /etc/appdynamics.cfg:
Before running any traffic through the instrumented application, manually launch the proxy by executing:
The Python Agent beta supports only mod_wsgi configurations that use
WSGIScriptAlias pointing to a single WSGI file. For example, the following type of configuration is supported:
If, instead, the script alias points to a directory, or if they are using the
WSGIScriptAliasMatch directive, contact email@example.com to discuss how the Python Agent can be deployed in your environment.
If the environment is Apache with mod_wsgi with a supported configuration as described above, you need to modify their mod_wsgi configuration files and manually launch the proxy.
Modify the mod_wsgi configuration file.
If the mod_wsgi configuration file has an entry like this:
modify it to look like this, assuming that you have stored the configuration file in /etc/appdynamics.cfg:
Before running any traffic through the instrumented app, manually launch the proxy by executing:
You can instrument a Python application built with PasteDeploy by modifying your PasteDeploy configuration to use a composite factory supplied by AppDynamics. This feature can be used to instrument applications described by the other deployment options if they were built with PasteDeploy.
The AppDynamics composite factory is named "egg:appdynamics#instrument". It requires a parameter named "target" that points to the application to the original application and the full path to the APPD_settings.
Manually launch the AppDynamics proxy:
In the PasteDeploy configuration file, rename the existing composite to a unique name.
For example, if the existing composite configuration for an application named "metadata" is:
you could rename it:
Create a new composite section for the "metadata" application above the original one that you just renamed, as follows:
Give the name of the old renamed application to the new composite application.
Configure it to use the AppDynamics composite factory: egg:appdynamics#instrument.
Set its target to the renamed application.
Set the AppDynamics configuration file environment variable, APPD_CONFIG_FILE, to the path of your configuration file. For example:
You can also set other APPD_ configuration variables here. For example: "APPD_LOGS_DIR=/var/log/appdynamics".