diff --git a/rfcs/0011-opentelemetry-tracing/README.md b/rfcs/0011-opentelemetry-tracing/README.md index 8b4b4ce0..f362a826 100644 --- a/rfcs/0011-opentelemetry-tracing/README.md +++ b/rfcs/0011-opentelemetry-tracing/README.md @@ -9,28 +9,28 @@ Must be one of `provisional`, `implementable`, `implemented`, `deferred`, `rejec **Creation date:** 2025-04-24 -**Last update:** YYYY-MM-DD +**Last update:** 2025-05-15 ## Summary -The aim is to collect traces via OpenTelemetry across all Flux related objects, such as HelmReleases, Kustomizations and among others. These may be sent towards a tracing provider where are going to be stored and visualized. Thereby, this may involve a new API definition obj called `Trace`, which may be capable of linking all the `EventSources` and send them out to a reusable tracing `Provider`. In this way, it could facilitate the observability and monitoring of Flux related objects. +The aim is to be able to collect traces via OpenTelemetry (OTel) across all FluxCD related objects, such as HelmReleases, Kustomizations and among others. These may be sent towards a tracing provider where may be potentially stored and visualized. Flux does not have any responsability on storing and visualizing those, it keeps being completely stateless. Thereby, being seamless for the user, the implementation is going to be part of the already existing `Alert` API Type. Therefore, `EventSources` is going to discriminate the events belonging to the specific sources, which are going to be looked up to and send them out towards the `Provider` set. In this way, it could facilitate the observability and monitoring of FluxCD related objects. ## Motivation -This RFC was born out of a need for end-to-end visibility into Flux’s multi-controller GitOps workflow. At the time Flux was one monolithic controller; it has since split into several specialized controllers (source-controller, kustomize-controller, helm-controller, notification-controller, etc.), which makes tracing the path of a single “Git change → applied resource → notification” much harder. +This RFC was born out of a need for end-to-end visibility into Flux’s multi-controller GitOps workflow. At the time Flux was one monolithic controller; it has since split into several specialized controllers (source-, kustomize-, helm-, notification-, etc.), which makes tracing the path of a single "Source change → applied resource → notification” much harder. Additionally, +users may not have to implement tools/sidecars around to maintain. Correlate a Git commit with all downstream actions. You want one single trace that (via multiple spans) shows: -- Source-controller current revision ID. -- Any Kustomize or Helm reconciliations that ran. +- Alert reference based on a unique ID (root span). +- Any source pulling new content based on a new Digest Checksum. +- Any subsequent rencolitiation that ran. - Events emitted and notifications sent by the notification-controller. On top of this, can be built custom UIs that surface trace timelines alongside Git commit or Docker image tags, so operators can say “what exactly happened when I tagged v1.2.3?” in a single pane of glass. -By extending Flux’s CRD objects, users can manage tracing settings (sampling rates, backends, object filters). Therefore, users may not have to implement tools/sidecars around to maintain. - ### Goals -- **End-to-end GitOps traceability:** Capture the traces that follows a Git change through all Flux controllers for simply debugging and root-cause analysis. -- **Declarative, CRD-drive configuration:** Reuse the concept of `Provider` and a similar definition as `Alerts` to build a new API/CR called `Trace`. Therefore, users can link `EventSources` and `Provider` where trace will be sent. Additionally, other setting can be set as sampling rates. -- **Notification-Controller as the trace collector:** Leverage the notification-controller's existing event watching pipeline to ingest reconciliation events and turn me into OpenTelemetry spans, being forwarwed to an OLTP-compatible backend - `Provider`. -- **Cross controller span correlation:** Ensure spans are emitted from multiple, stateless controller can be stiched together into a single trace by using Flux "revision" annotation (GitRepository sync to a downstream Kustomization/HelmRelease reconciliations). +- **End-to-end GitOps traceability:** Capture the traces that follows "a Git change" (any source) through all FluxCD controllers for simply debugging and root-cause analysis. +- **Declarative, CRD-drive configuration:** Reuse the concept of `Alerts` to be able to populate this feature over, out-of-the-box. Therefore, users can link `EventSources` and `Provider` where trace will be sent. +- **Notification Controller as the trace-collector:** Leverage the notification-controller's existing event watching pipeline to ingest reconciliation events and turn me into OpenTelemetry spans, being forwarwed to an OLTP-compatible backend - `Provider`. +- **Cross-controller span correlation:** Ensure spans are emitted from multiple, stateless controller can be stiched together into a single trace by using Flux "revision" annotation. ### Non-Goals - **Not a full-tracing backend:** We won't build or bundle a storage/visualization system. Users may have to still rely on a external collector for long-term retention, querying and UI. @@ -38,14 +38,10 @@ By extending Flux’s CRD objects, users can manage tracing settings (sampling r - **Not a replacement for metrics or logs:** Flux's existing Prometheus metrics and structural logging remain the primary way to monitor performance and errors. Tracing is purely for request-flow visibility, not for time-series monitoring or log aggregation. - **No deep-code lelve spans beyond CRUD events:** Will emit spans around high-level reconciliation steps (e.g. "reconcile GitRepository", "dispatch Notification"), but we're not aiming to instrument every internal function call or library method within each controller. - **Not a service mesh integration:** It's not plan of the scope tieing this into Istio, Linkerd, or other mesh-sidecar approaches. It's strictly a controller-drive, CRD-based model. -- **No per-span custom enrichment beyond basic metadata:** While Trace CRD will let you filter which Flux object kinds to trace (`EventSources`), it won't support (at least initially) complex span attributes or tag-enrichment rules. You may have to handle those in your downstream collector/processor if needed. -- **Not a replacement for user-driven OpenTelemetry SDKs:** If you already have a Go-based operator that embed OpenTelemetry's SDK directly, this feature won't override or duplicate that. Think about it as a complementary, declrartive layer for flux controllers. +- **No per-span custom enrichment beyond basic metadata:** At least intially, it won't support complex span attributes or tag-enrichment rules. You may have to handle those in your downstream collector/processor if needed. +- **Not a replacement for user-driven OpenTelemetry SDKs:** If you already have a Go-based operator that embed OpenTelemetry's SDK directly, this feature won't override or duplicate that. Think about it as a complementary, declarative layer for flux controllers. ## Proposal - -Add a new `Trace` custom definition in Flux's notification-controller. Under this, there is a conjuntion of: `EventSources` Flux's related objects to get the traces on and `Provider` external system where all the traces are going to be sent towards. - -Additionally, as part of the `Provider`, we may have to onboard new type(s) to tackle OLTP compliant systems. +The implementation will extend the notification-controller with OpenTelemetry tracing capabilities by leveraging the existing Alert API object model. This approach maintains Flux's declarative configuration paradigm while adding powerful distributed tracing functionality. -### User Stories - -#### Story 1 - > As a cluster administrator, I want to see everything that happened - > since a git change occurred in a single trace. All the applied yaml - > files in Source Controller, notifications that went out to Notifications - > Controller, all the HelmReleases that were applied in Helm-Controller, - > Kustomize Controller, etc... - -For instance, having the following setup: +### Core Implementation Strategy +1. **Extend the notification-controller:** Add OpenTelemetry tracing support to the notification-controller, which already has visibility into events across the Flux ecosystem. +2. **Leverage existing Alert CRD structure:** Use the Alert Kind API object as the configuration entry point, where: + - `EventSources` define which Flux resources to trace (GitRepositories, Kustomizations, HelmReleases, etc.). + - `Provider` specifies where to send the trace data (Jaeger, Tempo, or other OpenTelemetry-compatible backends). +3. **Span generation and correlation:** Generate spans for each reconciliation event from watched resources, ensuring proper parent-child relationships and context propagation using Flux's revision annotations as correlation identifiers. +4. **Provider compatibility and fallback mechanism:** The implementation supports any provider that implements the OpenTelemetry Protocol (OTLP). When traces are sent to OTLP-compatible providers (like Jaeger or Tempo), they are transmitted as proper OpenTelemetry spans. For non-OTLP providers, the system gracefully degrades by logging trace information as structured warnings in the notification-controller logs, ensuring no alerting functionality is disrupted. This approach maintains system stability while encouraging the use of proper tracing backends. +This approach allows users to declaratively configure tracing using familiar Flux patterns, without requiring code changes to their applications or additional sidecar deployments. The notification-controller will handle the collection, correlation, and forwarding of spans to the configured tracing backend. +Example Configuration: ```yaml +# Define a tracing provider apiVersion: notification.toolkit.fluxcd.io/v1beta1 kind: Provider metadata: @@ -76,31 +73,37 @@ metadata: namespace: default spec: type: jaeger - address: http://jaeger-collector.jaeger-system.svc.cluster.local:9411 + address: http://jaeger-collector.jaeger-system.svc.cluster.local:9411 # Provider endpoint secretRef: - name: jaeger-secret + name: jaeger-secret # Optional authentication + --- +# Configure an alert (includes the tracing out-of-the-box) apiVersion: notification.toolkit.fluxcd.io/v1beta1 -kind: Trace +kind: Alert metadata: - name: webapp + name: webapp-tracing namespace: default spec: providerRef: name: jaeger eventSources: - - kind: Kustomization + - kind: GitRepository # Source controller resources + name: webapp-source + - kind: Kustomization # Kustomize controller resources name: webapp-backend - - kind: HelmRelease + - kind: HelmRelease # Helm controller resources name: webapp-frontend ``` -#### Story 2 - > I want to build a UI using trace data to track release changes and integrate deeply - > with a Git commit/tag, a Docker image tag, and the GOTK flow of operations +Based on this configuration, the notification-controller will: +- Watch for events from the specified resources. +- Generate OpenTelemetry spans for each reconciliation event. +- Correlate spans across controllers using Flux's revision annotations. +- Forward the spans to the configured Jaeger endpoint - `Provider`. +- This implementation maintains Flux's stateless design principles while providing powerful distributed tracing capabilities that help users understand and troubleshoot their GitOps workflows. ### Alternatives -- Addition of a new `Provider` type to "onboard" OLTP-compliant systems. Could be adressed in generic way, just adding a new type to tackle them all or adding specific integrations for the most relevant ones: [Jaeger](https://www.jaegertracing.io/) & [Zipkin](https://zipkin.io/).