打造AQF中量化交易體系是一個綜合性的工作，在這個過程中難免會出現(xiàn)一些問題，所以小編在這里為大家分享一下量化交易系統(tǒng)中的日志的一些實用技巧希望能來幫助到大家。
一、分割策略
為了便于區(qū)分不同類別的日志內(nèi)容，我們一般會把這些日志分門別類的存放在相應(yīng)的日志文件中，比如把異常日志存放在error.log文件中，把調(diào)試日志存放在debug.log中，而業(yè)務(wù)類的日志也會存放在相應(yīng)的文件，比如可以回測流程中的產(chǎn)生的日志存放在backtest.log中。
由于日志在系統(tǒng)運行中，會持續(xù)生成，一直存放在一個文件中就會導(dǎo)致這個文件過大，定位困難，因此需要指定文件的分割策略。常用的策略有兩種：一種是每天生成一個新文件;另外一種是指定文件大小的較大數(shù)值，一旦到了這個大小就會生成一個新文件。兩種策略各有利弊，按日分割還是有可能產(chǎn)生十分大的文件，比如回測的日志，曾經(jīng)碰到過幾個小時內(nèi)達到上百G的情況;那么按文件大小的分割，就可能會導(dǎo)致一個文件中包含好幾天的日志，或者一天的日志被分割到多個文件中，如果設(shè)置的文件過小，還有可能迅速在日志目錄生成很多小文件。所以要根據(jù)實際情況，確定分割方式。大部分語言的日志框架都支持日志的定向輸出和文件分割，具體如何使用得看API文檔。
.png)
分布式的量化交易系統(tǒng)，每個子系統(tǒng)都是獨立運行，并且有些因子或者基礎(chǔ)數(shù)據(jù)的計算模塊還是可插拔的，那么生成的日志也會分布在不同的系統(tǒng)上。當(dāng)前我們看到的就是一個分布式的日志采集系統(tǒng)的架構(gòu)，這里我們列舉了四個大的子系統(tǒng)數(shù)據(jù)處理子系統(tǒng)、策略管理子系統(tǒng)、交易決策子系統(tǒng)和交易執(zhí)行子系統(tǒng)，每個子系統(tǒng)在運行過程中都會產(chǎn)生大量的日志。為了收集這些日志，我們需要在每臺主機上安裝采集日志的Agent，也就是代理程序，比如阿里云用的logtail、或者apache的flume agent等，這些代理程序需要安裝到所有的主機上。代理負(fù)責(zé)實時采集子系統(tǒng)產(chǎn)生的日志，然后把這些日志發(fā)送到統(tǒng)一的采集通道上，也就是Collecting Channel，這個通道一般都是一個數(shù)據(jù)臨時存儲，比如可以用Kafka。然后呢，再接著發(fā)送到后端的存儲系統(tǒng)，日子的存儲系統(tǒng)需要兼顧存儲效率和分析效率，一般情況下，顆粒度越細的數(shù)據(jù)，可能需要保存的時間段越短，因此這些日志就要根據(jù)分析的需求進行壓縮存儲。
二、分析與報告
對日志的分析，一般會包括離線分析的，這種分析一般生成的是定時報告，一種是實時分析，這種分析比較常見，比如我們經(jīng)?？吹?分鐘的在線人數(shù)、日活躍用戶這種類似的統(tǒng)計，這種是基于時間窗口的統(tǒng)計。對于日志的分析，還有一種需求就是實時的報警。AQF量化交易系統(tǒng)中，數(shù)據(jù)是最關(guān)鍵的環(huán)節(jié)，所以有關(guān)數(shù)據(jù)的任何異常可能都需要及時報警。比如，接收交易所的數(shù)據(jù)程序突然異常停止了、交易決策發(fā)的異常委托單超過了一定的閾值等等。報警的手段多種多樣，最常用的有郵件和短信，現(xiàn)在還有一些開源的發(fā)送微信的程序可以接入微信，告警有時候也要區(qū)分重要級別，同時確保報警的準(zhǔn)確性，否則就會變成了狼來了，失去了應(yīng)有的意義。報警的接收人也要慎重選擇，我們有時候可能會認(rèn)為消息發(fā)送給越多人知道越好，因為總會有人看到的。其實只要不是直接關(guān)系人，一般都會直接忽略這個消息的，起不到預(yù)想的作用。
從上面的架構(gòu)中，我們可以看出，日志的處理也是一項很耗大的工程，尤其是系統(tǒng)變得越來越龐大后，日志系統(tǒng)的開發(fā)和維護任務(wù)也會變得十分繁重。好在，日志分析是所有系統(tǒng)的共同需求，現(xiàn)在有不少的開源軟件可以幫助我們完成這些任務(wù)。另外如果我們把系統(tǒng)部署到云上，也可以看到這些云服務(wù)商都會提供相應(yīng)的日志分析服務(wù)，無需我們重復(fù)發(fā)明輪子。
日志對于整個系統(tǒng)的運行起著十分重要的作用，因此我們一定要重視日志的使用。
.jpg)
