CN111162956B

CN111162956B - 一种日志记录方法及装置

Info

Publication number: CN111162956B
Application number: CN201811324793.7A
Authority: CN
Inventors: 杜振训; 蒋铁柱; 巩仔明; 邱慧
Original assignee: Youxin Shuxiang Beijing Information Technology Co ltd
Current assignee: Youxin Shuxiang Beijing Information Technology Co ltd
Priority date: 2018-11-08
Filing date: 2018-11-08
Publication date: 2021-07-30
Anticipated expiration: 2038-11-08
Also published as: CN111162956A

Abstract

本申请提供了一种日志记录方法及装置。其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名。该方法可以包括：服务端获取用户端的HTTP请求头携带的目标用户令牌；服务端分析目标用户令牌在服务端缓存中是否存在，如果目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；如果用户端访问的域名与目标域名匹配，则服务端对用户端访问的域名开启日志记录功能。从而，仅当用户端的HTTP请求头携带的用户令牌和用户端访问的域名与服务端缓存的用户令牌和对应域名相匹配时，服务端才会开启日志记录功能，解决了现有技术中无法针对特定用户的网络访问行为记录日志的问题。

Description

一种日志记录方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种日志记录方法及装置。

背景技术

网站上线运行后，提供网站资源的服务端(例如：WEB服务器和缓存服务器)可以开启日志记录功能，例如记录服务端程序运行时所执行的数据操作语句、加载的文件、程序运行事件、占用内存大小等，以及用户端的IP地址、请求事件、访问的域名、HTTP来源地址等。网站的开发人员和维护人员通过查看和分析日志，可以了解网站运行各个时刻的服务端的运行状况，从而为开发人员优化网站性能提供参考。

现有技术中，开发人员如果希望获取网站运行的日志，可以开启服务端程序的日志记录功能。但是，如果对线上运行的网站启用日志记录功能，无论是开发人员还是普通用户访问网页，服务端程序都会记录日志。当有大量的用户访问网页时，服务端程序会频繁地记录大量日志，消耗有限的***资源，降低服务端的运行效率，从而导致网页响应速度下降，影响用户的使用体验。并且，由于用户对网站的访问量通常远大于开发人员对网站的访问量，导致服务端程序记录的日志大部分都是根据用户访问的行为而生成的，然而这些用户对日志并不感兴趣，也没有需求，因此，服务端记录的日志大部分都是冗余的日志，在消耗***资源的同时，还提高了开发人员查阅日志的难度。

然而，当对线上运行的网站启用日志记录功能时，如何针对开发人员的网络访问行为记录日志，还没有一个有效的解决方案。

发明内容

本申请实施例提供了一种日志记录方法及装置，以解决现有技术中无法针对特定用户的网络访问行为记录日志的问题。

第一方面，本申请提供了一种日志记录方法，应用于服务端，其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名，该方法具体包括：

服务端获取用户端的HTTP请求头携带的目标用户令牌；

服务端分析目标用户令牌在服务端缓存中是否存在；

如果目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；

如果用户端访问的域名与目标域名匹配，则服务端对用户端访问的域名开启日志记录功能。

第二方面，本申请提供了一种日志记录装置，应用于服务端，其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名，该装置具体包括：

获取模块，用于获取用户端的HTTP请求头携带的目标用户令牌；

第一匹配模块，用于分析目标用户令牌在服务端缓存中是否存在；

第二匹配模块，用于如果目标用户令牌在服务端缓存中存在，则分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；

执行模块，如果用户端访问的域名与目标域名匹配，则对用户端访问的域名开启日志记录功能。

由以上技术方案可知，本申请提供了一种日志记录方法及装置。其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名。该方法具体可以包括：服务端获取用户端的HTTP请求头携带的目标用户令牌；然后，服务端分析目标用户令牌在服务端缓存中是否存在，如果目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；最后，如果用户端访问的域名与目标域名匹配，则服务端对用户端访问的域名开启日志记录功能。从而，本申请提供的技术方案，当用户访问网站时，仅当用户端的HTTP请求头携带的用户令牌和用户端访问的域名与服务端缓存的用户令牌和对应域名相匹配时，服务端才会开启日志记录功能，由此，解决了现有技术中无法针对特定用户的网络访问行为记录日志的问题。

