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的架构和日志的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。