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)
 

varnish的架構和日誌