论文系统Step1:从日志记录中提取特定信息

论文系统Step1:从日志记录中提取特定信息

前言

论文数据需要，需要实现从服务器日志中提取出用户的特定交互行为信息。日志内容如下:

自己需要获取“请求数据包一行的信息”及“OUTSTR”下一行的信息。

思路

考虑使用正则表达式提取特定信息。

示例代码:

Pattern pattern = Pattern.compile("请求数据包信息:\"(.+?)\"");
Matcher matcher = pattern.matcher("请求数据包信息:\"index.html\"");
if(matcher.find())
  System.out.println(matcher.group(1));

考虑到日志中数据格式特点，利用上述方式并不可行。不过还是应该考虑使用正则解决以上问题。

初步处理后的文档内容如下:

分析以上信息，需要进一步进行处理，将每个用户的信息进行单独抽取并存入到数据库中。 作为实验，先单独获取一用户的数据。但是由于服务端返回数据无任何用户标识，而且返回信息无任何交易标识，仍需添加。需要对日志做进一步的处理操作。添加信息如下:

通过将json格式的字符串转换为json对象。并获取到指定信息，如下所示:

为了提取出每个用户的交互序列，实现方法如下:将日志中的交互序列按照用户ID分别建立相应的文件夹。将同一用户的请求与输出信息输出到同一用户ID的文件内。内容如下:

文件内容如下：

通过分析分类后的文件内容，可以发现，由于存在某些耗时交易，故会出现多个请求、输出交叉显示的情况。

针对这种情况，在服务端返回信息中加入了uid,tx_code信息，如下所示:

那么就需要将服务端返回信息与请求信息进行配对操作。

考虑到交易的混合，服务端返回信息的混合，必须假设一种理想情况之下的处理。否则，处理起来过于费劲。

{“phone”:“18353102068”}

{“result”:登陆结果}

{“classid”：分类编号}

{“pcnt”:返回数量}

{“shopid”:药店编号}

{“pcnt”:返回数量}

{null}

{“data”:广告详情}

{“advid”:广告编号}

{“url”:广告链接}

{null}

{"addrs":[{"receiver":"孙华强","tel":"18853883586","addr":"北京市北京市朝阳区112号","addrid":1}]}

