我們上一篇文章說到了性能測試負載模型落地時的建模方法，這裏我們先就第一種也是最常用的一種方法說起：
原始數據分析法
業務場景建模主要就是說明用戶如何使用系統，因此根據系統使用的原始數據也就是日誌進行分析建模是最有效最準確的方法。所謂日誌就是指用戶操作系統的痕跡，根據記錄信息時的不同視角，一般分爲兩類：一類視角是基於用戶，我們稱之爲操作日誌，這類日誌主要以用戶爲觀察實體，記錄用戶從登錄系統到離開系統的每一個動作；另一類視角基於系統，我們稱之爲訪問日誌，這類日誌主要爲應用系統爲觀察實體，記錄系統的輸入輸出。輸入就是每一個接收到的請求信息，輸出就是該請求的響應狀態。
基於操作日誌
對應於我們之前提出的模型的概念，當我們關注的負載主要是用戶量、業務量這類數據時，我們通常使用操作日誌來進行分析。
這類日誌信息一般都存儲於系統的物理表中，因此大都可以通過統計SQL來進行分析，例如公司內的各個產品線，都可以使用我們自己開發的UMT小工具直接將建模需要的關鍵信息統計出來。對於公司外的產品，該方法同樣適用，因爲任何一個產品的日誌信息都至少包括4W1H，也就是什麼用戶（WHO）在什麼時間（WHEN）由哪臺機器（WHERE）通過訪問哪個功能(WHICH)做了什麼事（HOW），針對每一個W或者組合進行統計，就大致可以得出我們前面所說的要獲取的三要素信息。
該分析方法的缺點就在於：對於還原用戶使用模型的準確度來說，主要依賴於系統操作日誌記錄是否完整準備。
基於訪問日誌
當我們關注的負載主要是PV、吞吐量這類數據時，通常是針對訪問日誌來進行分析，這類日誌一般都是在中間件或WEB服務器的日誌文件中存儲。
這類日誌記錄的數據一般都是規則的數據，所以可以很方便的使用正則對數據整理後進行統計，對於臨時統計一下數據，可以使用類似log analyzer這類的工具統計，這類開源的小工具有很多，基本原理都是一樣的；而對於一些需要長期觀察的系統，建議的方式是根據日誌文件中的字段建立一張物理表，通過shell腳本將日誌文件中日誌記錄整理後不斷寫入到物理表中，然後在物理表中再進行分析，分析方法基本也是4W1H原則。
該分析場景的準確度高，但由於日誌是基於http請求記錄的信息。因此，要建立實用度高的分析模型，需要對系統的各個頁面和功能足夠熟悉，並且要建立準備完備的元數據來建立頁面和功能的映射。