ngx_http_empty_gif_module在日志统计中的应用

日志统计分析架构

在日志统计分析中,通常包括以下的模块

前端日志上报(js上报url、user_agent等等)

打点服务器(nginx)

统计日志(access_log)

分析日志(后端程序)

保存分析结果(db)

我们通常把日志上报和日志分析解耦,利用nginx的大并发承载力,接收前端上报的日志。在这里,我们不做协议转发到后端程序(PHP或者其他cgi程序)处理日志统计,而是利用nginx的access_log,约定好日志保存格式(format),由nginx帮助我们做日志统计。

日志上报的并发量有可能非常巨大,举个例子,如果由PHP来处理,那么每一次日志上报都需要经过nginx的转发、PHP生命周期的五个阶段(MINIT、RINIT、代码处理、RSHUTDOWN、MSHUTDOWN),即使做了opcache,将预编译的脚本存储在共享内存中,也是需要不菲的消耗。1毫秒的处理时间不算什么,但是 1 X 100000n 那就需要引起关注了。

我们还需要一个分析日志的守护进程,这时候可以利用php的cli或者别的语言实现,将分析结果(pv、uv等等)保存到数据库,然后提供一个web界面来展示结果。

empty_gif 模块

http程序是请求-响应模式,日志上报完成后,后端需要返回一个值,告诉前端结果。一般来说,我们会使用json,上报一个日志,返回一个json串,比如

正如前文所说,这是有可能是一个大并发的程序,如果每次都返回一个json串,是不是有点太大了,为什么这里会说“大”,接着看,我尝试返回一个整型数字1,

在浏览器中查看返回数据的大小为 268B ,一个数字的占用就有268B,如果包含状态码,状态值,岂不是更大。

所以我们看看nginx有没有更好的解决方式,那就是ngxhttpemptygifmodule。

这是一个由nginx生成的 1x1 像素的图片,通过查看源码可以知道,这是nginx自己拼接而成的完全内存级别的图片

/path-to-nginx/src/http/modules/ngx_http_empty_gif_module.c

继续刚刚的问题,前端上报日志后,后端怎么返回这个图片呢?返回这个图片有什么好处?

只需要在nginx中配置

这样一来,前端只需要把url、ua等信息提交到 log.com/dig 即可,后端就会返回一个1pixel的图片。

通过查看浏览器信息可以发现,返回大小为 229B,是不是比返回json更快,占用更小呢 :)

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180416G0JB7I00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券