第三方面，本申请提供了一种日志记录方法，应用于用户端，该方法具体包括：

用户端获取当前用户拥有的用户令牌；

用户端向服务端发送HTTP请求头，HTTP请求头携带用户令牌，用户令牌用于指示服务端开启日志记录功能。

第四方面，本申请提供了一种日志记录装置，应用于用户端，该装置具体包括：

获取模块，用于获取当前用户的用户令牌，用户令牌由服务端生成；

发送模块，用于向服务端发送HTTP请求头，HTTP请求头携带用户令牌，用户令牌用于指示服务端开启日志记录功能。

由以上技术方案可知，本申请提供了一种日志记录方法及装置。首先，用户端获取当前用户拥有的用户令牌；然后，用户端向服务端发送HTTP请求头，HTTP请求头携带用户令牌，用户令牌用于指示服务端开启日志记录功能。由此，拥有用户令牌的用户，能够通过用户端向服务端发送携带有用户令牌的HTTP请求头，使服务端根据用户令牌开启日志记录功能，而对于服务端来说，当用户访问网站时，仅当用户端的HTTP请求头携带的用户令牌和用户端访问的域名与服务端缓存的用户令牌和域名相匹配时，才会开启日志记录功能，由此，解决了现有技术中无法针对特定用户的网络访问行为记录日志的问题。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种日志记录方法的流程图；

图2为本申请实施例提供的一种日志记录方法步骤S130的流程图；

图3为本申请实施例提供的一种日志记录方法步骤S140的流程图；

图4为本申请实施例提供的用户端的数据流转示意图；

图5为本申请实施例提供的一种日志记录方法的流程图；

图6为本申请实施例提供的一种日志记录方法步骤S210的流程图；

图7为本申请实施例提供的一种日志记录装置的示意图；

图8为本申请实施例提供的一种日志记录装置的第二匹配模块330的示意图；

图9为本申请实施例提供的一种日志记录装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

网站上线运行后，提供网站资源的服务端(例如：WEB服务器和缓存服务器)可以开启日志记录功能，例如记录服务端程序运行时所执行的数据操作语句、加载的文件、程序运行事件、占用内存大小等，以及用户端的IP地址、请求事件、访问的域名、HTTP来源地址等。

为了解决上述问题，一些方案提出将服务端的日志记录功能在测试环境中开启。但是，在测试环境中，服务端连接的用户端数量和服务器产生的负载等与生产环境中的实际情况有很大差距，因此，在测试环境得到的日志无法反映出服务端在生产环境中的真实性能。

另一些方案提出，当用户登陆网站之后，在开启日志记录功能。但是，许多网站是不需要用户登陆的，因此，这种方案的可行性不高。

还有一些方案提出，在服务端的后台设置一个开关，用来控制服务端开启或关闭日志记录功能。这种方案的缺陷在于，一旦后台开关被开启，包括开发人员和普通用户在内的所有网站用户的访问行为都会被服务端记录日志，因此会导致服务端的负载过大，降低服务端的响应速度，并导致日志量冗余。另外，如果用户忘记关闭开关，服务端会一直记录日志，有可能导致服务端内存溢出等风险的发生。

可见，现有技术提出的一些方案均无法解决现有技术存在的问题。

本申请实施例提供了一种日志记录方法，该方法可以应用于服务端。其中，服务端例如可以包括WEB服务器等，用于提供网站的数据资源，以及记录服务端程序产生的日志。

具体地，本申请实施例提供的日志记录方法在服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名。用户令牌和用户令牌对应的域名例如可以缓存在WEB服务器的RAM(random access memory，随机存取存储器)中，也可以缓存在WEB服务器的HDD(harddisk drive，硬盘)中，或者缓存在WEB服务器的flash memory(快闪存储器，例如SSD(solid-state drive，固态硬盘)等)中。

示例地，参见表1，用户令牌和用户令牌对应的域名可以是以数据表的形式缓存：

Key	Value
		logToken：Ado	admin.xin.com
