Tracing Tape: simple recording and viewing of application traces

[soehrl]

I love this project and appreciate the effort put into it. Especially the flexibility to inject custom subscribers depending on the user's requirements. There is already a wide variety of different Subscribers for many use cases. However, setting up an environment for viewing span traces is often quite involved, often requiring the user to set up an additional server. I wanted to have a dead-simple solution that writes traces to files for (relatively) short-lived applications you can view afterward. Thus, I developed the tracing-tape project to bridge that gap. It consists of a simple binary format called tracing-tape together with the tracing-tape-recorder and trace-deck crates for recording and viewing trace files. You can see the getting started guide for more information.

The main design goals are:

• simplicity: Recording traces should be dead simple and should not require a complicated setup. The trace-deck viewer is also available online for this purpose.
• low overhead: Writing traces should be fast to be usable in high-performance real-time applications.
• multi-process support: Debugging client-server applications can be tricky. The 'trace-deck' viewer allows loading trace files generated by multiple applications simultaneously and aligns them properly.

These requirements are tailored specifically to my use case and the project is very early in its development, but I think it may be also beneficial for other users. I am looking forward to any feedback! I would also be happy if it could be added to the Related Crates section in the documentation. What would be the procedure here? Do I just create a PR?

[hds]

@soehrl This project looks really interesting and is something that I would love to see it developed more.

Unfortunately when I tried it out I hit a panic when loading the following file and selecting the resource.spawn callsite:
ping-pong_2024-11-20_Wed_16-07-52.tape.zip

[soehrl]

Thank you very much for your feedback! I had a look at your trace file (thank you for providing that). The panic itself is caused by a divide by 0 error due to missing data. This itself is a very easy fix, but I also need to resolve the issue that leads to missing data. I am guessing that you set the subscriber via set_global_default, correct? If that's the case, I am aware of this problem, but ignored it for now (#7). The issue is that I cache all data and write it to disk in chunks. However, if the recorder is not dropped, which is the case when it is set via set_global_default the cached data is not flushed to disk.

I want to add a way to manually flush the data and also provide an option to disable caching. The latter will increase the overhead but does not require manual flushing and provides more information in case the application crashes. Nevertheless, I will also adjust the parser/viewer to be able to handle these incomplete trace files!