{"old_billid":"","addrid":"1","shopid":"S18853883587","msg":"","yhhdid":"YH00000019","yhhdamt":2,"yhqid":"","yhqcnt":0,"yhqamt":0,"cnt":4,"meddata":[{"medid":"TH20013063","medcnt":1,"cfid":""},{"medid":"TZ44021940","medcnt":1,"cfid":""},{"medid":"TH10940251","medcnt":1,"cfid":""},{"medid":"TB20020918","medcnt":1,"cfid":""}]

｛"billid":"LM201605163586476"｝

注意其中的输入输出参数是经过筛选之后提取出来的。为此需要写一个工具类，用来提取特定的输入输出参数。

测试情景1：

输入：整理后的单用户日志

18353102068:1002-->9002-->9002-->9002-->9005-->1004-->3002

输出：静态统计表、动态统计表

测试情景2：

输入：整理后的多用户日志

18353102068:1002-->9002-->9002-->9002-->9005-->1004-->3002

18353102066:1002-->9002-->9005-->1004-->3002

输出：静态统计表、动态统计表

测试情景3：

输入：整理后的包含匿名用户日志

18353102068:1002-->9002-->9002-->9002-->9005-->1004-->3002

18353102066:1002-->9002-->9005-->1004-->3002

$tempuser:9002-->9005-->9101-->9103

输出：静态统计表、动态统计表

测试情景4：

输入：整理后的交叉请求案例日志

输出：静态统计表、动态统计表

测试情景5：

输入：整理后的单用户多阶段日志

注：测试需在case长度至少为2的情况下进行。

18353102068:1002-->9002-->9002

18353102068:1002

输出：静态统计表、动态统计表

测试情景6：

输入：整理后的多用户多阶段日志

注：测试需在case长度至少为2的情况下进行。

18353102068:1002(2016-05-16 11:27:45)-->9002-->9002(2016-05-16 11:27:47)

18353102066:1002(2016-05-16 12:27:45)-->1004-->3002(2016-05-16 12:37:54)

18353102068:1002(2016-05-17 11:27:45)

-->9002-->9002-->9002-->9005-->1004-->3002(2016-05-17 11:27:54)

18353102066:1002(2016-05-17 11:27:45)

-->9002->9005-->1004-->3002(2016-05-17 11:27:54)

输出：静态统计表、动态统计表

测试情景7：

输入：整理后的包含匿名用户多阶段日志

注：测试需在case长度至少为2的情况下进行。

1.18353102068:1002(2016-05-16 11:27:45)-->9002-->9002(2016-05-16 11:27:47)

2.18353102066:1002(2016-05-16 12:27:45)-->1004-->3002(2016-05-16 12:37:54)

3.18353102068:1002(2016-05-17 11:27:45)

-->9002-->9002-->9002-->9005-->1004-->3002(2016-05-17 11:27:54)

4.18353102066:1002(2016-05-17 11:27:45)

-->9002->9005-->1004-->3002(2016-05-17 11:27:54)

5.$tempuser:9002(2016-05-17 11:35:54)-->9005-->9101-->9103(2016-05-17 11:39:54)

6.18353102066:1002(2016-05-17 12:27:45)-->1004-->3002(2016-05-17 12:37:54)

7.$tempuser:9002(2016-05-17 12:35:54)-->9101-->9103(2016-05-17 12:39:54)

输出：静态统计表、动态统计表

测试情景8：

输入：实际用户日志

问题

 

查看日志内容：

receiver:{"version":"1.0","fore_time":"2016-05-16 20:21:04","uid":"$tempuser","tx_code":"1001"}

receiver:{"version":"1.0","fore_time":"2016-05-16 20:21:22","uid":"$tempuser","tx_code":"1002"}

实际日志中居然出现了上面的请求信息。1001为注册交易应该对应参数“phone”和“passwd”,但请求中并未包含，这是什么原因？

交易1001(注册)、1002(登录)均涉及到加密传输，在逻辑上可以解释以上现象。移动端1001(注册交易)代码如下:

var data = {};
appCallServer($http, "1001", data, function(data) {
$ionicLoading.hide();
var key = data.publickey;
// 在此调用测试加密
var passwd = password; // 用户密码提交至此
data = {
"phone": phonenum, // 用户名提交至此
"passwd": MyRsaEncrypt(key, passwd)
};
appCallServer($http, "1001", data, function(data) {
if (data.result == "0000") {
$ionicLoading.show({
template: "注册成功"
});
$timeout(function() {
$ionicLoading.hide();
$scope.gotoLogin(phonenum, password);
}, 1000);
}
});
}, function(data) {
$ionicLoading.show({
template: data.errtext
});
$timeout(function() {
$ionicLoading.hide();
}, 1000);
});

客户端实现的业务逻辑是首先调用一次1001(此次请求参数为空),获取到服务端返回的公钥后，利用此公钥对用户所输入的密码进行加密操作。再次调用1001(此次请求参数为phone，passwd)，完成用户的注册。1002逻辑同此。至此，以上问题得到了解释。

为此，通过更改服务端逻辑:在1001，1002调用之前使用0000获取公钥，这样就符合了自己的筛选规则：去除0000。

     if(b.contains("result") && !"0000".equals(tx_code)){....}

整理后的日志中不会再出现1001、1002均不会存在不存在“phone”参数的现象。

注：在进行实际日志测试的时候遇到了瓶颈，交易紊乱，输入输出紊乱问题尤为突出。难道是生成日志方式有问题？

$tempuser:1001(2016-05-16 20:21:04)-->9101-->9103(2016-05-17 12:39:54)

18353102068:9104(2016-05-16 11:27:10)-->9101-->9002(2016-05-16 11:27:47)

输出：静态统计表、动态统计表

未完待续.....

参考文献

1.http://blog.csdn.net/sunhuaqiang1/article/details/47169913

2.http://www.bejson.com/

美文美图