Web应用的日志及其使用场景

作者: 一进制 | 来源:发表于2017-12-30 14:13 被阅读0次
    日志就是数据

    日志是数据,数据却不一定是日志。日志主要用于记录发生过的事件,写入和查询是常用操作,不推荐对其进行修改操作,日志过量或者过期的时候,需要清理。

    日志是应用不可分割的一部分,没有日志的应用是残缺的。依赖日志,我们可以追溯故障、找出BUG、统计数据和分析用户行为。适当的日志可以提供帮助,日志太少和太多都会造成不良影响。

    本文讨论了Web应用的HTTP日志、应用日志和用户日志。

    HTTP日志

    正规部署的Web应用,都会使用类似Nginx, Apache这样的Web服务器来做反向代理以及负载均衡。这样一来,就由这一层服务来搜集HTTP日志。即便是开发模式下,使用开发Web服务器,也会产生HTTP日志。一般的HTTP日志,至少会包含这些字段:日志产生时间、HTTP method、url path、HTTP协议版本、响应状态码、响应字节大小、访问者ip、代理服务器ip、请求处理耗时、Referrer、User Agent。

    • 根据访问者ip、代理服务器ip分析用户身份

      • 我们知道,访问Web服务的过程中,用户发起的请求,可能会经过层层转发之后,才能抵达最终的Web内容提供者的服务器。每次请求转发,实际上是代理服务器发起一个新的请求,对接的服务器识别到的访问者ip就会变成代理服务器的ip,为了解决这个问题,代理服务器会将原始请求客户端的ip也保存起来,一并添加到转发的请求中。这样一来,最终内容提供者的服务器就会识别到两个ip,一个是访问者ip,另一个是代理服务器ip。

      • 互联网上,部分访问者不愿意提供自身的真实信息(这类人包含隐私保护用户和黑客等),就会使用代理服务器掩盖自身的真实ip,或者是伪造虚假的ip,我们可以从访问日志中初窥端倪。

      • 日志中只有访问者ip,没有代理服务器ip,可以判断:该访问者的访问不经过代理服务器,或者该访问者是一个高匿名的代理服务器;日志中的访问者ip和代理服务器ip相同,可以判断:该访问者使用了匿名代理服务器;日志中的访问者ip和代理服务器ip不同,可以判断:该访问者使用了透明代理服务器,或者该访问者使用了欺骗性代理服务器。

    • 根据访问者ip短时间的出现次数,判断是否受到攻击

      • 每个网站,根据其流行程度,可以制定出一份不同时间间隔、正常访问量阈值的报表。对比这份报表,和我们监控的每个ip在单位时间范围内的访问量,我们可以分析出该ip是否正在进行违规访问操作。

      • 例如,某个ip在一分钟之内访问网站1000次,而其他ip只有每分钟几十次,正常阈值是100,那么这个ip就可以划入重点监控范围,继续分析其访问的url path,访问的方法类型等,判断它是否正在违规操作,一旦确认,就可以进行封禁ip的操作。

    • 根据User Agent分析客户端类型

      • Web请求中,一般会包含一个字段用来描述发起请求的客户端版本类型信息,例如Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36,有的Web服务器为了提高兼容性,会根据客户端的版本情况,返回不同的响应,以提高用户体验。当然,还可以根据客户端类型,统计分析网站访问者的客户端环境分布情况。

      • 各大搜索引擎,都有自己的爬虫机器人。这些爬虫机器人,会根据网站的开放情况,来爬取其网页信息,大多数开放的网站,都十分欢迎搜索引擎的爬虫机器人,借此提高其搜索排名。

      • 数据分析公司,会到感兴趣的网站上爬取内容,分析数据,生成行业报表。这种对网站内容提供者没什么好处的访问,就不那么受欢迎了,特别是数据分析公司的爬虫,不是那么规范的情况下。网站内容提供者限制非浏览器和搜索引擎爬虫之后,数据分析公司的爬虫,一般就会伪装成二者,进行内容爬取。爬虫攻防战,值得大书特书了,这里就不细说。

    • 根据响应状态码,判断请求和响应的状态

      • HTTP响应状态码,大致分为四类:成功响应200299,重定向响应300399,客户端请求错误400~499, 服务器响应错误500~599。

      • 短时间大量出现重定向响应,可以判断为网站的链接可能有反复循环的情况,可以根据url情况加以排查。

      • 短时间大量出现客户端请求错误,可以判断为:1、网站提供了错误的url path,2、爬虫机器人正在暴力扫描网站,3、网站攻击者正在攻击网站。具体情况再根据真实响应码和url判断。

      • 短时间大量出现服务器响应错误,可以判断为:1、Web应用代码出现BUG(响应码500),2、Web应用进程出现问题(响应码502),3、Web应用出现性能瓶颈(响应码504)

    • 根据url path数量分布,分析网站热点

      • 统计url path的分布,对热点url path进行排名,可以得知网站的热点在哪里,从而进行热点分流,性能优化,也可以为运营团队提供数据支撑。
    • 根据响应字节大小和请求处理耗时,分析响应缓慢的原因

      • 已知某个url path的页面访问非常慢,根据HTTP日志进行分析时,可以查看其响应字节大小和请求处理耗时。

      • 响应字节很小,比如少于1M,请求处理耗时也很少,比如少于100ms,那么:1、有可能是客户端的带宽很少,或者网络故障导致的。2、有可能该url path页面需要加载其他资源,并依赖于其他资源来显示页面,而访问其他资源缓慢导致该url path的页面缓慢。

      • 响应字节较大,比如超过10M,请求处理耗时很少,比如不超过1s,那么原因很简单,代理服务器到客户端的网络带宽限制导致的。

      • 响应字节很小,比如少于1M,请求处理耗时很大,比如超过5s,那么原因很简单,Web应用在处理该url path请求的时候,因为性能、网络、算法或数据处理量过大的原因导致的。

      • 响应字节较大,比如超过10M,请求处理耗时也很大,比如超过5s,那么原因很简单,就是文件过大导致下载缓慢。

    • 根据Referrer设置防盗链,统计流量来源

      • 我们在云平台上存储了图片,提供自己的网站使用,云平台按照资源访问量收费。这时候,其他网站盗用了我们的图片链接,我们就会为其他网站的流量付费,这时候,就需要用到防盗链。当然,我们自己网站的资源,不想提供给其他网站使用时,也可以设置防盗链。

      • 请求中带的Referrer键,其值是跳转到当前请求的上一个请求的完整url,我们在网页中嵌入了图片,加载图片时Referrer就会带上该网页的url,百度上搜索一个关键字出来的网页,上面有广告链接,点击之后,访问该广告的网页,也会在Referrer中带上百度的url。

      • 通过Web应用中,根据请求的Referrer,是否在白名单之内,来决定是否返回正确的内容,就是防盗链技术的核心思想了。如果没有提供Referrer,那就是直接访问了,网站也可以自行决定是否提供内容。当然,其他网站也可以使用伪装和匿名技术来突破防盗链的防御,所以,防盗链技术,防君子不防小人。

      • 广告网页通过Referrer统计流量来源,从而为对方付费,这就是广告来源统计和计费的核心。当然,也可以通过url上添加参数的情况来进行来源统计,例如我们常用的邀请码机制,url类似http://www.example.com/register?code=xxxxxx,其中的code=xxxxxx,就是给网站说明了,访问网页的来源。

    应用日志

    应用日志是Web应用直接产生的。应用日志可以接入到操作系统的日志系统中,例如syslog,也可以自行输出到标准输出中。Web应用产生的异常错误,会输出到标准错误输出中。由于Web应用在生产环境都是以daemon方式运行(后台运行),所以负责监控和管理Web应用进程的守护进程(例如supervisor),就要搜集这些应用日志,以便查询和分析。

    分析应用日志时,一般需要结合日志上下文进行分析,因为一旦抛出异常错误,日志一般不是一行就能记录完的。异常日志一般会以代码调用追溯的方式来展现。例如:

    RuntimeError                              Traceback (most recent call last)
    <ipython-input-5-e3097d5bf3e6> in <module>()
    ----> 1 test1()
    
    <ipython-input-2-ee75a0b1ab43> in test1()
          1 def test1():
          2     print('test1 start')
    ----> 3     test2()
          4     print('test1 end')
          5 
    
    <ipython-input-4-a2967c4ec095> in test2()
          1 def test2():
          2     print('test2 start')
    ----> 3     raise RuntimeError('runtime error')
          4     print('test2 end')
          5 
    
    RuntimeError: runtime error
    

    根据错误提示可以知道,在运行test1这个无参数的函数时,发生的异常,追溯到test1定义内部的第三行,调用test2这个无参数的函数时,再次追溯到test2定义内部的第三行,源头上,正是这里发生了异常,去掉这一行,修复异常,再次运行函数test1时,就能成功了。

    用户日志

    用户日志的产生,需要在Web应用代码中实现,常规做法,是将用户日志存储到数据库中,如果将用户日志存入到文件中,则可以归纳到应用日志中了,当然,这是一种不严谨的划分。

    我们知道,HTTP是无状态的协议,开发者利用cookie技术识别不同用户,这样一来,我们就可以区分相同客户端ip和相同电脑下的不同用户。有了更加细致的用户日志,我们可以做更加精细的统计分析。

    • 行为审计

      • 用户日志可以记录用户在网站的所有行为,包括不限于浏览页面、修改资料、发送消息、付款等等,甚至可以细化到点击了哪些按钮。通过分析这些行为,购物网站可以分析出用户大致喜欢什么类型商品,内部网站可以审计用户的操作是否符合规范等等。
    • 热点分析

      • 根据用户日志将用户进行分类,就可以分析网站更受什么样的人群的喜爱。通过用户喜爱商品的排名统计,可以分析出网站的最受欢迎的商品。根据商品销量排名,可以分析出网站的畅销商品。
    • 数据分析师可以根据这些用户日志,挖掘出更多的价值和隐藏的信息。

    总结

    本文详细讨论了HTTP日志的分析使用,并对应用日志和用户日志的常规使用做出了说明,通过阅读本文,可以对Web应用下的日志和其使用案例有了初步的了解,更多的详情,可以参考更加详细的资料。

    无戒365训练营 第八篇

    相关文章

      网友评论

        本文标题:Web应用的日志及其使用场景

        本文链接:https://www.haomeiwen.com/subject/xoqwgxtx.html