otel-profiling-agent
otel-profiling-agent copied to clipboard
elastic
Design document for collector API
In the context of providing an ebpf profiling library for generic Go applications, the alternative solution (separating OTEL collector code into its own package) looks preferable to me.
Based on the feedback from this document, I have changed the document to use a subpackage, named collector.
are there conflicts with agent startup?
There shouldn't be. Importing a package as a library doesn't run the main() method.
signal handlers? how will configuration work?
This seems unrelated to the subject of this design document.
signal handlers? how will configuration work?
This seems unrelated to the subject of this design document.
The reason I ask is because traditionally we haven't done design documents unless there's sufficient complexity (e.g. experiments that need to be designed to de-risk approaches, multiple trade-offs, implementation complexity) to warrant the effort. Since I wasn't involved in the discussion that led to this, I'll let others (maybe @rockdaboot) chime in. I'll approve this as LGTM.
signal handlers? how will configuration work?
This seems unrelated to the subject of this design document.
The reason I ask is because traditionally we haven't done design documents unless there's sufficient complexity (e.g. experiments that need to be designed to de-risk approaches, multiple trade-offs, implementation complexity) to warrant the effort. Since I wasn't involved in the discussion that led to this, I'll let others (maybe @rockdaboot) chime in. I'll approve this as LGTM.
Before this design document (or RFC), there were those two options outlined in the doc and it wasn't clear to me how to decide for or against one of those. They both come with pros and cons (or maybe just a matter of taste!?). So when @damien ask me whether we should have something written down, like an RFC / design document, I said yes please.
Actually, even if it looks trivial and doesn't contain deep technical considerations, it adds value (to me at least) and allows people to re-read it in the future. I wish we had rather more than less RFCs.
It has not. That is why the receiver can't be part of collector-contrib and will need its own distribution. We can implement the API and have our requirements in our own distribution, but not in the main one.