-
Notifications
You must be signed in to change notification settings - Fork 4
Integrating tracer into object lifecycles #403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: staging
Are you sure you want to change the base?
Conversation
Interestingly, a lot of tests are failing. That shouldn't really happen as the patch should not interfere with the actual functioning of the code. This probably flew under the radar as I was focusing on getting the spans working rather than doing a full test each change. I'll have to dig into this. On the other hand, I've made |
03ddbf3
to
7e3b0f0
Compare
I'll need you to work on this yourself. Also consider backwards compatibility or is it "side-compat" with open tracing. It may be possible to reuse their ecosystem.
|
I did some work on the visualiser, and this is what we came up with. The red lines are without an end span event, and the blue ones are with. If spans don't have a corresponding end event, they are coloured differently. I do notice something pretty interesting here -- the destroy method on
Another thing to note is that |
Actually, after checking the Polykey source code, I can see that the destroy methods are called only when Polykey agent is destroyed. In this case, how should I handle the create/destroy events in |
There are browser analogues to crypto and perf. Now that we have ESM we can do things like import adapter's that switch implementation. |
Tracing should live beyond the agent itself. It is pre-and-post agent object. Also I want you to try doing vertical scroll. Not horizontal scroll. Plus I want you to create forking and merging lines. |
Also try projecting into logical/vector time rather than real time. |
Over a 30-second run, the tracer system emitted around 30k lines of events, totalling around 700KiB. We probably need to design a more efficient format to store the data in. We probably need to write the data in a more binary format, as it already leans well into it. Most of the fields can easily be represented in binary or originate as binary arrays. For example, the Moreover, I have encountered some interesting issues with the span emission. The parents are often malformed. For example, some |
You can keep it as text for now to keep it simple. Log rotation can be used if it hits 1 MiB. But later there is a more compressed binary json. In js-db we looked into using something like that before. |
And it was not bson!! |
We can keep it JSON for now but simplified keys and deduplicating can help a lot here. Use an ENUM for the keys, so rather than each key being repeated "id","start", "name", etc, the ENUM will map it to 1, 2, 3. For deduplication rather than repeat the ID over and over again, include a line that maps the ID and Name to a number and then reference this number when you need to know what it is. You'll cut out 80% of the size doing this without the need for a binary format. |
Yes let's not overoptimize ahead of time. Just push it to the edge. Run on a beefier computer if necessary. Swap with Matthew? |
I want to see multi-gigabyte log files before you start doing any optimisation. |
Stream consumption obviously, don't load it all into memory. Or use memory mapping if you have binary structure that is one to one to the loaded memory and disk layout. Use chatgpt to help you understand how "BIG data is managed". |
Description
To gain observability into polykey, we are integrating a tracer system similar to OpenTracing. This is currently just an experiment. The visualiser and the integration is being tracked in this PR. As we are currently monkey-patching to get the spans integrated, that code cannot be shown in the PR. I might make some comments if I need feedback
Issues Fixed
Tasks
Final checklist