问题:我经常需要查看在特定日志的最后一天内重复频率最高的“模式”是什么。就像这里的一小部分 tomcat 日志一样:
GET /app1/public/pkg_e/v3/555413242345562/account/stats 401 954 5
GET /app1/public/pkg_e/v3/555412562561928/account/stats 200 954 97
GET /app1/secure/pkg_e/v3/555416251626403/ex/items/ 200 517 18
GET /app1/secure/pkg_e/v3/555412564516032/ex/cycle/items 200 32839 50
DELETE /app1/internal/pkg_e/v3/accounts/555411543532089/devices/bbbbbbbb-cccc-2000-dddd-43a8eabcdaa0 404 - 1
GET /app1/secure/pkg_e/v3/555412465246556/sessions 200 947 40
GET /app1/public/pkg_e/v3/555416264256223/account/stats 401 954 4
GET /app2/provisioning/v3/555412562561928/devices 200 1643 65
...
如果我想找出最常用的 URL(以及方法和 retcode) - 我会这样做:
[root@srv112:~]$ N=6;cat test|awk '{print $1" "$2" ("$3")"}'\
|sed 's/[0-9a-f-]\+ (/%GUID% (/;s/\/[0-9]\{4,\}\//\/%USERNAME%\//'\
|sort|uniq -c|sort -rn|head -$N
4 GET /app1/public/pkg_e/v3/%USERNAME%/account/stats (401)
2 GET /app1/secure/pkg_e/v3/%USERNAME%/devices (200)
2 GET /app1/public/pkg_e/v3/%USERNAME%/account/stats (200)
2 DELETE /app1/internal/pkg_e/v3/accounts/%USERNAME%/devices/%GUID% (404)
1 POST /app2/servlet/handler (200)
1 POST /app1/servlet/handler (200)
如果我想从同一个文件中找出最常用的用户名 - 我会这样做:
[root@srv112:~]$ N=4;cat test|grep -Po '(?<=\/)[0-9]{4,}(?=\/)'\
|sort|uniq -c|sort -rn|head -$N
9 555412562561928
2 555411543532089
1 555417257243373
1 555416264256223
上面在小数据集上工作得很好,但是对于更大的输入集 - 性能(复杂性)sort|uniq -c|sort -rn|head -$N
是难以忍受的(大约 100 台服务器,每台服务器约 250 个日志文件,每个日志文件约 100 万行)
尝试解决: |sort|uniq -c
零件可以很容易地用 awk 1-liner 替换,变成:
|awk '{S[$0]+=1}END{for(i in S)print S[i]"\t"i}'|sort -rn|head -$N
但我未能找到“快速选择算法”(在此处讨论)的标准/简单和高效内存实现来优化该|sort -rn|head -$N
部分。正在寻找 GNU 二进制文件、rpms、awk 1-liners 或一些我可以在数据中心携带/传播的易于编译的 Ansi C 代码,以转向:
3 tasty oranges
225 magic balls
17 happy dolls
15 misty clouds
93 juicy melons
55 rusty ideas
...
进入(给定 N = 3):
225 magic balls
93 juicy melons
55 rusty ideas
我可能可以获取示例 Java 代码并将其移植为上述标准输入格式(顺便说一下 - 对.quickselect(...)
核心 java 的缺乏感到惊讶) - 但是到处部署 java-runtime 的需要并不吸引人。我也许也可以抓取它的示例(基于数组的)C 片段,然后将其调整为上述标准输入格式,然后测试和修复泄漏等一段时间。或者甚至在 awk 中从头开始实现它。但是(!) - 超过 1% 的人可能经常面临这种简单的需求 - 应该有一个标准的(预先测试的)实现吗?希望...也许我使用了错误的关键字来查找它...
其他障碍:在处理大型数据集时还面临一些问题:
- 日志文件位于约 100 台服务器的 NFS 安装卷上 - 因此将工作并行化并将其拆分为更小的块是有意义的
- 以上
awk '{S[$0]+=1}...
需要内存 - 我看到它在耗尽 16GB 时会死掉(尽管有 48GB 的可用 RAM 和大量交换......也许我忽略了一些 linux 限制)
我目前的解决方案仍然不可靠且不是最佳的(正在进行中)看起来像:
find /logs/mount/srv*/tomcat/2013-09-24/ -type f -name "*_22:*"|\
# TODO: reorder 'find' output to round-robin through srv1 srv2 ...
# to help 'parallel' work with multiple servers at once
parallel -P20 $"zgrep -Po '[my pattern-grep regexp]' {}\
|awk '{S[\$0]+=1}
END{for(i in S)if(S[i]>4)print \"count: \"S[i]\"\\n\"i}'"
# I throw away patterns met less than 5 times per log file
# in hope those won't pop on top of result list anyway - bogus
# but helps to address 16GB-mem problem for 'awk' below
awk '{if("count:"==$1){C=$2}else{S[$0]+=C}}
END{for(i in S)if(S[i]>99)print S[i]"\t"i}'|\
# I also skip all patterns which are met less than 100 times
# the hope that these won't be on top of the list is quite reliable
sort -rn|head -$N
# above line is the inefficient one I strive to address