Asciinema: Запись на диск в реальном времени

Созданный на 19 авг. 2015  ·  23Комментарии  ·  Источник: asciinema/asciinema

Действия по воспроизведению:

  • начать запись в файл;
  • убить процесс asciinema (например, закрыть окно терминала);
  • попробуйте найти запись - ее нет.

Смотрите демо .

Было бы очень полезно, если бы asciinema периодически сбрасывал файл записи. Незавершенный файл JSON легко исправить ( asciinema play может это сделать). Потеря записи сеанса временами может вызывать разочарование.

(В моем проекте dayjob есть долгосрочные системные тесты. Я использую asciinema для записи их выполнения, потому что его веб-интерфейс позволяет мне переходить к интересным местам и ускорять тест.)

feature request improvement

Самый полезный комментарий

@sickill - Спасибо, приятно слышать. Я буду следить за этим. Я бы предпочел asciinema скрипту, потому что я могу встроить контент в нашу Wiki для других системных администраторов.

Все 23 Комментарий

Хороший улов @vvv. Похоже, это довольно легко исправить.

Я смотрел на это. Текущие мысли:

asciinema не генерирует поток JSON на лету - он генерирует всю строку JSON и сохраняет ее в файл после захвата всего stdout. В основном это связано с тем, как работает маршаллер JSON в Go.

Одна из возможностей - выполнить сброс в файл 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 в конечном файле.

Что касается восстановления, вы можете легко сделать это самостоятельно (просто перемещая строки в vim).
Также может быть новая команда asciinema recover foo.json.tmp foo.json чтобы автоматизировать это (не уверен, что делать восстановление частью asciinema play лучше всего).

Одна из возможностей - выполнить сброс в файл tmp ( foo.json.tmp если вы записываете в foo.json ).

Звучит отлично! Эта функция будет напоминать файлы автоматического сохранения Emacs ( #foo.json# ) и файлы восстановления Vim ( .foo.json.swp .)

Что касается восстановления, вы можете легко сделать это самостоятельно (просто перемещая строки в vim).

Честно говоря, я бы предпочел команду «восстановить» или даже облегченный вариант -r | --recover , чем возиться с файлом автосохранения вручную.

Чтобы заявить об этом открыто, # 82 также исправит эту проблему.

@xloem # 82 относится только к случаю, когда вы rec + выгрузили на asciinema.org за один шаг. asciinema rec demo.json также позволяет вам записывать в файл без автоматической загрузки на сайт, и поэтапная запись на диск в этом случае также будет полезна.

Я начал работать над черновиком формата asciicast v2 в # 196, который должен хорошо решать запись в реальном времени на диск (и конвейер, сеть, что у вас есть).

Прямая ссылка на документ из этого PR: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

Обратная связь высоко ценится.

@sickill Я не понимаю, как изменение формата файла ( NDJSON вместо JSON) применяется к инкрементному обновлению выходного файла. Могли бы вы объяснить?

@vvv в обычном файле JSON у вас есть один объект, и вы не можете писать в него постепенно, он должен быть записан целиком (технически вы можете, но если вы сбой и т. д., вы получите недопустимый файл JSON, пропуская закрывающий скобки). С NDJSON (или JSONLines, который почти идентичен) у вас есть несколько объектов JSON в одном файле, каждый в отдельной строке. Таким образом, вы можете добавлять новые строки с новыми данными и останавливать / аварийно завершать работу по желанию и никогда не оставлять файл недействительным.

Я обновил черновик документа формата asciicast v2, чтобы прояснить мотивацию / проблемы, которые он решает.

@sickill было бы хорошо, если бы время начала сеанса сохранялось в исходных метаданных. Это может быть извлечено с помощью другого инструментария для обеспечения проверяемых сеансов ssh.

Кроме того, возможность «вводить» метаданные может быть интересной, поэтому вы потенциально можете пометить созданный сеанс такими вещами, как:

  • пользователь, который ssh'd
  • имя хоста
  • серверная среда

И выставить это в каком-нибудь внешнем интерфейсе.

РЕДАКТИРОВАТЬ: Кажется, есть PR для формата, поэтому я буду там комментировать :)

