Asciinema: Menulis ke disk secara real-time

Tangkapan bagus @vvv. Sepertinya itu bisa diperbaiki dengan mudah.

Aku melihat ini. Pikiran saat ini:

asciinema tidak menghasilkan aliran JSON dengan cepat - ini menghasilkan seluruh string JSON dan menyimpannya ke file setelah seluruh stdout ditangkap. Ini sebagian besar karena cara kerja marshaller JSON Go.

Satu kemungkinan adalah mem-flush ke file tmp ( foo.json.tmp jika Anda merekam ke foo.json ). Itu bisa terlihat seperti:

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

Pada dasarnya file JSON dengan beberapa objek tingkat atas, pertama adalah peta JSON dengan metadata, sisanya adalah cetakan stdout yang pada akhirnya akan berakhir di bawah kunci stdout di file akhir.

Adapun pemulihan, Anda kemudian dapat dengan mudah melakukannya sendiri (hanya memindahkan garis di vim).
Mungkin juga ada perintah baru asciinema recover foo.json.tmp foo.json untuk mengotomatisasi ini (tidak yakin apakah menjadikan pemulihan sebagai bagian dari asciinema play adalah yang terbaik).

Satu kemungkinan adalah mem-flush ke file tmp ( foo.json.tmp jika Anda merekam ke foo.json ).

Kedengarannya bagus! Fitur ini akan menyerupai file penyimpanan otomatis Emacs ( #foo.json# ) dan file pemulihan Vim ( .foo.json.swp .)

Adapun pemulihan, Anda kemudian dapat dengan mudah melakukannya sendiri (hanya memindahkan garis di vim).

Terus terang, saya lebih suka perintah "pulihkan", atau bahkan opsi -r | --recover ringan, daripada mengutak-atik file penyimpanan otomatis secara manual.

Hanya untuk menyatakan ini secara terbuka, #82 akan memperbaiki masalah ini juga.

@xloem #82 hanya berlaku untuk kasus ketika Anda merekam+upload ke asciinema.org dalam satu langkah. asciinema rec demo.json juga memungkinkan Anda merekam ke file tanpa mengunggah secara otomatis ke situs, dan menulis ke disk secara bertahap dalam hal ini akan sama-sama berguna.

Saya mulai mengerjakan draf format asciicast v2 di #196, yang seharusnya menyelesaikan penulisan dengan baik secara real-time ke disk (dan pipa, jaringan, apa pun yang Anda miliki).

Tautan langsung ke dokumen dari PR ini: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

Umpan balik sangat dihargai.

@sickill Saya tidak melihat bagaimana perubahan format file ( NDJSON alih-alih JSON) berlaku untuk pembaruan tambahan file output. Bisakah Anda menjelaskan?

@vvv dalam file JSON normal Anda memiliki satu objek dan Anda tidak dapat menulisnya secara bertahap, itu harus ditulis secara keseluruhan (secara teknis Anda bisa tetapi jika Anda crash dll maka Anda berakhir dengan file JSON yang tidak valid, tidak ada penutupan kurung). Dengan NDJSON (atau JSONLines yang hampir identik), Anda memiliki beberapa objek JSON dalam satu file, masing-masing pada barisnya sendiri. Jadi Anda dapat menambahkan baris baru dengan data baru dan berhenti/rusak sesuka hati dan tidak pernah meninggalkan file tidak valid.

Saya telah memperbarui draf dokumen format asciicast v2 untuk membuatnya lebih jelas tentang motivasi / masalah apa yang dipecahkannya.

@sickill satu hal yang baik adalah memiliki waktu mulai sesi yang disimpan dalam metadata awal. Ini dapat diekstraksi di alat lain untuk menyediakan sesi ssh yang dapat diaudit.

Selain itu, dapat "menyuntikkan" metadata mungkin menarik, sehingga Anda berpotensi menandai sesi yang dibuat dengan hal-hal seperti:

• pengguna yang ssh'd
• nama host
• lingkungan server

Dan ekspos itu di beberapa ui eksternal.

EDIT: Sepertinya ada PR untuk formatnya, jadi saya akan berkomentar di sana :)

Saat ini saya memiliki pengaturan asciinema untuk pencatatan sesi karyawan jarak jauh
menghubungkan melalui ssh ke jaringan aman melalui jumphost. mampu menyelamatkan,
sesi streaming dan pemutaran ulang, saat terjadi, akan sangat meningkatkan
kegunaan asciinema dalam skenario tersebut.

Pada Sel, 25 Apr 2017 jam 5:17, Jose Diaz-Gonzalez <
[email protected]> menulis:

