Asciinema: リアルタイムでディスクに書き込む

作成日 2015年08月19日  ·  23コメント  ·  ソース: asciinema/asciinema

再現する手順:

  • ファイルへの記録を開始します。
  • asciinemaプロセスを強制終了します(たとえば、ターミナルウィンドウを閉じます)。
  • 録音を見つけてみてください—何もありません。

デモをご覧ください。

asciinemaが記録ファイルを定期的にフラッシュすると非常に便利です。 未完成のJSONファイルは簡単に修正できます( asciinema play修正できます)。 セッション記録の喪失は、時にはかなりがっかりするかもしれません。

(私のdayjobプロジェクトには、長時間実行されるシステムテストがあります。そのWeb UIを使用すると、興味深い場所にジャンプしてテストを早送りできるため、asciinemaを使用して実行を記録します。)

feature request improvement

最も参考になるコメント

@ sickill-ありがとうございます。これは聞いて良かったです。 私はそれを監視します。 他のシステム管理者のためにWikiにコンテンツを埋め込むことができるので、スクリプトよりもasciinemaの方が本当に好きです。

全てのコメント23件

グッドキャッチ@vvv。 かなり簡単に修正できるようです。

私はこれを見ました。 現在の考え:

asciinemaはその場でJSONストリームを生成しません-JSON文字列全体を生成し、stdout全体がキャプチャされるとファイルに保存します。 これは主に、GoのJSONマーシャラーがどのように機能するかによるものです。

1つの可能性は、tmpファイルにフラッシュすることです( foo.json.tmp記録する場合はfoo.json )。 次のようになります。

{ "version": 2, "width": 80, "height": 24, "env": { "TERM": "xterm-256color" } ... }
[0.1, "bash-4.3$ "]
[0.3, "l"]
[0.1, "s"]
...
...

基本的に、複数のトップレベルオブジェクトを含むJSONファイル。最初はメタデータを含むJSONマップであり、残りはすべてstdoutプリントであり、最終的には最終ファイルのstdoutキーの下に配置されます。

回復に関しては、あなたはそれを自分で簡単に行うことができます(vimで線を動かすだけです)。
これを自動化するための新しいコマンドasciinema recover foo.json.tmp foo.jsonもあります(リカバリをasciinema play一部にするのが最適かどうかはわかりません)。

1つの可能性は、tmpファイルにフラッシュすることです( foo.json.tmp記録する場合はfoo.json )。

いいですね! この機能は、Emacsの自動保存ファイル#foo.json# )とVimリカバリファイル.foo.json.swp )に似ています

回復に関しては、あなたはそれを自分で簡単に行うことができます(vimで線を動かすだけです)。

率直に言って、自動保存ファイルを手動でいじるよりも、「回復」コマンド、または軽量の-r | --recoverオプションを使用したいと思います。

これをはっきりと述べると、#82でもこの問題が修正されます。

@ xloem #82は、1つのステップでasciinema.orgにrec + uploadした場合にのみ適用されます。 asciinema rec demo.jsonを使用すると、サイトに自動的にアップロードせずにファイルに記録することもできます。この場合、ディスクに段階的に書き込むことも同様に役立ちます。

私は#196でasciicast v2形式のドラフトに取り組み始めました。これは、ディスク(およびパイプ、ネットワーク、あなたが持っているもの)へのリアルタイムの書き込みをうまく解決するはずです。

このPRからドキュメントへの直接リンク: https

フィードバックを高く評価します。

@sickillファイル形式の変更(JSONではなくNDJSON )が出力ファイルの増分更新にどのように適用されるかわかりません。 説明してもらえますか?

通常のJSONファイルの@vvvには単一のオブジェクトがあり、増分的に書き込むことはできません。全体として書き込む必要があります(技術的には可能ですが、クラッシュするなどすると、無効なJSONファイルになり、終了が失われます。ブラケット)。 NDJSON(またはほぼ同一のJSONLines )を使用すると、1つのファイルに複数のJSONオブジェクトがあり、それぞれが独自の行にあります。 したがって、新しいデータを新しい行に追加し、自由に停止/クラッシュして、ファイルを無効のままにすることはできません。

asciicast v2形式のドキュメントのドラフトを更新して、動機/それが解決する問題についてより明確にしました。

@sickill良いことの1つは、セッションの開始時刻を初期メタデータに保存することです。 これは、監査可能なsshセッションを提供するために、他のツールで抽出できます。

さらに、メタデータを「挿入」できることは興味深いかもしれないので、作成されたセッションに次のようなタグを付けることができる可能性があります。

  • sshしたユーザー
  • ホスト名
  • サーバー環境

そして、それをいくつかの外部UIで公開します。

編集:フォーマットのPRがあるようですので、そこにコメントします:)

