LINEで送る
Pocket

みなさま。分析基盤の運用は大変ですよね(他人事)
今回アクセスログをtdでS3に保存してdigdag/embulkで定期的にBigQueryにシンクしているのですが、遭遇したことがないエラーに出会ってしまいました….

これはわからん

前回Athenaでクエリが叩けないという問題がありましたが、

[AWS][Athena] Error running query: HIVE_CURSOR_ERROR: Unexpected end of input stream

そもそもログはJSONで吐かれてSyntax errorもないし、欠損もない。
というわけでどのように300万行もあるログから犯人特定したかブログします。


■awkでログ抽出してみた

そもそもs3にあるログは以下のように3つある。

  • nginx_access_20190630.log_0.gz
  • nginx_access_20190630.log_1.gz
  • nginx_access_20190630.log_2.gz

どのログからエラーを出しているのかわからないので、1つずつS3にあげて digdag run をすると nginx_access_20190630.log_1.gz だと判断できました。

そしてエラーをちゃんと見てみると…

Bad int64 value

integer(整数)なのに違う値入ってるわ!と怒られています。
そこでint64で対象のカラムからawkすればいけそう?

  • 対象カラム
  • reqsize
  • status
  • size

ここから数字以外をegrepします。

ないじゃん?‍

他にもuser_idカラムも抽出してみた。

ありません?‍


■二分探索で見極める

とりあえず 100000万行 分割して、 このログらを1個ずつS3に置いて digdag run をするしかない!!(地味な戦い?)

すると

"user_id": "11��]\u0018>",

!!!!?

そうエラーにもある 11\\357\\277\\275\\357\\277\\275]\\030> なんなのよって感じですが、UTF-8(文字コード)で文字列が入っているということですな。

どうやらサーバ再起動時におかしくなったかと思われ。


■まとめ

みなさんもログ系でハマったら split コマンドで二分探索をしよう!!!!!

LINEで送る
Pocket


adachin

1989年生まれのランサーズ/SRE。 ホスティングから大規模なアドテクなどのインフラエンジニアとして携わり、AnsibleやTerraformでのインフラコード化を推進。未経験によるエンジニアのメンターなども実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。現在はDocker開発環境の提供、AWSでのインフラ構築、分析基盤の運用を担当している。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください