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


あだちん

1989年生まれ。 ランサーズ/SRE。 ホスティングから大規模なアドテクなどのインフラエンジニアとして携わり、他社インフラレスポンス改善などの副業、ansibleやterraformでのインフラコード化を推進し、未経験によるエンジニアのメンターなども実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/広報/VulsRepo init file,chatwork通知のコントリビュータでもある。現在はDocker開発環境の提供、AWSでのインフラ構築、PHPバージョンアップ、CakePHPでのSEO対策とバッチ作成、Wordpressによるコーポレートサイトの修正、分析基盤の運用を担当している。

コメントを残す

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