Athenaを運用していると、S3にある圧縮されたログが破損して、
下記のようにRedash/Athena側にエラーが出ることがあります。
Error running query: HIVE_CURSOR_ERROR: Unexpected end of input stream
今回はその対処方法をブログしやす
■Athena vs BigQuery
AthenaはS3のgzipを全て展開して出力しているため、
クエリで日付け指定してもバケットにファイル破損しているものがあればエラーが出てしまいます。(ツラミ)
そのため上記のエラーはどこのファイルが破損しているか不明なため、全ファイルのエラーチェックをする必要があります。
(スキャンした容量により, 従量課金される課金方式)
※逆にBigQueryはembulkなどで展開されているため、実行時にコケるはず。
せっかくなので次はAthenaでログ収集のコツをまとめてみました。
■Athenaを使ってS3のログを検索できるようにしたら運用コストが改善されたお話
https://qiita.com/godgarden/items/69fc31b95d63200f2f3f
ちなみに我ら@g0dgardenさんのQiitaにて以下のような工夫と実装をしています。
- アクセスログをLTSV形式にする⇛アクセスログを解析しやすく, 項目追加など変化に強い形になるため
- S3へ保存するログファイルをtdでJSONにする
- S3バケットのディレクトリ設計。HIVE形式にする⇛全ファイルを探索すると、その分課金されてしまうため必要な分のみ
- パーティションを認識させる
これにより毎回サーバに入ってawkして加工することがなく、爆発的に運用コストが下がりました。
ということでエラー直していきやしょう！
■ログの容量を確認
ローカルにログをダウンロードしないといけないので、
Macの容量的に余裕があるか、毎月のログ容量はどんなもんなのか確認しましょう。
$ aws s3 ls logs.adachin.jp/log/nginx/access/dt=2018-01 --recursive --human --sum Total Objects: 67 Total Size: 4.1 GiB
ざっと35GBもありました。。
・cyberduck
この目が死んでいるアヒルを使ってローカルにダウンロードします。
(意外と便利)
■Research
$ cd ~/Desktop $ mkdir accesslog download!! $ ls check.sh* dt=2018-07-23/ dt=2018-08-15/ dt=2018-09-07/ ~省略~ dt=2018-07-24/ dt=2018-08-16/ dt=2018-09-08/ dt=2018-07-02/ dt=2018-07-25/ dt=2018-08-17/ dt=2018-09-09/ dt=2018-07-03/ dt=2018-07-26/ dt=2018-08-18/ dt=2018-09-10/ dt=2018-07-04/ dt=2018-07-27/ dt=2018-08-19/ dt=2018-09-11/ dt=2018-07-05/ dt=2018-07-28/ dt=2018-08-20/ dt=2018-09-12/ dt=2018-07-06/ dt=2018-07-29/ dt=2018-08-21/ dt=2018-09-13/ dt=2018-07-07/ dt=2018-07-30/ dt=2018-08-22/ dt=2018-09-14/ dt=2018-07-08/ dt=2018-07-31/ dt=2018-08-23/ dt=2018-09-15/ dt=2018-07-09/ dt=2018-08-01/ dt=2018-08-24/ dt=2018-09-16/ dt=2018-07-10/ dt=2018-08-02/ dt=2018-08-25/ dt=2018-09-17/ dt=2018-07-11/ dt=2018-08-03/ dt=2018-08-26/ dt=2018-09-18/ dt=2018-07-12/ dt=2018-08-04/ dt=2018-08-27/ dt=2018-09-19/ dt=2018-07-13/ dt=2018-08-05/ dt=2018-08-28/ dt=2018-09-20/ dt=2018-07-14/ dt=2018-08-06/ dt=2018-08-29/ dt=2018-09-21/ dt=2018-07-15/ dt=2018-08-07/ dt=2018-08-30/ dt=2018-09-22/ dt=2018-07-16/ dt=2018-08-08/ dt=2018-08-31/ dt=2018-09-23/ dt=2018-07-17/ dt=2018-08-09/ dt=2018-09-01/ dt=2018-09-24/ dt=2018-07-18/ dt=2018-08-10/ dt=2018-09-02/ dt=2018-09-25/ dt=2018-07-19/ dt=2018-08-11/ dt=2018-09-03/ dt=2018-09-26/ dt=2018-07-20/ dt=2018-08-12/ dt=2018-09-04/ dt=2018-09-27/ dt=2018-07-21/ dt=2018-08-13/ dt=2018-09-05/ ~省略~ dt=2018-07-22/ dt=2018-08-14/ dt=2018-09-06/
・check.sh
#! /bin/bash for f in $(ls */*.gz); do gunzip $f && rm $(dirname $f)/$(basename $f .gz) done
上記のスクリプトを使ってエラー(unexpected end of file)のみのファイルを標準出力してあげます。
・run check.sh
$ ./check.sh gunzip: dt=2018-xx-xx/nginx_access_2018xxxx.log_5.gz: unexpected end of file gunzip: dt=2018-xx-xx/nginx_access_2018xxxx.log_5.gz: uncompress failed
すると!!エラーは1つのファイルのみだったようです。
・fix log
・解凍
$ gunzip < nginx_access_2018xxxx.log_5.gz > nginx_access_2018xxxx.log_5.txt
・編集
$ vim nginx_access_2018xxxx.log_5.txt
~省略~
# 一番下
{"time":"2018-xx-xxTxx:xx:xx+09:00","server_addr":"127.0.0.1⇛ここで切れてるので削除
・圧縮
$ gzip nginx_access_2018xxxx.log_5.txt
$ mv nginx_access_2018xxxx.log_5.txt.gz nginx_access_2018xxxx.log_5.gz
・S3 アップロード!!
■確認
■まとめ
今回破損しているところは削除しましたが、ログサーバ/本番にもあるか確認しましょう。
しかしファイル破損はtdが問題なのかな。(不明)