代理的工作原理
编辑代理的工作原理编辑
为了收集 APM 事件（称为事务和跨度）、错误和指标，Python 代理以几种不同的方式对您的应用程序进行检测。然后，这些事件将发送到 APM 服务器。APM 服务器将它们转换为适合 Elasticsearch 的格式，并将其发送到 Elasticsearch 集群。然后，您可以使用 Kibana 中的 APM 应用程序来深入了解应用程序中的延迟问题和错误原因。
总的来说，我们区分了三种不同的方法来收集必要的数据：框架集成、检测和后台收集。
框架集成编辑
为了收集有关传入请求和后台任务的数据，我们与 Django、Flask 和 Celery 等框架集成。只要有可能，框架集成就会利用框架提供的钩子和信号。例如：
-
request_started、request_finished和got_request_exception来自django.core.signals的信号 -
request_started、request_finished和got_request_exception来自flask.signals的信号 -
task_prerun、task_postrun和task_failure来自celery.signals的信号
框架集成需要在您的应用程序中进行一些有限的代码更改。例如，对于 Django，您需要将 elasticapm.contrib.django 添加到 INSTALLED_APPS 中。
如果您没有使用框架怎么办编辑
如果您没有使用支持的框架，例如，一个简单的 Python 脚本，您仍然可以使用代理的 自动检测。查看我们关于 检测自定义代码 的文档。
检测编辑
为了收集来自数据库驱动程序、HTTP 库等的数据，我们检测了这些库中的某些函数和方法。我们的检测包装了这些可调用对象，并收集了其他数据，例如：
- 在调用中花费的时间
- 数据库驱动程序执行的查询
- HTTP 库获取的 URL
我们使用一个第三方库 wrapt 来包装可调用对象。您可以在 Graham Dumpleton 的一系列优秀的 博客文章 中阅读有关 wrapt 工作原理的更多信息。
检测会自动设置，不需要任何代码更改。请参阅 自动检测，以了解有关我们支持哪些库的更多信息。
后台收集编辑
除了 APM 和错误数据外，Python 代理还会定期收集系统和应用程序指标。此收集发生在代理启动的后台线程中。
除了指标收集后台线程外，代理还会为每个进程启动两个额外的线程：
- 一个线程定期从 APM 服务器获取远程配置
- 一个线程处理收集到的数据，并通过 HTTP 将其发送到 APM 服务器。
请注意，每个实例化代理的进程都将拥有这三个线程。这意味着，例如，当您使用 gunicorn 或 uwsgi 工作进程时，每个工作进程都将拥有代理启动的三个线程。