我们上一篇文章说到了性能测试负载模型落地时的建模方法，这里我们先就第一种也是最常用的一种方法说起：
业务场景建模主要就是说明用户如何使用系统，因此根据系统使用的原始数据也就是日志进行分析建模是最有效最准确的方法。所谓日志就是指用户操作系统的痕迹，根据记录信息时的不同视角，一般分为两类：一类视角是基于用户，我们称之为操作日志，这类日志主要以用户为观察实体，记录用户从登录系统到离开系统的每一个动作；另一类视角基于系统，我们称之为访问日志，这类日志主要为应用系统为观察实体，记录系统的输入输出。输入就是每一个接收到的请求信息，输出就是该请求的响应状态。
基于操作日志对应于我们之前提出的模型的概念，当我们关注的负载主要是用户量、业务量这类数据时，我们通常使用操作日志来进行分析。
这类日志信息一般都存储于系统的物理表中，因此大都可以通过统计SQL来进行分析，例如公司内的各个产品线，都可以使用我们自己开发的UMT小工具直接将建模需要的关键信息统计出来。对于公司外的产品，该方法同样适用，因为任何一个产品的日志信息都至少包括4W1H，也就是什么用户（WHO）在什么时间（WHEN）由哪台机器（WHERE）通过访问哪个功能(WHICH)做了什么事（HOW），针对每一个W或者组合进行统计，就大致可以得出我们前面所说的要获取的三要素信息。
该分析方法的缺点就在于：对于还原用户使用模型的准确度来说，主要依赖于系统操作日志记录是否完整准备。
基于访问日志当我们关注的负载主要是PV、吞吐量这类数据时，通常是针对访问日志来进行分析，这类日志一般都是在中间件或WEB服务器的日志文件中存储。
这类日志记录的数据一般都是规则的数据，所以可以很方便的使用正则对数据整理后进行统计，对于临时统计一下数据，可以使用类似log analyzer这类的工具统计，这类开源的小工具有很多，基本原理都是一样的；而对于一些需要长期观察的系统，建议的方式是根据日志文件中的字段建立一张物理表，通过shell脚本将日志文件中日志记录整理后不断写入到物理表中，然后在物理表中再进行分析，分析方法基本也是4W1H原则。
该分析场景的准确度高，但由于日志是基于http请求记录的信息。因此，要建立实用度高的分析模型，需要对系统的各个页面和功能足够熟悉，并且要建立准备完备的元数据来建立页面和功能的映射。
