Python 版 APM 服务使用测试

后端开发与云服务

云服务这个词，大概最先是从云盘开始的，那时候概念也特别简单，无非就是把一些数据存在别人的服务器上，在”云存储”这个名词火起来以前，QQ 也有提供网站的功能用来存一些小东西（05年06年的样子，那时候大概只有几十 M 的空间），其实刚听到这个概念的时候我就很不理解，光存存东西不至于吹得这么玄乎吧。毕业后入行，云服务器才慢慢真真的丰富起来，从最开始的 VPS 变成云服务器、存储变成资源服务器、远程数据库等等，如今甚至有帮你防 DDOS 的服务（去年和今年貌似 DDOS 变得愈来愈没有节操了）。确实节省了不少精力，也省钱。

除了云，最近几年还有另一个比较火的词："大数据”。我没接触过那么大的数据，做为一个半吊子运维，接触的最大的数据应该就是服务器 log 了。因此大数据的东西之后有机会接触再说，对我来讲更重要的是 — 数据统计。

服务端的各类 log 不只是分析服务器的状态的重要参数，也是从后台代码里抓 bug 抓异常检查 SQL 性能等各类工做的参考。log 数据通常都是单调并且重复的居多，要发现它的价值，每每须要大量的分析和统计工做。各类监控服务、分析工具也是层出不穷。不过到今年我才知道有个词叫 "APM"。

APM (Application Performance Management/Monitoring) 简单翻译过来就是"应用性能管理/监控”(也许说监控更准确一些)。大概就是服务器上部署的 awstats、nagios、zabbix 等一堆东西的集合。有服务器的地方就有云，既然这个事情这么麻烦，那就天然也能够交给别人来作了。

前几天找到了一个 Python 的小 web 框架：bottle，只有一个文件，简洁好用，以为很不错，先是用它来作了一个简单的小应用（APP 下载，公司内部使用），准备这段时间尝试用它来本身写一个简单的博客系统，改造一下本身的博客，因此业务时间花在搞 Python 上的比较多一点。刚好看到了在测 Python 版本的探针，因而部署来测试一下。部署以前先在本地作了一些测试，不过听云目前仅支持基于 django 开发的程序（文档上写的目标是支持全部以 wsgi 协议部署的 Python Web 服务，包括 flask、tornado 等等，不过这个应该还要等后续开发支持了），因此我就先在本地用 django 测了一下。

听云探针(Python版)的使用

探针部署过程十分简单，在听云后台复制本身帐户的 license key，生成配置文件，将配置文件地址加载到环境变量中，就能够启动程序开始使用了。如下是测试环境部署步骤的介绍。

先用 virtualenv 开辟一个环境并 active 之：

virtualenv tingyun
cd tingyun
source bin/active

听云探针在 pypi 的仓库里有，因此能够直接安装了，同时也安装 django , 探针支持 MySQL 的 log 记录，因此我也安装了 MySQL 的组件并将 django 的数据库从 sqlite 改为 MySQL：

# 安装组件
pip install tingyun django MySQL-python
# 建立一个 django 工程
django-admin startproject www

接着须要修改一下 django 的数据库选项，进入到 www/www 目录，打开 settings.py，找到 DATABASE 的字典，注释掉原有的 sqlite 选项并改成 MySQL：

# 'default': {
#     'ENGINE': 'django.db.backends.sqlite3',
#     'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
# }
'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'django',
    'USER': 'root',
    'PASSWORD': '',
    'HOST': '',
    'PORT': '',
}

在 MySQL 中建立 django 的库，而后安装 django 的 admin 后台须要的数据表（注意回到 manage.py 所在的目录）：

python manage.py syncdb

接下来设置听云的服务，按照听云后台的提示和文档说明进行就能够了：

