Create central trace health check
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 38/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- performance
Research direction
Start by surveying the TraceLens modules that accept traces and perform analysis, then trace how profiler options such as add_python_func=True and with_stack=True are represented. Define the lightweight health checks and the configuration or environment bypass, ensuring modules invoke the check before analysis and that users can identify incomplete or unsuitable traces.
Written by the indexing model from the issue text.
Description
There are many TraceLens modules and they each take in a trace and perform some kind of analysis. It would be useful if there was a file that performs a "trace health" check to see if the trace is analyzable/complete and have all the TraceLens modules call this health check before analysis. This could check for many things:
- Are all the expected kernels present? Are any kernels dropped? This is something that often goes by unnoticed in trace analysis. Profilers could be buggy and drop kernels and the user wouldn't know
- Was the trace collected with add_python_func=True and with_stack=True? Users may not know that these flags are often needed to pass into profiler for some TraceLens use cases (needed if --include_call_stack is passed into generate_perf_report)
- Is the trace in graph mode or eager mode? If it's in graph mode, analysis would be difficult without a corresponding capture trace
If we create this, we'd have to make sure it's very lightweight and give users the option to bypass this health check with some kind of config or env var.
- Dominant language
- Python
- Stars
- 101
- Forks
- 34
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 78
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from AMD-AGI/TraceLens
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
2 graph capture handling bugsPossibly taken @gabeweisz claimed this 1 day ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
All issues in AMD-AGI/TraceLens
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
comp/desktop P3 type/feature
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NousResearch/hermes-agent#154285 ·
Maintainers usually reply within 1 day
-
docs: qualify copied and custom kubectl debug policy notesPossibly taken @nym01 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
kubescape/cel-admission-library#166 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
SACGF/variantgrid#2804 · 1 comment ·
Maintainers usually reply within 1 day
-
[BUG] HTTP lifecycle dispatch treats a NO_PROXY-only environment as corporate egress and skips the resolve-and-pinned sessionPossibly taken @bodapatisaikrishna claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day