Skip to content

Instantly share code, notes, and snippets.

@rimms
Last active December 27, 2015 01:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save rimms/7245779 to your computer and use it in GitHub Desktop.
Save rimms/7245779 to your computer and use it in GitHub Desktop.
異常処理方針

目的

現状の Jubatus では、異常発生時の振る舞い、異常時に出力するログに統一感があるとは言いがたい。

本資料では、発生しうる異常を体系立てて整理(可能な限り網羅的に抽出)するととともに、それぞれのエラーに対して、ログ出力も含めた Jubatus の振る舞いの方針を定義することを目的とする。

作業ゴール

本資料では、まずは 2 までの議論・決定をゴールとする。確認・議論すべき点は箇条書きの通り。

  1. 発生しうるエラーの分類
    • 分類の妥当性、網羅的な抽出ができているか(漏れはないか)
  2. 1 で抽出したエラー発生時のJubatusの振舞い方針の決定
    • 方針として、問題がないか(Jubatus の考え方にそぐわないものはないか)
    • ログレベル、ログに出力すべき内容は適切か
    • 実現方法を踏まえた上での問題はないか
  3. ソースコードの点検/修正
    • 異常ハンドリングの方針についても、決定が必要
    • 場合によっては、点検/修正を細かなIssues単位に分割する (例えば、MIX時の振る舞いとか)

補足

  • 分類ごとの処理方針に対して、細かな比較検討を行ったわけではなく、現在の実装を踏まえ、一般的に考えられる(明らかにおかしくない)範囲での動作を案として記載している。

変更履歴

  • 2013/10/31: 今増 初版作成
  • 2013/11/19: 今増 誤記修正
  • 2013/12/02: 今増 ポリシー修正
    • 01-01: RPC 利用者誤り のログ出力を なし から WARNING ヘ変更 (ユーザーAP側で出力することを強要しない)
  • 2013/12/13: 今増 ポリシー修正
    • 03-02: 自動的なリトライはしない。クライアントAPに例外を通知する。
    • 03-04, 05: 接続エラーは、起動中に発生するため、クライアントへのエラー通知はなし。
  • 2014/02/06: 今増 ポリシー修正
    • 06, 07: ディスク枯渇、故障時は

発生しうる異常の分類 と 振る舞い方針(案)

発生しうる異常の分類ごとに振る舞い方針(案) を以下に示す。

凡例:

* 通信の自動的なリトライ: Jubatus が通信を自動的にリトライするか否か
* クライアントAPへのエラー通知: クライアントAPへのエラー通知有無
* ユーザーへのエラー通知: 起動時エラーの場合、ユーザー(操作者)へのエラー通知有無
* プロセス継続性: Jubatus Server、Jubatus Proxy の処理継続性
* ログ出力: ログの出力有無、出力レベル、出力時に含むべき情報

01: 利用者誤り

01-01: RPC

  • 例) API 引数誤り
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装に任せる
    • クライアントAPへのエラー通知: エラーを返却する
    • プロセス継続性: プロセスを継続する
    • ログ出力
      • レベル: WARNING
      • 含むべき情報: クライアントIP、異常なパラメータ名、パラメータ値

01-02: コマンド

  • 例) コマンドオプション誤り、コマンド引数誤り(無効な値)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施しない (通信は「指定された ZK への接続」が対象)
    • クライアントAPへのエラー通知: 起動時エラーのため、クライアントからの通信は発生しない
    • ユーザーへのエラー通知: 原則、標準エラーへエラー内容と usage を出力する
      • スタンドアロンでビルド時に分散モードのオプションが指定された場合: 指定されたオプションを無視し、処理を継続する (異常としない)
      • 指定されたZKへの接続失敗時: ログを通じてエラーを通知する
    • プロセス継続性: 原則、プロセスを安全に停止する
      • スタンドアロンでビルド時に分散モードのオプションが指定された場合: 指定されたオプションを無視し、処理を継続する (異常としない)
    • ログ出力: 原則、なし
      • スタンドアロンでビルド時に分散モードのオプションが指定された場合:
        • レベル: WARNING
        • 含むべき情報: 無視したオプション名
      • 指定されたZKへの接続失敗時:
        • レベル: FATAL
        • 含むべき情報: 発生した ZK エラー内容

02: 設定誤り

  • 例) 設定ファイル内容誤り
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 通信は発生しない
    • クライアントAPへのエラー通知: 起動時エラーのため、クライアントからの通信は発生しない
    • ユーザーへのエラー通知: ログを通じてエラーを通知する
    • プロセス継続性: プロセスを安全に停止する
    • ログ出力:
      • レベル: FATAL
      • 含むべき情報: 誤り箇所

03: NW故障 (接続失敗)

03-01: RPC通信 (C/P間)

スタンドアロン構成においては、C/S間通信と読み替える

  • 例) 接続失敗 (クライアントリクエスト)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装 に任せる
    • クライアントAPへのエラー通知: 例外を返却する
    • プロセス継続性: プロセスを継続する
    • ログ出力: なし

03-02: RPC通信 (P/S間)

  • 例) 接続失敗 (クライアントリクエスト)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: しない
    • クライアントAPへのエラー通知: 例外を返却する
    • プロセス継続性: プロセスを継続する
    • ログ出力:
      • レベル: WARNING
      • 含むべき情報: 接続先ホスト、ポート番号

