Pocket

Digdagを運用していると以下のようにエラーが複数出た。
何回も手動でdigdag runしてもエラーが出てしまう。

今回、道なるエラーをどのように調査して、何万行もあるログから破損している行を特定し、修正したのか流れをブログしていきたいと思います。


■Environment

  • Digdag/embulk
  • s3にアクセスログをBigQueryへ定期的に同期

■Research

(例)日にちは12/31のみにしています

  • 12/31のみエラーが出ているので以下のように手動でDigdagを実行をしたがうまくいかない
  • 他の日にちでDigdag手動実行をするとうまくいく
  • となると、ファイル欠損と予想
  • s3にあるgzファイルは以下
  • nginx_access_20181231.log_0
  • nginx_access_20181231.log_1  

・access_log.20181231.dig

・digdag run access_log.20181231.dig

Error: java.lang.NullPointerException


■Try delete nginx_access_20181231.log_1

nginx_access_20181231.log_1を削除してnginx_access_20181231.log_0のみをdigdag runすると!

BigQueryに同期できた!?

となると、ファイル欠損しているのはnginx_access_20181231.log_1となるので、
10000行までファイルを分割して、digdag runできるか確認する。


■Try use command split

・10000行までファイルを分割する

・ファイル名をインデックス順に変更

この170以上あるファイルを半分ずつS3にアップロードしてdigdag runしまくる!

(これはツライ?)

?…..

すると一部だけ欠損を目撃しました?

どうやらカーネルパニックになり、サーバが急に落ちて、ログも死んだのでしょう。


■まとめ

これで道なるエラーもこの流れですばやく対応できるでしょう!!

Pocket

カテゴリー: digdagembulk

adachin

1989年生まれのSRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWS/Azureでのインフラ構築、Docker開発環境の提供、Kubernetes保守、インフラコード化、新技術の検証、リファクタリング、セキュリティ強化などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTAで未経験者にインフラのコーチング/コミュニティの運用を実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

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