Add design doc for Go labels#465
Conversation
Co-authored-by: Felix Geisendörfer <felix@felixge.de>
| - When disabled custom labels has little to no impact on performance or memory usage of the profiler | ||
| - Custom labels should be limited so that even if a program has thousands of eligible labels the number supported is reasonably small (mostly enforced by eBPF itself) | ||
| - Custom labels should be short and have fixed memory overhead | ||
| - The custom labels should be made available to the reporter backend but otherwise it should be left up to implementors what to do with them |
There was a problem hiding this comment.
To fit into OTel it would be great to make the costum labels available with the OTel SemConv. Package reporter should just be an implementation detail.
There was a problem hiding this comment.
How does one make something available with the OTel SemConv package?
There was a problem hiding this comment.
Taking environment variable as example, information like labels can be provided as attribute:
opentelemetry-ebpf-profiler/reporter/internal/pdata/generate.go
Lines 230 to 233 in afbda36
From a quick lock, currently there is no specific OTel SemConv for labels afaict. But we should use a label that is commonly agreed until there is a OTel SemConv variant. Where this label key/value pair is used, e.g. in package reporter, then just becomes an implementation detail.
There was a problem hiding this comment.
So should I add something like this to the custom labels PR:
https://gist.github.com/gnurizen/1b2c6bd8904a603d8ed621d57e28c83a
florianl
left a comment
florianl
left a comment
There was a problem hiding this comment.
Just some minor nits. The overall idea sounds good to me.
christos68k
left a comment
christos68k
left a comment
There was a problem hiding this comment.
Should we also merge this now since the PR got merged? @gnurizen if there's follow up work that includes changes to this design document we can open a new PR.
5 participants
No description provided.