feat(collector): add allow_startup_failure config option

[rushabh-exe]

Fixes #1214

Description

Adds a new allow_startup_failure boolean config option to the profiler
receiver. When set to true, errors during Start() are logged but not
returned to the OTel Collector — so it keeps running without profiling
instead of failing entirely.

The Problem

eBPF profiler startup can fail for reasons outside the user's control
(old kernel, missing permissions, containerized environments). Right now
that failure takes down the entire collector, including logs and metrics
which are usually more critical than profiling.

Solution

Added allow_startup_failure to the config. When true, Start() catches
the error, logs it, and returns nil so the collector continues normally.

Also extracted a small profilerController interface to decouple the
internal Controller from the concrete type — this allowed adding the first
unit tests for the collector/internal package.

Testing

Added three unit tests:

• startup failure with flag true → returns nil, logs error
• startup failure with flag false → propagates error
• successful startup → always returns nil

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: rushabh-exe / name: rushabh (1093f09, 27f07b4, 5520ed8, a39e995, a9d0e5a, e835a71, f042de1)

[dmathieu]

While this looks good to me, I'm not sure you should be doing profiling in the same collector as traces, metrics and profiles.
ebpf-profiler needs to run in an agent collector (daemonset), while the recommended pattern for all other signals is to have a cluster-wide collector (deployment).

Since this pattern isn't really what we've been advising for, I would hide this behavior behind a feature gate.

[christos68k]

While this looks good to me, I'm not sure you should be doing profiling in the same collector as traces, metrics and profiles. ebpf-profiler needs to run in an agent collector (daemonset), while the recommended pattern for all other signals is to have a cluster-wide collector (deployment).

Since this pattern isn't really what we've been advising for, I would hide this behavior behind a feature gate.

Shouldn't feature gate be something that the downstream implementors decide about / put together depending on the requirements of the downstream collector? Essentially, this upstream PR makes this bit functionality available but is not opinionated in how it should be used.

[dmathieu]

Yes, but this assumes profiles can fail to start (and never start), which would be fine with purely a log entry. That's probably not the behavior you want when you're using a collector dedicated to doing profiling.
In that configuration, you likely want your collector to actually receive profiles, or alert you with an actual failure.

[dmathieu]

There is a precedent for feature gates that enable specific opinionated features.
See service.AllowNoPipelines for example: https://github.com/open-telemetry/opentelemetry-collector/blob/main/service/metadata.yaml#L192-L196

[rushabh-exe]

Any update on the direction here?

[christos68k]

Any update on the direction here?

Let's switch this to error_mode (see @rogercoll's comment here)

[rushabh-exe]

Updated, switched to ErrorMode with ignore and propagate values following the OTTL pattern!

[dmathieu]

Could you add tests?

[rushabh-exe]

Sure, I can add tests. Should I cover just config validation (empty ErrorMode defaults to propagate, valid modes pass, invalid returns error) or also the controller Start() behaviour with error modes?

[dmathieu]

Ideally, both.

[rushabh-exe]

Added config validation tests. For controllerStart() tests I'd need to bring back the profilerController interface to mock startup failures, but @christos68k previously mentioned removing it since it was only used in one spot. Should I still add it back or is there another way you'd prefer?

[rushabh-exe]

Moved the ErrorMode default to defaultConfig() in factory.go, that's where all the other defaults live. Empty error_mode is now a validation error instead of silently defaulting. Also added a Start() integration test using WithReporterFactory