[8.17](backport #6444) [otel/kube-stack]: Add gateway collector #6990
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?s=60&v=4){kind=small}
* feat: move telemetry aggregation and forwarding to gateway * ci: use Elastic envs in gateway * chore: add changelog entry * fix: format values file * feat: add apm loadbalancing * chore: increase resource limits * revert resource limits increase * chore: remove config warnings * docs: add Gateway collectors section * revert: enable daemonset storagechecks * rename metrics/otel pipeline and use signaltometrics * unify k8s and host metrics pipelines * use default traceID as loadbalancing routing_key * chore: reuse k8s integration test helpers * format values with Helm linter * replace loadbalancing in favor of headless otlp * Update testing/integration/otel_helm_test.go Co-authored-by: Panos Koutsovasilis <[email protected]> * Update testing/integration/otel_helm_test.go Co-authored-by: Panos Koutsovasilis <[email protected]> * rename k8s values options helper function * move process attributes remove processor to gateway * add batch processor for aggregation pipeline * enable compression for cluster otlp connections * chore: remove elastic endpoint references * fix: do not generate service's signals for non apm data * Revert "fix: do not generate service's signals for non apm data" This reverts commit ffa6620. * fix: set agent.name as edot-collector * fix: enable daemon hostNetwork * set unknown as default signaltometrics agent.name resource attribute * remove signaltometrics for metrics-only services --------- Co-authored-by: Panos Koutsovasilis <[email protected]> (cherry picked from commit daed81e)
mergify
bot
requested review from
andrzej-stencel and
pchila
and removed request for
a team
rogercoll
approved these changes
Feb 24, 2025
|
It requires the routing connector to be backported #6996 |
|
💚 Build Succeeded
History
cc @rogercoll |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR adds a new K8s deployment of the EDOT collector named "gateway". The main purpose of this new deployment is to simplify the daemonset collector configuration and unify managed/self-managed scenarios. The gateway collector configuration contains all Elastic's custom Otel components needed for the signals transformations in self-managed scenarios, which are currently configured in the daemonset collector.
Elastic configured components in the "Gateway" collectors (previously in the daemonset):
Another important change is that the Gateway collectors will forward the Otel data to Elasticsearch, the daemonset and cluster collectors configurations have been updated to export all collected data to the corresponding Gateway OTLP endpoint. Although the daemonset collectors are still configured to collect the auto-instrumentation OTLP data, the data is load balanced (loadbalancing exporter) to the gateway collectors based on the service name.
Additional context: https://github.com/elastic/opentelemetry-dev/issues/587
Why is it important?
The key benefit of this architecture is to decouple data collection from data transformations (e.g. APM enrichment and aggregations), for managed scenarios, users would just need to remove (or comment) the "gateway" collector configuration. Note that moving the data processing from a k8s "daemonset" to a "deployment", it eases its horizontal scaling.
Checklist
./changelog/fragmentsusing the changelog toolDisruptive User Impact
How to test this PR locally
Related issues
Questions to ask yourself
This is an automatic backport of pull request #6444 done by [Mergify](https://mergify.com).