私は現在、リモート従業員のセッションログ用にasciinemaを設定しています
ジャンプホストを介してssh経由でセキュアネットに接続します。 保存できる、
ストリームおよびリプレイセッションは、発生すると、大幅に強化されます。
上記のシナリオにおけるasciinemaの有用性。

2017年4月25日火曜日午前5時17分、Jose Diaz-Gonzalez <
[email protected]>は次のように書いています:

@sickillhttps ://github.com/sickill良いと思われることが1つあり
セッションの開始時刻を初期メタデータに保存する必要があります。
これは、監査可能なsshセッションを提供するために、他のツールで抽出できます。

さらに、メタデータを「注入」できることは興味深いかもしれないので、あなたは
作成されたセッションに次のようなタグを付ける可能性があります。

  • sshしたユーザー
  • ホスト名
  • サーバー環境

そして、それをいくつかの外部UIで公開します。


このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_

私はasciinemaを使用して(まあ、もう、この問題のためにスクリプトに戻っています)、CYAへのすべてのターミナルセッションの記録を保持し、先週3時にサーバーXで行ったことを忘れた場合の参照用に使用します午後。 問題は、これは正常に終了したときにのみフラッシュされるため、セッションの半分にデータがないことです。 たとえば、ハングしたセッションのウィンドウを閉じると、セッションの記録が完全に失われます。 これは予想外の動作であり、非常に残念でした。

@gizmonicus asciicast v2形式とリアルタイムでのディスクへの書き込みは、次のリリースの最優先事項です。 ETAはありませんが、まもなく発生します。

@ sickill-ありがとうございます。これは聞いて良かったです。 私はそれを監視します。 他のシステム管理者のためにWikiにコンテンツを埋め込むことができるので、スクリプトよりもasciinemaの方が本当に好きです。

@timofonicここで質問して、辛抱強く待つことができます。 この方法でユーザーにpingを実行して、全員にスパムを送信する必要はありません。

更新:リアルタイムでのディスクへの書き込みは#196で実装されており、次のリリースの一部になる予定です。

ベータテストを行う場合は、 developブランチをチェックアウトし、チェックアウトディレクトリからpython3 -m asciinema rec filenameます。 さまざまなLinuxディストリビューションやmacOSでどのように機能するかについてのフィードバックをいただければ幸いです👋

注:現在、サーバーとWebプレーヤーは新しいasciicast形式をサポートしていないため、ローカル記録と端末内再生にのみ使用できます。

素晴らしい仕事@sickill! 私はこれをテストして、動作させることができました(Ubuntu17.04)。

ただし、少し説明します。 何がダンプをトリガーしますか? それはファイルのバッファリングですか、それともタイムアウトですか? いずれにせよ、特定のしきい値は何ですか? いくつかのクイックエコーを実行した後、ファイルに何も表示されなかったので、質問しますが、それをさらにいじってみると、何かが表示され始めました。

@metasoarousそれは素晴らしい質問です。

書き込みをバッチ処理するための明示的なタイムアウトやその他のメカニズムはなく、キューをリアルタイムで通過します。

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L72

「ライター」プロセスを分離するには:

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L36 -L40

これはf.write(...)ます。

そうは言っても、最大8KBのチャンクで書き込まれていることも確認したので、ここでは間違いなくバッファリングが行われています。 ここで責任を負っているのはPythonのTextIOWrapperだと思います。

ここで何が一番いいと思いますか? 開いているioオブジェクトのバッファリングをオフにするか、書き込みごとにf.flush()するか、しきい値に達したときにバイト/時間のカウントとフラッシュを行う明示的なトリガーを実装できます。

ioオブジェクトのバッファリングをオフにするのが最も簡単な解決策であり、N秒ごとに1秒近く手動でフラッシュすることを想像します。 私はもっ​​と凝った戦略を想像することができました、しかしそれらの選択の1つに近い何かがトリックをするべきです。

ファイルを書き込み用に開くときに、バッファリングポリシーを「行バッファリング」(書き込みに\n含まれる場合はフラッシュ、この場合は100%の書き込みの場合)に明示的に設定するように変更しました。 今すぐプルして試してみると、ファイルがすぐに大きくなるのがわかります。

素晴らしい! 迅速にご注目いただき、誠にありがとうございます。

これが(#227で)実装されており、次のasciinema 2.0でリリースされることを考えると、この問題を閉じます。

注:誰かがこれを試したい場合は、 v2ブランチをチェックアウトしてください。

このページは役に立ちましたか?
0 / 5 - 0 評価

関連する問題

karelbilek picture karelbilek  ·  9コメント

dlintw picture dlintw  ·  11コメント

deeplook picture deeplook  ·  10コメント

lukehinds picture lukehinds  ·  5コメント

Edo78 picture Edo78  ·  5コメント