logToken：Tomas	wx.qlogo.cn
		logToken：Nick	nexus.officeapps.live.com

表1服务端缓存的用户令牌和域名

如表1所示，服务端缓存的用户令牌和域名以“Key-Value”的形式成对存储。其中，“Key”和“Value”为数据键的名称，数据键“Key”的键值为用户令牌的名称，数据键“Value”的键值为用户令牌对应的域名。具体地，例如在“Key”的键值“logToken：Ado”中，“logToken”是用户令牌的声明标识，表示该键值是一个用户令牌，“Ado”是用户的名称，表示该用户令牌属于用户Ado；进一步地，例如“Value”的键值“admin.xin.com”表示用户令牌“logToken：Ado”对应的域名。

另外，在一些实施例中，每个用户令牌可以对应一个或多个域名，示例地，参见表2：

Key	Value
		logToken：Ado	img.xin.com
logToken：Ado	admin.xin.com
		logToken：Tomas	wx.qlogo.cn
logToken：Nick	nexus.officeapps.live.com

表2服务端缓存的用户令牌和域名

如表2所示，“Key”具有两个相同的键值“logToken：Ado”，对应“Value”的两个键值，由此，用户令牌“logToken：Ado”所对应的域名有两个。从而，通过一个用户令牌对应多个域名的方式，用户可以通过同一个用户令牌指示服务端对多个域名开启日志记录功能。

另外，在一些实施例中，每个用户可以拥有一个或多个用户令牌，示例地，参见表3：

表3服务端缓存的用户令牌和域名

如表3所示，“Key”存在两个键值“logToken：Ado_0”和“logToken：Ado_1”，表示用户Ado拥有两个用户令牌，这两个用户令牌分别对应不同的域名。从而，用户可以根据自身需求使用不同的用户令牌，以实现对不同的域名开启日志记录功能。

进一步地，在一些实施例中，可以使用Redis存储用户令牌和域名。Redis是一个使用ANSI C编写的支持网络、基于内存、可选持久性的键值对存储数据库。在Redis中用户令牌和用户令牌对应的域名以“Key-Value”键值对的形式存储，Redis数据库例如可以缓存在WEB服务器的RAM(random access memory，随机存取存储器)中，利用RAM远胜于HDD(harddisk drive，硬盘)和flash memory(快闪存储器，例如SSD(solid-state drive，固态硬盘)等)的高速存取能力，实现用户令牌和域名的高速存储和读取；此外，当Redis数据库存储在RAM中时，利用RAM的易失性，实现用户令牌和域名的临时存储，用户可以在服务端临时配置需要使用的用户令牌和域名，并能够在使用用户令牌和域名之后随时抹除其使用的用户令牌和域名等数据，防止用户令牌被第三人盗用，保证用户口令牌的安全性。另外，Redis数据库例如也可以持久地存储在WEB服务器的HDD(hard disk drive，硬盘)中，或者缓存在WEB服务器的flash memory(快闪存储器，例如SSD(solid-state drive，固态硬盘)等)中，从而，即使WEB服务器发生失电等意外故障之后，用户令牌和域名也不会被抹除，并能够记录意外故障时的日志数据，为用户分析故障原因提供更全面的参考数据。

进一步地，用户令牌除了以上述示出的键值对的数据格式缓存之外，还可以包括其他数据格式，例如：

一种示例的非结构化的数据格式可以是：

“logToken：Ado；img.xin.com”

“logToken：Tomas；wx.qlogo.cn”

当每个用户令牌可以对应多个域名时，上述示例的非结构化的数据格式可以是：

“logToken：Ado；img.xin.com，admin.xin.com”

当每个用户可以拥有多个用户令牌时，上述示例的非结构化数据可以是：

“logToken：Ado_1；img.xin.com|Ado_2：admin.xin.com”

需要补充说明的是，上述示出的用户令牌和域名的存储方式和数据格式仅是本申请实施例示出的一部分实施方式，而不是全部实施方式，本领域普通技术人员在本申请实施例示出的有关用户令牌和域名技术设计和构思下，还可以设计出其他的实施方式，能够应用在此处的设计和构思均没有超出本申请实施例的保护范围。

