回忆 像一直开着的机器 
趁我不注意
慢慢地清晰反覆播映

-- 《三万英尺》迪克牛仔


  当航班在三万英尺的高空爬升下坠，穿越乱流，沉入海底，无人知道它在云中究竟经历了什么波折苦难，甚至无人知道它最终沉睡于何处，随着时间的变迁，也许被人渐渐遗忘。要理清一切，重拾记忆，唯一的希望便是找到那台发着微弱电波，记忆着一切的黑匣子。



   服务器网站的日志记录便是如此，它就是网站服务器的黑匣子，日常运维中我们遭遇故障往往非常依赖分析统计的日志来找到问题。像是悬疑电影中的主角，每几分钟就会忘记自己的身份自己的姓名，需要在本子上不停写字，在墙上四处张贴，在记录的时候我们还要四处张望，一旦遗漏了没有看见没法写下来，那也许明天就是末日。

  还好我们有日志，这一切都是自动化的！

  负载均衡设备在网站前端承担着统一交付业务数据的任务，是最核心的集中点，下面我们以广泛使用的NetScaler为例来探讨在网站日志运维中能够带来的帮助。


一：通过NetScaler记录网站高延迟慢响应时间


通常，网站的标准格式类似


192.35.100.21 - -[19/Jan/2016:14:47:37 -0400] "GET /NetScaler.html HTTP/1.1" 200 6553


  这样的日志可以时刻记录访问的源地址、访问时间、目标URL等。但这往往是不够的 ：除了用户这端的问题，服务器后端更是我们需要关注的部分。例如服务器性能不足响应慢，用户访问某个网页出现延迟等。当用户报来故障的时候这个访问延迟已经发生过去，如果是上述的日志格式，如何能找到那一刻出现了问题？ 

  记录了很多，可没有应该记录的关键！这一刻感觉自己失去了光明！



  要锁定故障必须可以记录服务器端当时的响应时间才可以找出罪魁祸首。

  我们需要如下这样，记录响应时间并且写入日志


Sep 7 03:04:21 <local0.alert> 127.0.0.2 09/06/2015:19:04:21 GMT myNS 0-PPE-0 : default REWRITE Message 10782 0 : "MyLog: ClientIP: 192.168.20.1:62716 ServerIP: 192.168.50.68:80 HOST: 192.168.20.67 URL: /index.asp restime: 90ms"



  这对于NetScaler来说这是非常轻松的工作，NetScaler可以直接看透传输的内容并做出分析排名，可以按照单位时间的请求，带宽，或者响应时间的排名，一目了然






当然，这样的统计也可以在文本日志中体现出来。我们可以详细规定日志的格式，并在日志输出处勾选用户自定义日志信息



   虽然我们测试时的日志简单明了生成的日志很小，但实际上拥有众多用户大型网站的日志是海量的，几小时可能就会以G级别计算。如果每条记录都记录响应时间，寻找高延迟时还是会比较困难，要动用各种工具来查询过滤。NetScaler还可以直接定义标准响应时间，仅仅在高于我们定义的延时发生后，警告才会产生并记录在日志中。

  日志的格式内容依据需求任意定义，不仅是英文，我们还可以定义出中文日志在NetScaler上直接查看




  日积月累的日志，最好有专门的日志服务器来接受，NetScaler也可以将高延迟的日志发往任意定义的远程日志服务器上，自定义地址如下：



  在服务器上便可收到高延迟警报日志，这里用的是免费的KiWi Syslog Server




因为NetScaler天然就以七层方式处理着HTTP流量，因此类似上述的动态统计完全不影响性能。



二：通过NetScaler集中统计日志


  默认的情况下，服务器日志是记录在每台服务器中的。每台设备日志的巡查极为耗时费力。我们需要分别配置每台服务器，把日志发送到集中日志服务器上去记录，定期进行文件切割，日志分析。



  如前所述，其实大多数网站的前端都部署着负载均衡系统，所有的VIP虚拟站点都落于负载均衡之上，浏览者访问服务器都必须要经过负载均衡设备，那么您有没有想过让负载均衡直接生成日志发送日志，而省去管理后端众多服务器配置的烦恼？



  NetScaler本身就具备此功能，叫做NetScaler Web Logging (NSWL)，通过单个发送点便可以输送日志。HTTP/HTTPS的日志均可以直接按W3C/NCSA 的标准格式生成，和nginx apache生成的日志完全一致。可按照规定的变量调整格式。日志可发向我们常用的Linux，Windows，FreeBSD系统。



@Netscaler_Insight


我们还可以定义每个日志文件的生成周期（例如每天 每小时），生成文件大小（例如100M  1G），日志文件名称（例如Exmmyydd.log ），虚拟主机名称（例如 www.netscaler.com ）并不需要通过自己编辑的脚本来切割日志。



三：通过Appflow可视化日志



  在90年代，Cisco为运营商和企业开发了网络流量分析统计协议Netflow，无需探针，对CPU和网络要求低且功能丰富。历经多个版本升级优化，Netflow V9被IETF组织从5个候选方案中确定为IPFIX(IP FlowInformation Export)标准。NetFlow被广泛运用于网络监控，思杰基于此标准开发了全新的多项扩展，例如应用层参数，网页性能参数，数据库参数等

wKioL1bb6ZHC_jeTAAKUaUBidSQ930.png


利用这些搜集到的数据，NetScaler Insight将应用层信息搜集统计，以强大的可视化图表展示出来

 

例如，访问地理位置，消耗带宽和平均响应时间


wKioL1bb6lmwgNWmAAGxK38fxLA931.png


访问来源IP


wKiom1bb6dvgyZjfAABeWoHBHag045.png


请求数量曲线


wKiom1bb6dzhWuGcAACdkQ2lNNw208.png


也可以针对具体业务做出统计

wKioL1bb6luw7A9BAABeCvOv0mg589.png


进入具体业务，可以进行具体URL和客户端的分析，可以看到每个url的命中次数，渲染时间，加载时间等

wKiom1bb6d3AlpbiAACD3_WtVJo174.png


进入具体的URL，可以看到时间曲线图


wKioL1bb6nzAnvm0AADYDnrSyVo538.png


整个页面的详细分析


wKiom1bb6f6SvO4sAADLaNR-GvA347.png


访问的操作系统，浏览器类型，响应类型等等


wKioL1bb6n2BxOj8AAB9bojHZw8700.png




总结

 

   虽然运用应用交付设备的历史已有十余年，但很多使用者还是仅仅将其和负载均衡，甚至仅仅和轮询算法等价。其实随着技术发展，ADC早已成为网络看透和掌控应用层的大脑和双眼，运用好ADC才可以从网络的三四层直升进入应用层的天地。

   睁开眼的记忆是光明，闭上眼的记忆是黑暗。

   终于发现，我们并没有失忆，也没有失明，我们一直拥有着双眼，要做的仅仅是摘掉眼罩，睁开双眸。

   

 

wKioL1bb6oCSJuPoAAYRKmSRFOE567.png