@sickill https://github.com/sickill satu hal yang akan baik
memiliki waktu mulai sesi yang disimpan dalam metadata awal.
Ini dapat diekstraksi di alat lain untuk menyediakan sesi ssh yang dapat diaudit.

Selain itu, kemampuan untuk "menyuntikkan" metadata mungkin menarik, jadi Anda
berpotensi menandai sesi yang dibuat dengan hal-hal seperti:

• pengguna yang ssh'd
• nama host
• lingkungan server

Dan ekspos itu di beberapa ui eksternal.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJonPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

Saya menggunakan asciinema (yah, tidak lagi, saya kembali ke skrip karena masalah ini) untuk menyimpan catatan semua sesi terminal saya ke CYA serta sebagai referensi jika saya lupa apa yang saya lakukan di server X minggu lalu pukul 3 PM. Masalahnya adalah, karena ini hanya memerah pada pintu keluar yang berhasil, setengah sesi saya tidak memiliki data. Menutup jendela untuk sesi yang digantung misalnya, menyebabkan hilangnya rekaman sesi secara total. Ini adalah perilaku yang tidak terduga dan cukup mengecewakan.

@gizmonicus asciicast v2 format dan menulis ke disk secara real-time adalah prioritas tertinggi untuk rilis berikutnya. Tidak ada ETA, tapi itu akan segera terjadi.

@sickill - Terima kasih, ini bagus untuk didengar. Aku akan mengawasinya. Saya benar-benar lebih suka asciinema daripada skrip karena saya dapat menyematkan konten di Wiki kami untuk sysadmin lain.

@timofonic Anda dapat mengajukan pertanyaan Anda di sini dan menunggu dengan sabar. Tidak perlu mengirim spam ke semua orang dengan melakukan ping ke pengguna dengan cara ini.

Pembaruan: menulis ke disk secara real-time telah diterapkan di #196 dan akan menjadi bagian dari rilis berikutnya.

Jika Anda ingin menguji beta, maka checkout cabang develop dan jalankan dari direktori checkout dengan: python3 -m asciinema rec filename . Saya sangat menghargai umpan balik tentang cara kerjanya di berbagai distro Linux dan macOS

Catatan: mulai hari ini server dan pemutar web tidak mendukung format asciicast baru sehingga hanya dapat digunakan untuk perekaman lokal dan pemutaran di dalam terminal.

Kerja bagus @sickill! Saya baru saja menguji ini dan dapat membuatnya berfungsi (Ubuntu 17.04).

Sedikit klarifikasi; Apa yang memicu dump? Apakah file buffering atau batas waktu? Either way, apa ambang batas spesifik? Saya bertanya karena setelah melakukan beberapa gema cepat, saya tidak melihat apa pun di file, tetapi ketika saya lebih banyak bermain-main dengannya, hal-hal mulai muncul.

@metasoarous itu pertanyaan yang bagus.

Tidak ada batas waktu eksplisit atau mekanisme lain untuk mengelompokkan penulisan, ini berjalan secara real-time melalui antrian:

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

untuk memisahkan proses "penulis":

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

yang melakukan f.write(...) .

Karena itu, saya juga mengamati bahwa itu ditulis dalam potongan ~8KB, jadi pasti ada beberapa buffering yang terjadi di sini. Saya menduga TextIOWrapper Python bertanggung jawab di sini.

Menurut Anda apa yang terbaik di sini? Kita dapat mematikan buffering pada objek io yang dibuka, atau menerapkan pemicu eksplisit, baik f.flush() pada setiap penulisan, atau penghitungan byte/waktu dan pembilasan saat ambang batas tercapai.

Saya membayangkan mematikan buffering pada objek io mungkin merupakan solusi termudah, dengan flush manual setiap N detik per detik. Saya bisa membayangkan strategi yang lebih bagus, tetapi sesuatu yang dekat dengan salah satu pilihan itu seharusnya berhasil.

Saya mengubahnya sehingga sekarang secara eksplisit menetapkan kebijakan buffering ke "line buffering" (== flush ketika menulis termasuk \n , yang merupakan kasus untuk 100% penulisan dalam kasus kami) saat membuka file untuk menulis. Jika Anda menarik dan mencobanya sekarang, Anda akan segera melihat file tumbuh.

Hebat! Terima kasih banyak atas perhatian Anda yang cepat!

Mengingat ini telah diterapkan (dalam # 227) dan akan dirilis dengan asciinema 2.0 yang akan datang, saya menutup masalah ini.

Catatan: jika ada yang ingin mencoba ini maka checkout cabang v2 .