图1为本申请实施例提供的一种日志记录方法的流程图。

在服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名的情况下，本申请实施例提供的日记记录方法如图1所示可以包括以下步骤：

步骤S110，服务端获取用户端的HTTP请求头携带的目标用户令牌。

具体地，用户可以在用户端添加自己的拥有的目标用户令牌，用户端向服务端发送HTTP请求之前，首先向在HTTP请求头中添加目标用户令牌，然后再将添加了用户令牌的HTTP请求头发送给服务端，从而，服务端可以从接收到的HTTP请求头中获取该目标用户令牌。

HTTP请求头(HTTP header fields)是HTTP(hypertext transfer protocol，超文本传输协议)用户端程序(例如：WEB浏览器)向WEB服务器(服务端)发送请求时，用来指示请求类型的信息。当用户在服务端的WEB浏览器的地址栏中输入一个网站的域名，或者通过在WEB浏览器中的操作触发一个域名访问请求时，WEB浏览器根据该域名创建并向WEB服务器发送HTTP请求，该HTTP请求的HTTP请求头中包含用户要访问的域名以及WEB浏览器的信息等。当WEB服务器接收到这个HTTP请求时，会解析HTTP请求头中的域名和其他信息。

示例地，当用户Ado在浏览器的地址栏中输入的域名为“img.xin.com”时，服务端在HTTP请求头中添加用户Ado的目标用户令牌“logToken：Ado”的结果为(HTTP请求头中的其他信息未予示出)：

“

……

Host：img.xin.com

logToken：Ado

……

”

其中“Host：img.xin.com”表示用户端向服务端请求访问的域名为“img.xin.com”，“logToken：Ado”为用户Ado的目标用户令牌。

进一步地，当服务端接收到用户端发送的HTTP请求头时，可以首先对HTTP请求头的内容进行校验，分析HTTP请求头中是否包含“logToken”字段，如果不包含“logToken”字段，则服务端不会对用户端当前访问的域名开启日志记录功能，如果包含“logToken”字段，则执行步骤S120。

由此，服务端通过对分析HTTP请求头中是否包含“logToken”字段，对用户端发送的HTTP请求头进行了第一次校验，在HTTP请求头不包含“logToken”字段时，服务端不会开启日志记录功能，那么，当服务端在生产环境中运行时，由于普通用户不拥有用户令牌，服务端不会就对普通用户的网络访问行为记录日志。

步骤S120，服务端分析目标用户令牌在服务端缓存中是否存在。

当服务端从HTTP请求头中获取到目标用户令牌时，服务端将目标用户令牌与自身缓存的用户令牌进行匹配，以分析目标用户令牌在服务端缓存中是否存在。

示例地，服务端通过Redis数据库缓存了内容如表1所示的用户令牌和域名，那么，当服务端从用户端发送的HTTP请求头中获取了内容为“logToken：Ado”的目标用户令牌时，服务端使用“logToken：Ado”去匹配Redis数据库的数据键“Key”拥有的所有键值，由此，能够匹配到键值“logToken：Ado”，从而说明目标用户令牌“logToken：Ado”存在于服务端缓存中，从而执行步骤S130。进一步地，如果服务端使用“logToken：Ado”无法在Redis数据库匹配到对应的键值，则说明目标用户令牌“logToken：Ado”在服务端缓存中不存在，服务端不会为用户Ado的网络访问行为记录日志。

步骤S130，如果目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配。

具体地，如果目标用户令牌在服务端缓存中存在，则服务端从HTTP请求头中获取用户端访问的域名的域名，并将该域名与服务端缓存的目标用户令牌所对应的目标域名进行匹配。

示例地，当目标用户令牌为“logToken：Ado”，并且服务端从用户端的HTTP请求头中获取的域名为：admin.xin.com时，如表1所示，如果服务端缓存的目标用户令牌“logToken：Ado”对应的目标域名为“admin.xin.com”，则说明用户端访问的域名与目标域名相匹配，应进一步执行步骤S140；如果服务端缓存的目标用户令牌“logToken：Ado”对应的目标域名为其他内容，则说明用户端访问的域名与目标域名不匹配，服务端不会开启日志记录功能。

