問題:特定のログの最終日に最も頻繁に繰り返される「パターン」を確認する必要にしばしば直面します。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 個のログ ファイル、ログ ファイルあたり約 1mln 行)。
解決しようとする: |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 バイナリ、rpm、awk 1 ライナー、または簡単にコンパイルできる 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 コードを取得して、上記の stdin 形式に移植することもできます (ちなみに、.quickselect(...)
コア Java 内に不足していることに驚きました)。サンプル (配列ベース) の C スニペットも取得して、上記の stdin 形式に適応させてから、しばらくの間、リークなどをテストして修正することができます。または、awk でゼロから実装することもできます。BUT(!) - この単純な必要性は、おそらく 1% を超える人々が定期的に直面している可能性があります - 標準的な (事前にテストされた) 実装が存在するはずでした?? 希望...おそらく私はそれを調べるために間違ったキーワードを使用しています...
その他の障害:また、大規模なデータセットを回避するためにいくつかの問題に直面しました。
- ログ ファイルは、NFS でマウントされた最大 100 台のサーバーのボリュームに配置されているため、作業を並列化して小さなチャンクに分割することは理にかなっています。
- 上記に
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