varnish的架構和日誌

varnish的架構和日誌

varnish的架構

知道varnish的內部結構有兩個重要的緣由：
        首先，架構主要負責性能，其次，它影響你如何將Varnish集成到你本身的架構中。
    主程序塊是Manager進程，包含在二進制程序varnishd中。
    Manager進程的任務是將任務包括緩存委託給子進程。
    Manager進程確保每一個任務老是有一個進程。
    這樣設計的主要驅動因素就是安全性。
    能夠經過如下方式訪問Manager的命令行界面（CLI）：
        1）varnishadm管理界面部分，
        2）Varnish Agent vagent2
        3）Varnish管理控制檯（VAC）（經過vagent2）
    Varnish Agent vagent2是一個varnishd服務的開源HTTP REST接口，它提供遠程控制和監視服務。 
    vagent2提供了一種Web UI ，同時你能夠編寫本身的UI。
    vagent2的一些功能是：VCL上傳，下載，保存（存儲到磁盤），參數查看，存儲（尚未持續），顯示/清除應急消息，開始/中止/查看varnishd服務，取締功能，varnishstat 採用JSON格式。
    父進程：manager
        Manager 進程由root用戶所擁有，其主要功能有：
            應用配置更改（從VCL文件和參數）
            將任務委託給子進程：Cacher和VCL到C編譯器（VCC）
            監視varnish
            提供一個varnish命令行界面（CLI）
            初始化子進程：Cacher
        Manager進程每幾秒鐘檢查一次cacher是否仍然存在。
        若是Manager在由ping_interval給定的時間間隔內沒有獲得回覆，那麼Manager將殺死Cacher並從新啓動。
        若是Cacher意外退出，也會發生自動重啓。
        你能夠經過使用varnishadm ping來進行手動ping。
        子進程的自動重啓是Varnish的一種復原屬性，這個屬性能夠確保即便Varnish包含一個能夠危害子進程的重要bug，子進程一般也會在幾秒鐘內從新啓動，您可使用auto_restart參數切換此屬性。
        注意：
            即便您沒有察覺到長時間的服務停機時間，您也應該檢查varnish的子進程是否正在從新啓動。
            這一點很重要，由於子進程重啓會致使額外的加載時間，由於這段時間中varnishd會不斷清空緩存。
            自動重啓的日誌記錄在/var/log/syslog，爲了驗證子進程是否被重啓，你也能夠用varnishstat中的MAIN.uptime計數器來檢查它的生命週期。
    子進程：cacher
        因爲Cacher偵聽的是公共IP地址和已知端口，所以它暴露在惡意客戶端面前。
        所以，出於安全考慮，這個子進程由非特權用戶擁有，而且沒有與其父進程Manager進行反向通訊。
        Cacher的主要功能是：
            聽取客戶端的要求
            管理工做線程
            存儲緩存
            記錄流量
            更新統計的計數器
        Varnish使用工做區來減小每一個線程在須要獲取或修改內存時的爭用。
        有多個工做區，但最重要的是會話工做區，它用於處理會話數據。
        如在輸入到緩存以前將www.example.com更改成example.com，來減小重複。
        請注意，即便你擁有5 MB的會話工做區並使用1000個線程，但實際的內存使用量也不是5 GB，虛擬內存的使用量確實是5GB，可是除非你真的使用內存，這不是問題，您的內存控制器和操做系統將跟蹤您實際使用的內容。
        爲了與系統的其餘部分進行通訊，子進程使用VSL訪問文件系統，這意味着若是一個線程須要記錄某些內容，所須要作的就是設定一個鎖，而後寫內容到到內存區域，最後再解鎖。
        除此以外，每一個工做線程都有一個緩存用於記錄日誌數據以此來減小鎖定爭用。
        日誌文件一般大約80MB，並分紅兩部分：第一部分是計數器，第二部分是請求數據，要查看實際數據，能夠採用工具解析VSL。
        因爲日誌數據並不意味着都是以原始形式寫入磁盤的，所以Varnish能夠作得很是詳細，這樣你可使用其中一種日誌解析工具來提取您想要的信息 - 便可以永久存儲也能夠實時監控Varnish。
        若是Cacher出現問題，它會記錄一個詳細的應急信息到syslog。
        當測試時，你可使用varnishadm debug.panic.worker 命令或使用vanish agent web 頁面上的induce panic按鈕來減小varnishd服務的應急信息。
    
    VCL編譯
        打印編譯爲C語言的VCL代碼並退出：
            varnishd  - C  - f  < vcl_filename >
            用於檢查您的VCL代碼是否正確編譯。
        Varnish配置語言VCL配置了Varnish的高速緩存策，而後VCL被VCC進程轉換爲C，它是由一個普通的C編譯器gcc編譯，而後連接到正在運行的Varnish實例中。
        因爲VCL的編譯是在子進程以外完成的，因此不會無心中加載格式不正確的VCL，從而影響正在運行的Varnish實例。
        所以，運行Varnish時更改配置很是方便，新的VCL的政策會當即生效，可是，所使用的舊配置緩存的對象可能會一直存在，直到它們沒有了舊的引用或新的配置對其執行操做爲止。
        一個已編譯的VCL文件將一直存在，直到徹底重啓Varnish，或直到管理界面發出vcl.discard命令，在使用完編譯的VCL文件後你只能刪除。
        您能夠經過讀取vcl.list參數來查看VCL引用的數量。
    
    VCL重載
        varnishd能夠從新加載VCL程序，無需從新啓動，只是從新加載VCL編譯代碼。
            service varnish reload
            systemctl reload varnish
            varnish_reload_vcl
            varnishadm vcl.load <compiledVCL> <VCLsourcecode>
            varnishadm vcl.list
            varnishadm vcl.use