需要补充说明的是，由于用户在浏览网站时通常会连续打开或者跳转多个网页，从而发起多个包含不同域名的HTTP请求，那么，如果用户希望服务端对这些域名均开启日志记录的话，就需要将这些域名都缓存到服务端，导致服务端缓存的域名数量过多，降低域名匹配效率。

示例地，用户Ado希望对“www.xin.com/app/”以及“www.xin.com/app/sj”这两个域名开启日志记录功能，那么用户需要在服务端缓存如表4的内容：

Key	Value
		logToken：Ado	www.xin.com/app/
logToken：Ado	www.xin.com/app/sj

表4服务端缓存的用户令牌和域名

那么，如果用户希望服务端记录日志的域名更多，表4的数据量也就更多，不利于提高匹配效率，也不利于维护管理。

由此，在一个实施例中，为了减少服务端缓存的域名的数量，提高匹配效率，本申请实施例还提供了一些可实现的域名匹配方法，例如，父级域名匹配方法：只要服务端缓存的目标域名的全字与用户端访问的域名的父级域名相同，就认为两个域名匹配。

示例地，服务端缓存了如下表5所示的内容：

Key	Value
		logToken：Ado	www.xin.com/app/

表5服务端缓存的用户令牌和域名

那么，当用户端访问的域名为www.xin.com/app/时，用户端访问的域名与服务端缓存的目标域名相同，因此，两个域名匹配。当用户端请求的域名为www.xin.com/app/sj时，其父级域名www.xin.com/app/与服务端缓存的目标域名相同，因此，两个域名也匹配。由此，通过上述父级域名匹配方法，如果要对多个拥有共同父级域名的网页开启日志记录功能，只需要将这些域名共同的父级域名作为目标域名缓存在服务端即可，从而，能够减少服务端需要缓存的域名数量，提高匹配效率。

步骤S140，如果用户端访问的域名与目标域名匹配，则服务端对用户端访问的域名开启日志记录功能。

其中，用户可以根据自身需求配置服务端记录日志的内容，例如：服务端在响应一次HTTP请求中执行了哪些SQL(structured query language，结构化查询语句)语句，加载了那些文件，执行了哪些程序，以及程序的执行时间、占用内存(RAM)大小、处理器利用率等。

由以上技术方案可知，本申请提供了一种日志记录方法。其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名。该方法具体可以包括：服务端获取用户端的HTTP请求头携带的目标用户令牌；然后，服务端分析目标用户令牌在服务端缓存中是否存在，如果目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；最后，如果用户端访问的域名与目标域名匹配，则服务端对用户端访问的域名开启日志记录功能。从而，本申请提供的方法，当用户访问网站时，仅当用户端的HTTP请求头携带的用户令牌和用户端访问的域名与服务端缓存的用户令牌和对应域名相匹配时，服务端才会开启日志记录功能，由此，解决了现有技术中无法针对特定用户的网络访问行为记录日志的问题。

图2为本申请实施例提供的一种日志记录方法步骤S130的流程图。

在一个实施例中，服务端对缓存的用户令牌设置有效期，步骤S130如图2所示可以包括以下步骤：

步骤S131，如果目标用户令牌在服务端缓存中存在，则服务端根据有效期分析目标用户令牌是否有效。

具体地，服务端在为用户创建用户令牌时，可以记录用户令牌创建的时间，并设置用户令牌的有效期，使用户令牌在有效期过后自动失效。其中，服务端可以对所有的用户令牌设置相同的有效期，例如，有效期为10分钟；也可以对每个用户令牌或者每个用户的用户令牌设置不同的有效期，例如，对用户Ado的用户令牌设置有效期为10分钟，对用户Tomas的用户令牌设置有效期为20分钟，等等。

示例地，用户Ado的用户令牌“logToken：Ado”在服务端创建的时间为2019年1月1日11：30：00，有效期为10分钟。如果服务端在2019年1月1日11：37：45获取了携带目标用户令牌“logToken：Ado”HTTP请求头，该用户令牌是有效的，执行步骤S132。如果服务端在2019年1月1日11：40：01获取了携带目标用户令牌“logToken：Ado”的HTTP请求头，该目标用户令牌是无效的，服务端不会开启日志记录功能。