# YourLicenseKey 是你的听云后台里显示的 key
# 听云后台里将 tingyun.ini 放置在 tmp 目录，我建议你放在当前工做目录，省得丢失
# 一些配置参数能够打开 tingyun.ini 进行修改
tingyun-admin generate-config YourLicenseKey tingyun.ini
#
# 这里的 TING_YUN_CONFIG_FILE 写绝对路径比较保险，如下是我本地的目录
# 若是是在服务器上，能够写入到 .bashrc 或者 .bash_profile 中去，须要重启服务时不用从新设置
export TING_YUN_CONFIG_FILE=/Users/Scholer/Work/Personal/tingyun/tingyun.ini
#
# 听云的服务会读取当前环境变量的参数 TING_YUN_CONFIG_FILE 来获取配置文件
# 咱们能够先检查一下，若是看到 success 字样就 OK
tingyun-admin check-config

万事具有，能够启动服务了：

tingyun-admin run-program python www/manage.py runserver

接下来咱们就能够浏览一下页面，登陆一下后台等等生成一些访问记录来看看效果了（或者能够比较残暴一点用测试工具，我用 ab 发了一些的测试请求）。

一切顺利的话，过一下子刷新一下听云的后台，就能看到一些数据了。

有一些事情须要注意一下：

1. 听云的多个应用是同一个 key，经过应用名称来区分应用；
2. 不一样于一些其余服务、听云没有新建一个 应用的过程，有部署、上报的数据就能看到数据了；
3. 若是使用 uwsgi 的方式不是，须要开启 enable-threads 和 single-interpreter 的选项。

上报数据观察

登陆到听云的后台管理面板就能查看到一些监控日志分析了（图表是用 highcharts 作的，体验至关不错）。

图中能够看到一些基本的数据图表，包括应用的响应时间、Apdex（应用程序性能指数），应用响应耗时和吞吐率等等。

此外面板上也会有硬件的基本信息，包括 CPU 的占用时间、内存占用等参数。

各项参数指标的统计最终目的都是为了分析服务器自己的承载能力和性能。当以上参数出现异常状况，好比响应时间过长、CPU负载太高或者内存剩余很少时，就要考虑升级硬件资源或者对程序进行优化了。

Apdex (Application Performance Index) ，应用性能指数。这是一个近几年成立的联盟组织，大概是在 2010 年发起的，12 年以后沉寂了两年，去年又开始活跃了。这个联盟意在经过一个统一的标准来计算和衡量应用程序的的性能，在它的 官网 中有一些专门的文章来介绍本身。

"Apdex is a way to study measurements of any experience that can be interpreted on a scale ranging from excellent to unacceptable. " （Apdex 用以学习解释从好到坏的评级标准的相关经验。）

Apdex 的计算在下面这篇文章用也有介绍：

Apdex = (正常样本 + 0.5 x 低质样本 + 0 x 高质样本) / 样本总量

咱们能够这样把正常样本理解成正常的时间，低质和高质就分别表示响应的慢和快。显然计算结果从 1 到 0 就表示从好到坏。

详细介绍：http://www.apdex.org/index.php/2014/05/apdex-is-not-just-for-application-performance/

以上两张统计图分别展现了应用层的处理时间与数据库调用时间。这两个参数是对程序和 SQL 语句进行优化的重要参考。这里应该是计算的平均时间。

在实际的分析过程当中，咱们也一样须要对于全部耗时过长的处理或者 SQL 慢查询进行分析和优化。听云也提供了对于耗时应用和 SQL 的统计。

在上面的"最耗时的应用过程"中，有一个墙钟时间比的概念。墙钟时间（Wall-clock time / wall time）指的是程序从开始执行到结束的过程当中人的时间感知（这个时间是大于 CPU 时间的，由系统提供）。墙钟时间比就表示当前时间点下某个程序占总墙钟时间的百分比。

除了常见关系型数据库的监控，听云也提供了对 memcached、Redis、MongoDB 等非关系型数据库的监控和统计。

响应率和吞吐率参数参数。吞吐率指的是单位时间内响应的数量。这两个参数是对网站整体的响应速度和承载能力的评估。

吞吐量、响应时间、Apdex和错误率的概览。

