paritytech / paritytech/trie

eBPF stack trace trie design

Open
#128 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
274
Forks
72
PR merge metrics
No merged PRs in 30d

Description

https://github.com/iovisor/bcc/blob/master/tools/profile.py (what Pyroscope uses under the hood) is a far from optimal logging format for stack traces. I have a design in mind for a binary logger to save network bandwidth when exporting traces.

The logger would emit references to immutable trie pointers. When done, or when the trie overfills the memory limit - it would dump the trie tagged with the memory pointers.

Does this sound feasible? A more compressed version would have base64 counters on each trie node.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading tools/profile.py, the referenced stack-trace logging format, and the repository's trie implementation. The issue does not name an implementation entry point, tests, or a settled acceptance criterion; progress would first require agreeing whether the proposed binary logger and trie-pointer design is feasible.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, rust
Domain
backend, data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.