步骤S132，如果目标用户令牌有效，则服务端分析用户端访问的域名与目标域名是否匹配。

具体地，如果目标用户令牌有效，则服务端从HTTP请求头中获取用户端访问的域名，并将该域名与服务端缓存的目标用户令牌所对应的目标域名进行匹配。具体匹配方法请参见本申请实施例对步骤S130阐述的内容，此处不再赘述。

由此，通过对用户令牌设置有效时间，使用户令牌在使用后及时失效，防止用户令牌在意外泄露的情况下被他人利用；同时，也能够限制服务端记录日志的时长，防止用户在忘记关闭服务端的日志记录功能时，服务端一直记录日志的情况发生。

在一个实施例中，服务端对用户端访问的域名开启日志记录功能时，重置缓存的目标用户令牌的有效期。从而，如果服务端没有继续获取到携带目标用户令牌的HTTP请求头，那么目标用户令牌会在有效期满后失效，服务端记录日志的时长将等于一个有效期的时长；如果服务端继续获取到携带目标用户令牌的HTTP请求头，那么目标用户令牌的有效期会被继续重置，服务端就会持续记录日志。从而，既能够保证服务端在用户端有活动的网络访问行为期间持续记录日志，又能够保证服务端在用户端停止网络访问之后，及时关闭日志记录功能，释放***资源。

图3为本申请实施例提供的一种日志记录方法步骤S140的流程图。

在一个实施例中，如图3所示，步骤S140可以包括以下步骤：

步骤S141，服务端监测缓存的目标用户令牌是否在有效期内。

具体地，服务端在开启日志记录功能后，持续监测目标用户令牌是否在有效期内。

示例地，目标用户令牌的创建时间为2019年1月1日11：30：00，有效期为10分钟。如果服务端设置在开启日志记录功能时不重置目标用户令牌的有效期，那么，该目标用户令牌的有效期为2019年1月1日11：30：00-2019年1月1日11：39：59；如果服务端设置了开启日志记录功能时重置目标用户令牌的有效期，那么，该用户目标令牌的有效期为重置时刻之后的10分钟之内。

步骤S1411，如果在有效期内，服务端保持日志记录功能为开启状态。

步骤S1412，如果不在有效期内，服务端关闭日志记录功能。

由此，既能够保证服务端在用户端有活动的网络访问行为期间持续记录日志，又能够保证服务端在用户端停止网络访问之后，及时关闭日志记录功能，释放***资源。

图4为本申请实施例提供的用户端的数据流转示意图。

在一个实施例中，如图4所示，用户端设置有代理服务器，代理服务器用于向用户端的HTTP请求头中添加用户令牌之后，将HTTP请求头发送给服务端，从而，服务端从代理服务器发送的HTTP请求头中获取目标用户令牌。

具体地，用户可以在用户端的WEB浏览器执行输入或点击等操作，以产生指向某个域名的HTTP请求，该HTTP请求携带HTTP请求头，代理服务器首先获取该HTTP请求，并在HTTP请求头中添加预先配置好的目标用户令牌，然后，再将添加了目标用户令牌的HTTP请求头发送给服务端。由此，当有多个用户需要开启服务端的日志记录功能时，只需要在代理服务器中配置自身拥有的目标用户令牌即可，使用灵活，便于维护。

本申请实施例提供了一种日志记录方法，该方法可以应用于用户端。

图5为本申请实施例提供的一种日志记录方法的流程图。如图5所示，该方法具体包括以下步骤：

步骤S210，用户端获取当前用户拥有的用户令牌。

具体地，合法的用户令牌应该由服务端生成并分发给用户，用户拿到该用户令牌之后，可以将用户令牌输入到用户端，使用户端获取并记录用户令牌。用户令牌的数据格式和生成方式等内容请参见本申请实施例在先阐述的内容，此处不再赘述。

步骤S220，用户端向服务端发送HTTP请求头，HTTP请求头携带用户令牌，用户令牌用于指示服务端开启日志记录功能。

