Standardized Client Tracing #187
Description
Starting with the the Javascript client + core codebases, implement trace logging. The requirements are as follows:
- Can be disabled by default, where it doesn't affect performance.
- Easy to use to instrument function performance & log additional logs.
- Has the concept of topic areas, allowing the viewer to "listen" to specific sections of the codebase.
- The "backend" of the trace logger is extendable. This will allow us to implement loggers that write to a file, to the console, or send all events to an external logging service.
Tracing can be used to:
- Diagnose hard to solve issues in the core of the codebase. For example, unsure why your URI isn't getting resolved? Turn on tracing for the "uri-resolver" topic, and walk through the trace stack to figure out what's going wrong.
- Performance benchmarking.
- Create a standard set of "required trace events" that each client is expected to implement. This will allow us to (automatically) gather trace logs from various client implementations (JS, C#, C++, Rust, Python, etc), and "diff" them with a known good to make sure they implement the Web3API standard appropriately.
In order to not come up with something custom for a very common problem, I suggest we use something that already exists. Here's something I found that looks like a good candidate: https://opentracing.io/
It supports lots of languages, is fully open source, and seems to support all needed features described above.