Conversation
Signed-off-by: Giuseppe Ognibene <giuseppe.ognibene@coralogix.com>
|
|
||
| **Appolly** is the component that handles all application-level tasks and generates traces and metrics. Unlike Netolly, it uses different types of eBPF probes (such as `uprobe`, `kprobe/kretprobe`) and introduces the concept of a `tracer`, which is the component responsible for tracing a given type of application. Specifically, we can divide tracers into two categories: `gotracer` and `generictracer`. The latter includes the GPU tracer and the log enricher (which handles trace-log correlation). | ||
|
|
||
| It also has two common tracers: |
There was a problem hiding this comment.
Need to add log enricher here after latest changes
|
|
||
| ## Appolly | ||
|
|
||
| **Appolly** is the component that handles all application-level tasks and generates traces and metrics. Unlike Netolly, it uses different types of eBPF probes (such as `uprobe`, `kprobe/kretprobe`) and introduces the concept of a `tracer`, which is the component responsible for tracing a given type of application. Specifically, we can divide tracers into two categories: `gotracer` and `generictracer`. The latter includes the GPU tracer and the log enricher (which handles trace-log correlation). |
There was a problem hiding this comment.
gputracer and logenricher are two separate tracers which are not part of generictracer
There was a problem hiding this comment.
ok for the logernicher but the goutracer is enabled inside newGenericTracersGroup so it should be considered generic?
There was a problem hiding this comment.
these are all the tracers:
// the common tracer group should get loaded for any tracer group, only once
func newCommonTracersGroup(cfg *obi.Config) []ebpf.Tracer {
var tracers []ebpf.Tracer
// Add tracers based on configuration
// Enables tpinjector which handles context propagation via both HTTP headers (sk_msg) and TCP options (BPF_SOCK_OPS)
if cfg.EBPF.ContextPropagation.HasHeaders() || cfg.EBPF.ContextPropagation.HasTCP() {
tracers = append(tracers, tpinjector.New(cfg))
}
// Enables tctracer which handles context propagations via IP options only (TC egress/ingress)
if cfg.EBPF.ContextPropagation.HasIPOptions() {
tracers = append(tracers, tctracer.New(cfg))
}
// Enables log enricher which handles trace-log correlation
if cfg.EBPF.LogEnricher.Enabled() {
logEnricher := logenricher.New(cfg)
if logEnricher != nil {
tracers = append(tracers, logEnricher)
}
}
return tracers
}
func newGoTracersGroup(pidFilter ebpfcommon.ServiceFilter, cfg *obi.Config, metrics imetrics.Reporter) []ebpf.Tracer {
return []ebpf.Tracer{gotracer.New(pidFilter, cfg, metrics)}
}
func newGenericTracersGroup(pidFilter ebpfcommon.ServiceFilter, cfg *obi.Config, metrics imetrics.Reporter) []ebpf.Tracer {
var tracers []ebpf.Tracer
// Add tracers based on configuration
tracers = append(tracers, generictracer.New(pidFilter, cfg, metrics))
// Enables GPU tracer
if cfg.EBPF.CudaInstrumentationEnabled() {
tracers = append(tracers, gpuevent.New(pidFilter, cfg, metrics))
}
return tracers
}
tpinjector, tctracer (now deleted), logenricher, generictracer, gotracer and gputracer.
The gputracer case I believe it's a bug, I think it's been added there because it needs the pidfilter from the generictracer to work but ideally it should be able to run even when the generictracer is not loaded, just like the logenricher
There was a problem hiding this comment.
well, for the gputracer I'll check and see if it's worth moving it
|
|
||
| It also has two common tracers: | ||
| - `tctracer`: handles context propagations via IP options only (TC egress/ingress) | ||
| - `tpinjector`: handles context propagation via both HTTP headers (sk_msg) and TCP options (BPF_SOCK_OPS) |
There was a problem hiding this comment.
I don't think this is 100% correct, sock_ops is for tracking, the sk_msg programs are triggered on the tracked socks. I'd keep it generic with "handles context propagation"
There was a problem hiding this comment.
I guess we should update also this comment because I used it for the doc
| ``` | ||
| - **HTTPClientRequestSize**: | ||
| ``` | ||
|
|
There was a problem hiding this comment.
yep because I didn't find good example, I'll check
|
|
||
| ## Notes | ||
|
|
||
| You can find more metric examples directly in the OBI [CI](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/actions) logs or in the [integration](../internal/test/integration/) tests. |
There was a problem hiding this comment.
I wouldn't point users to the CI logs from the documentation
There was a problem hiding this comment.
This doc is in devdocs so for developers, don't you think it's a good idea to point to the CI logs?
3 participants
WIP. Would appreciate some feedback.