由以上技术方案可知，本申请提供了一种日志记录方法。首先，用户端获取当前用户拥有的用户令牌；然后，用户端向服务端发送HTTP请求头，HTTP请求头携带用户令牌，用户令牌用于指示服务端开启日志记录功能。由此，拥有用户令牌的用户，能够通过用户端向服务端发送携带有用户令牌的HTTP请求头，使服务端根据用户令牌开启日志记录功能，而对于服务端来说，当用户访问网站时，仅当用户端的HTTP请求头携带的用户令牌和用户端访问的域名与服务端缓存的用户令牌和域名相匹配时，才会开启日志记录功能，由此，解决了现有技术中无法针对特定用户的网络访问行为记录日志的问题。

图6为本申请实施例提供的一种日志记录方法步骤S210的流程图。

在一个实施例中，如图4所示，用户端设置有代理服务器。步骤S210图6所示可以包括以下步骤：

步骤S211，用户端在代理服务器中配置当前用户的用户令牌。

例如，代理服务器可以是Charles，Charles一个HTTP代理服务器，当用户端的浏览器连接Charles访问互联网时，Charles可以监控浏览器发送和接收的所有数据，Charles允许用户查看经由Charles发送和接收的HTTP通信，例如：HTTP请求(HTTP request)、HTTP响应(HTTP response)和HTTP请求头等。

由此，用户在代理服务器中配置当前用户的用户令牌，从而允许代理服务器在用户端浏览器发送的HTTP请求头中添加用户令牌，并将添加了用户令牌的HTTP请求头发送给服务端。

另外，需要补充说明的是，如果HTTP请求头为HTTPS(hypertext transferprotocol secure，超文本安全传输协议)请求头，还需要为代理服务器安装CA证书(certification authority)，从而使代理服务器能够成功解密到HTTPS请求头中的信息，以顺利添加用户令牌。

步骤S212，用户端将代理服务器的地址设置为发送HTTP请求头的目标地址。

由此，用户端不会将HTTP请求头直接发送给服务端，而是发送给目标地址，即代理服务器，从而使代理服务器将用户令牌添加到HTTP请求头中，并将添加了用户令牌的HTTP请求头转发给服务端。

下面是本申请的装置实施例，可用于执行本申请的方法实施例，该装置包括用于执行本申请的方法实施例的各个步骤的软件模块。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

本申请实施例提供了一种日志记录装置，应用于服务端。其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名。

图7为本申请实施例提供的一种日志记录装置的示意图。如图7所示，该装置包括：

获取模块310，用于获取用户端的HTTP请求头携带的目标用户令牌；

第一匹配模块320，用于分析目标用户令牌在服务端缓存中是否存在；

第二匹配模块330，用于如果目标用户令牌在服务端缓存中存在，则分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；

执行模块340，如果用户端访问的域名与目标域名匹配，则对用户端访问的域名开启日志记录功能。

由以上技术方案可知，本申请提供了一种日志记录装置，应用于服务端。其中，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名。该装置用于获取用户端的HTTP请求头携带的目标用户令牌；然后，分析目标用户令牌在服务端缓存中是否存在，如果目标用户令牌在服务端缓存中存在，则分析用户端访问的域名与服务端缓存的目标用户令牌对应的目标域名是否匹配；最后，如果用户端访问的域名与目标域名匹配，则对用户端访问的域名开启日志记录功能。从而，本申请提供的装置，当用户访问网站时，仅当用户端的HTTP请求头携带的用户令牌和用户端访问的域名与服务端缓存的用户令牌和对应域名相匹配时，服务端才会开启日志记录功能，由此，解决了现有技术中无法针对特定用户的网络访问行为记录日志的问题。

图8为本申请实施例提供的一种日志记录装置的第二匹配模块330的示意图。

在一个实施例中，如图8所示，第二匹配模块330包括：

有效期分析子模块331，用于如果所述目标用户令牌在服务端缓存中存在，则根据所述有效期分析所述目标用户令牌是否有效。

域名匹配子模块332，用于如果所述目标用户令牌有效，则分析用户端访问的域名与所述目标域名是否匹配。

