- 0.5.0 で取得可能な情報は以下の wiki に記載の通り。
- これらの情報に加えて、現時点で必要だと思われる情報について、整理する。
| 分類 | 想定用途 | 例 |
|---|---|---|
| プロセス情報 | * オペレーションの確認 (起動時の条件確認)
* プロセスの稼働情報
|
* 起動ユーザー
* pid など
|
| システム情報 | * メトリクス収集
|
* システム時刻 など
|
| アプリケーション情報 | * アプリケーションの確認
|
* バージョン など
|
| 稼働情報 | * オペレーションの確認 (起動時の条件確認)
|
* 起動引数 など
|
- 起動時間(秒)
uptime- プロセスが起動してからの秒数
- 想定用途
- プロセスの稼働情報 (どれくらい稼働しているのかを確認する)
- オペレーションの確認 (いつ起動したかを後々確認する)
- 補足
psコマンドで確認可能な値であるが、複数のマシンをまたがっての確認は操作コストが高いため、提供を行う- redis でも提供
- 起動時刻(エポック秒)
start_time- プロセスが起動した際のエポック秒
- 想定用途
uptimeと同じ用途で利用する
- 補足
psコマンドで確認可能な値であるが、複数のマシンをまたがっての確認は操作コストが高いため、提供を行う- 用途から考えると、
uptimeのみでも十分であるかもしれないが、uptimeの算出のために内部的に保持する値でもあるため、提供する
- 起動ユーザー
user- 動作しているプロセスのユーザー名
- 想定用途
- オペレーションの確認 (どのユーザーで実行したかを後々確認する)
- 補足
psコマンドで確認可能な値であるが、複数のマシンをまたがっての確認は操作コストが高いため、提供を行う
- プロセスID
pid- 動作しているプロセスのPID
- 想定用途
- Jubatus の場合、
IP_PORTがメンバシップを示す一意な情報であるため、本情報で何かを管理するようなケースはあまり想定されないが、プロセスを示す一意な情報という意味で、プロセス情報として一般的であり、取得するための実装コストも高くないため、提供する
- Jubatus の場合、
- 補足
psコマンドで確認可能な値であるが、複数のマシンをまたがっての確認は操作コストが高いため、提供する
- プログラムパス
program_path- 動作しているプログラムのパス
- 想定用途
- オペレーションの確認 (どのプログラムを実行したかを後々確認する)
- 補足
psコマンドで確認可能な値であるが、複数のマシンをまたがって確認は操作コストが高いため、提供する- 現行の
PROGNAMEは、本エントリにより置き換わることを想定
エポック秒
clock_timeget_status 受付時のシステム時刻(エポック秒)
想定用途
メトリクス収集
get_statusを複数回実行することにより、以下の様な形で単位時間あたりの処理数を把握することが可能 (性能を見るのではなく、システム組み込み時の使用状況を確認することが目的)QPS = (after_count - before_count) / (after_clock_time - before_clock_time)
補足
- kumofs では、上記方法で QPS を表示
- クライアント側で取得することでも想定する用途を満たせるが、前述の
uptime算出のため内部的に保持することとなるため、提供する
- サーバープロセスの種類
type- classifier, recommender のような機械学習エンジンの種類
- 想定用途
- 機械学習エンジンの識別子として、各種外部ツールでハンドルすることを想定
- 補足
PROGNAME,program_pathでも識別可能であるが、機械学習エンジンを判断する最も短い単語(識別子)として提供する
現行で出力されているものからの差分のみを記載
Jubatus Proxy でも同様に 起動引数 の値を提供する
- 稼働モード
mode- 「スタンドアローンモード」か「分散モード」のいずれかの稼働モード
- 想定用途
- あまり想定はしづらいが、オペレーションの確認 (どのモードを実行したかを後々確認する)
- 補足
is_standaloneの bool 値 ではなく、人間が分かる値(文字列)として返却する- 「standalone mode」「multinode mode」のいずれかとする
- 現行の
is_standaloneは、本エントリにより置き換わることを想定
- ログ出力ディレクトリ
logdir- 想定用途
- オペレーションの確認 (どのディレクトリを指定して実行したかを後々確認する)
- 補足
- 起動引数で省略された場合は標準エラーへの出力する動きであるため、「/dev/stderr」 を返却する
- 想定用途
- ログレベル
loglevel- 想定用途
- オペレーションの確認 (どのレベルを指定して実行したかを後々確認する)
- 補足
loglevelの int 値 ではなく、人間が分かる値(文字列)として返却する
- 想定用途
- 設定ファイルへのパス
configpath- 想定用途
- オペレーションの確認 (どのファイルを指定して実行したかを後々確認する)
- 補足
- ファイル名だけでは、実行時のファイルを特定できないので、相対パスを絶対パスへ変換する
- 分散モードの場合は、ZooKeeper 上のノードパスを出力する
- 想定用途
- 最終 save 時刻
last_saved- 最後に
saveを実行した時刻 (エポック秒) - 想定用途
- オペレーションの確認 (最後のモデル保存時刻を後々確認する)
- 最後に
- 最終 save ファイル
last_saved_path- 最後に
saveしたファイルのパス - 想定用途
- オペレーションの確認 (最後にモデルを保存したときのファイル名を後々確認する)
- 補足
- ファイル名 もしくは RPC引数の
idだけでも良いが、datadirを含めた絶対パスで提供し、scp等で移動を行いたいユーザーのコストを下げる
- ファイル名 もしくは RPC引数の
- 最後に
- 最終 load 時刻
last_loaded- 最後に
loadを実行した時刻 (エポック秒) - 想定用途
- オペレーションの確認 (最後のモデル読み込み時刻を後々確認する)
- 補足
- 起動時読み込みの場合も値を更新する
- 最後に
- 最終 load ファイル
last_loaded_path- 最後に
loadしたファイルのパス - 想定用途
- オペレーションの確認 (最後にモデルを読み込んだときのファイル名を後々確認する)
- 補足
- ファイル名 もしくは RPC引数の
idだけでも良いが、last_saved_pathと統一し、datadirを含めた絶対パスで提供る - 起動時読み込みの場合も値を更新する
- ファイル名 もしくは RPC引数の
- 最後に
- レイテンシー、スループット など時間効率性の観点の値は、システム全体として確認すべきものとの立場から、現時点では、クライアントアプリケーション側を通じた一気通貫での性能監視を実施することを想定する
- また、 Jubatus 側でクエリ毎のこれらの情報(レイテンシー、スループット)を保持するのは、性能面、リソース消費の面で高コストである