В настоящее время у меня есть asciinema, настроенный для ведения журнала сеансов удаленных сотрудников
подключение через ssh к защищенной сети через jumphost. возможность экономить,
сеансы потоковой передачи и воспроизведения, когда они происходят, значительно улучшили бы
полезность asciinema в указанном сценарии.

Во вторник, 25 апреля 2017 г., в 5:17, Хосе Диас-Гонсалес <
[email protected]> написал:

@sickill https://github.com/sickill одна вещь, которая была бы хорошей, была бы
быть, чтобы время начала сеанса сохранялось в исходных метаданных.
Это может быть извлечено с помощью другого инструментария для обеспечения проверяемых сеансов ssh.

Кроме того, возможность «вводить» метаданные может быть интересной, поэтому вы
потенциально может пометить созданный сеанс такими вещами, как:

  • пользователь, который ssh'd
  • имя хоста
  • серверная среда

И выставить это в каком-нибудь внешнем интерфейсе.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

Я использую asciinema (ну, больше нет, я возвращаюсь к сценарию из-за этой проблемы), чтобы вести учет всех моих сеансов терминала с CYA, а также для справки, если я забыл, что делал на сервере X на прошлой неделе в 3 вечера. Проблема в том, что поскольку он сбрасывается только при успешных выходах, половина моих сеансов не имеет данных. Например, закрытие окна для зависшего сеанса приводит к полной потере записи сеанса. Это было неожиданное поведение и весьма разочаровывающее.

Формат @gizmonicus asciicast v2 и запись на диск в реальном времени являются наивысшим приоритетом для следующего выпуска. Нет ETA, но это скоро произойдет.

@sickill - Спасибо, приятно слышать. Я буду следить за этим. Я бы предпочел asciinema скрипту, потому что я могу встроить контент в нашу Wiki для других системных администраторов.

@timofonic Вы можете задать свой вопрос здесь и терпеливо ждать. Нет необходимости спамить всех, пингуя пользователей таким образом.

Обновление: запись на диск в реальном времени была реализована в # 196 и будет частью следующего выпуска.

Если вы хотите провести бета-тестирование, проверьте ветку develop и запустите ее из каталога проверки с помощью: python3 -m asciinema rec filename . Буду очень признателен за отзывы о том, как это работает в различных дистрибутивах Linux и macOS 👋

Примечание: на сегодняшний день сервер и веб-плеер не поддерживают новый формат asciicast, поэтому его можно использовать только для локальной записи и воспроизведения в терминале.

Отличная работа @sickill! Я только что протестировал это и смог заставить его работать (Ubuntu 17.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(...) .

Сказав это, я также заметил, что он написан кусками размером ~ 8 КБ, так что здесь определенно происходит некоторая буферизация. Я подозреваю, что здесь виноват TextIOWrapper Python.

Как вы думаете, что здесь лучше всего? Мы можем отключить буферизацию для открытого объекта io или реализовать явный триггер, либо f.flush() при каждой записи, или подсчет байтов / времени и сброс при достижении порогового значения.

Я предполагаю, что отключение буферизации для объекта io может быть самым простым решением с ручным сбросом каждые N секунд в секунду. Я мог бы вообразить более причудливые стратегии, но что-то близкое к одному из этих вариантов должно помочь.

Я изменил его, так что теперь он явно устанавливает политику буферизации на «буферизацию строки» (== flush, когда запись включает \n , что в нашем случае имеет место для 100% операций записи) при открытии файла для записи. Если вы потянете и попробуете сейчас, вы увидите, что файл сразу же увеличивается.

Чудесно! Большое спасибо за ваше внимание!

Учитывая, что это было реализовано (в # 227) и будет выпущено с грядущей версией asciinema 2.0, я закрываю эту проблему.

Примечание: если кто-то хочет попробовать это, то проверьте ветку v2 .

Была ли эта страница полезной?
0 / 5 - 0 рейтинги