Add feature flags for running beats as OTel receivers #6486
Conversation
This is for internal usage only. No documentation or changelog is added for this.
andrzej-stencel
added
Team:Elastic-Agent-Control-Plane
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
There was a problem hiding this comment.
I worry that this feature flag is too broad. We might want to define a few flags to enable this. We want to start with monitoring only so maybe monitoring_as_beatsreceivers would be better. I see beats_as_otel_receivers as meaning that all beat inputs are converted to otel beatsreceivers. I do think we want to get to that level, but we might want to do it in stages. A user might just want to turn on monitoring for now, test it out then turn it on the others once we support those as well. I think if we don't add some levels of enablement here, it because an all on or nothing and that is probably not something we would want.
I was leaning this more to a flag in the monitoring configuration so it just turned on specifically to monitoring.
I agree we might want separate feature flags for monitoring and for data collection. Given that this feature flag is not documented, I believe we can always change, rename, delete, add new flags later, right? I think it would be best to add a specific feature flag together with the functionality it implements, as a single task. A separate task for just creating a feature flag in isolation from the functionality it guards is prone to deliberations like this. I propose to close this task and add new feature flag(s) as part of one or both of the tasks: Alternatively, I can create two separate feature flags for monitoring and data collection as part of this task. As I said, we can always modify the approach later. |
|
I've added another feature flag "monitoring_with_otel" in 56ee320. Let me know what you think about the naming. |
andrzej-stencel
changed the title
|
| beatsAsOtelReceivers bool | ||
|
|
||
| // monitoringWithOtel indicates if the Agent should use OpenTelemetry components for self-monitoring instead of Beats. | ||
| monitoringWithOtel bool |
There was a problem hiding this comment.
I think there is a case where we want to run monitoring with native otel in the future. So we might just want to use a little different name. What about monitoringWithOtelReceivers? Just so in the future we want to add monitoringWithOtel where it is using native filelog receiver and a native metric receiver.
| @@ -37,6 +41,12 @@ type Flags struct { | |||
| fqdnCallbacks map[string]BoolValueOnChangeCallback | |||
|
|
|||
| tamperProtection bool | |||
|
|
|||
| // beatsAsOtelReceivers indicates if the Agent run Beats as OpenTelemetry receivers like filebeatreceiver etc. | |||
| beatsAsOtelReceivers bool | |||
There was a problem hiding this comment.
I don't think this should just be a boolean. I think this needs to be an array of input types to run as otel beatsreceivers. That way the feature can be enable per input type at a time for the user. They will want to test out 1 input, see if it works then enable the next type. They will not want to be a change all. Possible that a * can be used to mean all of them, but I think we need a way to limit it to specific input types.
What does this PR do?
Adds new Agent feature flag "beats_as_otel_receivers". This is for internal usage only. No documentation or changelog is added for this.
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files[ ] I have added an entry in./changelog/fragmentsusing the changelog tool[ ] I have added an integration test or an E2E test