03-03: RPC通信 (S/S間)

  • 例) 接続失敗 (MIX)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施する (通信個別ではなく、MIXのループをリトライと考える)
    • クライアントAPへのエラー通知: なし (サーバー間通信のため)
    • プロセス継続性: プロセスを継続する
    • ログ出力:
      • レベル: WARNING
      • 含むべき情報: 接続先ホスト、ポート番号

03-04: ZK通信 (P)

  • 例) 接続失敗
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施しない
    • クライアントAPへのエラー通知: 起動時エラーのため、クライアントからの通信は発生しない
    • プロセス継続性: プロセスを安全に停止する
    • ログ出力:
      • レベル: FATAL
      • 含むべき情報: 発生した ZK エラー内容

03-05: ZK通信 (S)

  • 例) 接続失敗
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施しない
    • クライアントAPへのエラー通知: 起動時エラーのため、クライアントからの通信は発生しない
    • プロセス継続性: プロセスを安全に停止する
    • ログ出力:
      • レベル: FATAL
      • 含むべき情報: 発生した ZK エラー内容

04: NW故障 (タイムアウト)

04-01: RPC通信 (C/P間)

スタンドアロン構成においては、C/S間通信と読み替える

  • 例) タイムアウト (クライアントリクエスト)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装 に任せる
    • クライアントAPへのエラー通知: エラーを返却する
    • プロセス継続性: プロセスを継続する
    • ログ出力: なし

04-02: RPC通信 (P/S間)

TBD

  • C/P間のタイムアウトに至る前に P/S間 のタイムアウトが発生させることに対して、議論が必要。
  • クライアントには P/S間 のタイムアウトは隠蔽(その前にクライアントがタイムアウトする)されるべきでは。

04-03: RPC通信 (S/S間)

  • 例) タイムアウト (MIX)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施する (通信個別ではなく、MIXのループをリトライと考える)
    • クライアントAPへのエラー通知: なし (サーバー間通信のため)
    • プロセス継続性: プロセスを継続する
    • ログ出力:
      • レベル: WARNING
      • 含むべき情報: 接続先ホスト、ポート番号

04-04: ZK通信 (P)

  • 例) 接続失敗
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施しない
    • クライアントAPへのエラー通知: なし (仕掛中のリクエストへ対しては、通常時と同様に処理を行う)
    • プロセス継続性: プロセスを安全に停止する
    • ログ出力:
      • レベル: FATAL
      • 含むべき情報: 発生した ZK エラー内容

04-05: ZK通信 (S)

  • 例) 接続失敗
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: 実施しない
    • クライアントAPへのエラー通知: なし (仕掛中のリクエストへ対しては、通常時と同様に処理を行う)
    • プロセス継続性: プロセスを安全に停止する
    • ログ出力:
      • レベル: FATAL
      • 含むべき情報: 発生した ZK エラー内容

05: メモリ枯渇

  • 例) メモリ確保エラー(malloc失敗, bad_alloc)
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: エラー返却が可能であるか不定
    • クライアントAPへのエラー通知: 不定
    • ユーザーへのエラー通知: 起動時の場合は、ログを通じてエラーを通知する
    • プロセス継続性: プロセスを即時に停止する
    • ログ出力(可能な限り):
      • レベル: FATAL
      • 含むべき情報: 発生箇所のスタックトレース

06: ディスク枯渇

  • 例) save 時にディスク容量不足
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装 に任せる (save はリトライしないのがベスト・プラクティス)
    • クライアントAPへのエラー通知: エラーを返却する
    • ユーザーへのエラー通知: 起動時の場合は、ログを通じてエラーを通知する
    • プロセス継続性: プロセスを継続する
    • ログ出力(可能な限り):
      • レベル: ERROR
      • 含むべき情報: 作成/更新を試みたファイルのパス

07: ディスク故障

  • 例) save 時に I/O エラー
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装 に任せる (save はリトライしないのがベスト・プラクティス)
    • クライアントAPへのエラー通知: エラーを返却する
    • ユーザーへのエラー通知: 起動時の場合は、ログを通じてエラーを通知する
    • プロセス継続性: プロセスを継続する
    • ログ出力(可能な限り):
      • レベル: ERROR
      • 含むべき情報: 作成/更新を試みたファイルのパス

08: 論理矛盾/内部バグ

  • 例) ASSERT文、システムコール失敗
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: エラー返却が可能であるか不定
    • クライアントAPへのエラー通知: 不定
    • ユーザーへのエラー通知: 起動時の場合は、ログを通じてエラーを通知する
    • プロセス継続性: プロセスを即時に停止する
    • ログ出力(可能な限り):
      • レベル: FATAL
      • 含むべき情報: 発生箇所のスタックトレース、システムコールの戻り値

09: 想定外トラフィック

Jubatus での検知スコープ外とする

10: 機械学習上のエラー

  • 例) モデルに Inf が含まれる場合 など
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装 に任せる
    • クライアントAPへのエラー通知: 結果をそのまま返却する (通常時の応答と同様)
    • プロセス継続性: プロセスを継続する
    • ログ出力:
      • レベル: ERROR
      • 含むべき情報: 異常の内容、異常の発生したデータを特定できる情報

11: ZK操作エラー

別途 #497 にて整理中

  • 例) ZK API からの戻り値が異常
  • 振る舞い方針(案)
    • 通信の自動的なリトライ: クライアント および クライアントの実装 に任せる
    • クライアントAPへのエラー通知: 結果をそのまま返却する (通常時の応答と同様)
    • プロセス継続性: 原則、プロセスを安全に停止する
    • ログ出力:
      • レベル: FATAL
      • 含むべき情報: 異常の内容、異常の発生したデータを特定できる情報
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment