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)