varnish日誌

varnish日誌中記錄有請求，緩存和對varnish共享內存日誌（VSL）的響應信息。
    內存日誌覆蓋有兩個效果，一方面沒有歷史數據，但另外一方面卻有大量的信息以很是快的速度得到。
    固然，仍然能夠將日誌存儲在文件中。
    varnish會生成大量的數據，所以它不會將日誌默認寫入磁盤，而只會記錄到內存中。
    若是須要記錄日誌到磁盤上，能夠經過在/etc/default/varnishlog和/etc/default/varnishncsa中分別設置VARNISHNCSA_ENABLED=1來實現。

日誌工具

顯示詳細日誌： 
        varnishlog  
            用於訪問特定的數據，它提供了特定客戶的信息和要求。   
        varnishncsa     
            以NCSA通用日誌格式顯示varnish訪問日誌。   
        varnishtest     
            容許顯示測試中的日誌記錄和計數器。   
    統計工具：   
        varnishstat 
            用於訪問全局計數器，不讀取varnish日誌中的條目。 
        varnishtop  
            讀取Varnish日誌並呈現最常出現的日誌條目的不斷更新的列表。    
        varnishhist 
            讀取Varnish日誌，並顯示一個連續更新的直方圖，顯示最後N個請求的處理分佈狀況。

日誌佈局

varnish日誌事務處理如圖所示，varnishlog是最經常使用的工具之一，並採用了按TCP會話，前端或後端工做者分組的事務機制從新排序事務。
    varnishlog的各類參數是爲幫助你找到你想要的東西。使用varnishlog能夠有效地過濾varnish工做中產生的大量日誌數據。

事務處理

varnishlog -g <session|request|vxid|raw> -d 
    Varnish Transaction IDs (VXIDs，varnish 事務id)被應用於大量不一樣種類的工做項目中。   
    事務類型：   
        session：tcp 會話  
        request：前端或後端工做者處理的事務   
    varnish默認按照VXID來分組，1是後端請求BeReq，2是客戶端請求Request，3是會話Session。  
    事務組
        事務組是分層的
        層級和關係
            Level 1: Client request (cache miss)
              Level 2: Backend request
              Level 2: ESI subrequest (cache miss)
                Level 3: Backend request
                Level 3: Backend request (VCL restart)
                Level 3: ESI subrequest (cache miss)
                  Level 4: Backend request
              Level 2: ESI subrequest (cache hit)