听云后台的参数记录十分全面，从硬件基础到程序响应到数据库执行耗时都有完整的分析和记录。不过遗憾的是在后台没有看到 HTTP 状态码的记录，相似 awstats 提供的记录和统计功能。不过相对于一个须要本身作复杂的配置的开源组件，优点仍是十分明显的。我也相信随着时间的推移，服务会愈来愈丰富，这些信息都会被记录并分析出来。

简析

部署和数据分析都说了，如今也能够简单的来分析下听云是如何运做的。我无心去弄清楚探针工做的每个步骤，但却能够了解一下大体的流程。

Python 做为一门胶水语言，已经积淀了丰富的优秀模块，从来都是被公认为做为服务端运维最强力的脚本语言，对于这类问题的处理上，具备自然的优点。听云在语言上也作了处理，可以同时支持 Python 2 和 Python 3。

在听云的配置文件 tingyun.ini 中，除了有 license_key 之外，还有 app_name、 log_file 、 log_level 等参数配置。其中 action_tracer.log_sql 能够选择是否将 SQL 日志只保存在本地文件中（这应该是出于安全考虑，毕竟把全部的 SQL 日志都暴漏给服务平台，有些人可能会有些顾虑。可是考虑到如今服务器通常都是云服务器，因此这其实问题也并不大，选择了服务，就应该相信服务），这点听云考虑的很周到。

log 文件中记录了一些 trace 的log，包括程序耗时等。

回到程序自己中去，在启动探针的时，咱们执行的是 tingyun run-program，最终执行的是听云的 package 中 admin 目录下的 run_program 的函数，check_config、generate_config 也位于 admin 目录下。整个程序目录还包括 bootstrap 、hook 和 api 目录。

root_directory = os.path.dirname(root_directory)
boot_directory = os.path.join(root_directory, 'bootstrap')
python_path = boot_directory

run_program 将 bootstrap 目录加入系统 path 中。经过 Python 提供的两个 hook（sitecustomize 和 usercustomize 之中的 sitecustomize，听云探针正式被加载到运行环境中：

if config_file is not None:
    # When installed as an egg with buildout, the root directory for
    # packages is not listed in sys.path and scripts instead set it
    # after Python has started up. This will cause importing of
    # 'tingyun' module to fail.

    if root_directory not in sys.path:
        sys.path.insert(0, root_directory)

    import tingyun.agent

    # Finally initialize the agent.
    tingyun.agent.initialize(config_file=config_file)

在 tingyun.api.initial.config 中，initialize 函数被执行，调用 _process_module_builtin 函数，探针开始工做 ：

_load_configuration(config_file=config_file)

if not _detect_done:
    _detect_done = True
    _process_module_builtin()

MySQL、Redis 等监控模块都位于 hook 目录下，经过 _process_module_definition_wrapper 函数将进程与监控模块进行绑定，包括 django 的主要模块以及经常使用的数据库等。在核心模块执行的时候触发监控，将数据回传到 api.tracert 模块进行处理。

而对于硬件信息的检测则由 api.platform.system_info 进行。

应用监控数据最终会由 api.tracert.uploader 上传到听云的服务器（host 的设置位于 api.settings 中，host 地址是 redirect.networkbench.com，因此看到你的服务器往这个域名发送请求时，不要以为奇怪），经过听云的处理，咱们就能看到应用程序的各类监控数据了。

对听云探针的简单分析就到这里，有兴趣的读者能够进一步深刻研究。其实对于这类云服务，程序的自己都是透明的，不用有太大的安全顾虑，对于服务提供方而言，更重要的是数据的分析工做。

听云自己提供的服务器是很是优秀的，虽然目前还并不是完美。我也期待服务能更加完善，提供更完善的数据分析。另一方面，经过 tingyun-admin run-program 的方式启动程序，对开发者和服务器管理员来讲可能有些侵入感。若是能用模块加载的方式调用，或许更符合某些开发者的习惯。