本申请实施例提供了一种日志记录装置，应用于用户端。

图9为本申请实施例提供的一种日志记录装置的示意图。如图9所示，该装置包括：

获取模块410，用于获取当前用户的用户令牌，用户令牌由服务端生成；

发送模块420，用于向服务端发送HTTP请求头，HTTP请求头携带用户令牌，用户令牌用于指示服务端开启日志记录功能。

本领域技术人员在考虑说明书及实践这里公开的申请后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims

1.一种日志记录方法，应用于服务端，其特征在于，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名，所述方法包括：

服务端获取用户端的HTTP请求头(HTTP header fields)携带的目标用户令牌；

服务端分析所述目标用户令牌在服务端缓存中是否存在；

如果所述目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的所述目标用户令牌对应的目标域名是否匹配；

如果用户端访问的域名与所述目标域名匹配，则服务端对用户端访问的域名开启日志记录功能。

2.根据权利要求1所述的方法，其特征在于，服务端对缓存的用户令牌设置有效期，所述如果目标用户令牌在服务端缓存中存在，则服务端分析用户端访问的域名与服务端缓存的所述目标用户令牌对应的目标域名是否匹配，包括：

如果所述目标用户令牌在服务端缓存中存在，则服务端根据所述有效期分析所述目标用户令牌是否有效；

如果所述目标用户令牌有效，则服务端分析用户端访问的域名与所述目标域名是否匹配。

3.根据权利要求2所述的方法，其特征在于，所述服务端对用户端访问的域名开启日志记录功能，还包括：

服务端重置缓存的所述目标用户令牌的有效期。

4.根据权利要求2或3所述的方法，其特征在于，所述服务端对用户端访问的域名开启日志记录功能，包括：

服务端监测缓存的所述目标用户令牌是否在有效期内；

如果在有效期内，服务端保持日志记录功能为开启状态；

如果不在有效期内，服务端关闭日志记录功能。

5.根据权利要求1所述的方法，其特征在于，用户端设置有代理服务器，所述代理服务器用于向用户端的HTTP请求头中添加所述目标用户令牌之后，将所述HTTP请求头发送给服务端，所述服务端获取用户端的HTTP请求头携带的目标用户令牌，包括：

服务端从所述代理服务器发送的HTTP请求头中获取所述目标用户令牌。

6.一种日志记录方法，应用于用户端，其特征在于，所述方法包括：

用户端获取当前用户拥有的用户令牌；

用户端向服务端发送HTTP请求头，所述HTTP请求头携带所述用户令牌，所述用户令牌用于指示所述服务端开启日志记录功能。

7.根据权利要求6所述的方法，其特征在于，用户端设置有代理服务器，所述用户端获取当前用户拥有的用户令牌，包括：

用户端在代理服务器中配置当前用户的用户令牌；

用户端将代理服务器的地址设置为发送HTTP请求头的目标地址。

8.根据权利要求7所述的方法，其特征在于，所述用户端向服务端发送HTTP请求头，所述HTTP请求头携带所述用户令牌，包括：

用户端根据所述目标地址向所述代理服务器发送HTTP请求头，所述代理服务器用于向所述HTTP请求头中添加用户令牌，并将所述HTTP请求头转发给服务端。

9.一种日志记录装置，应用于服务端，其特征在于，服务端缓存有至少一个用户的用户令牌和用户令牌对应的域名，所述装置包括：

第一匹配模块，用于分析所述目标用户令牌在服务端缓存中是否存在；

第二匹配模块，用于如果所述目标用户令牌在服务端缓存中存在，则分析用户端访问的域名与服务端缓存的所述目标用户令牌对应的目标域名是否匹配；

执行模块，如果用户端访问的域名与所述目标域名匹配，则对用户端访问的域名开启日志记录功能。

10.一种日志记录装置，应用于用户端，其特征在于，所述装置包括：

获取模块，用于获取当前用户的用户令牌，所述用户令牌由服务端生成；

发送模块，用于向服务端发送HTTP请求头，所述HTTP请求头携带所述用户令牌，所述用户令牌用于指示所述服务端开启日志记录功能。