[jira] [Work started] (CAMEL-24051) camel-test-infra: add an "observability" service (Grafana/Tempo/Loki OTel-LGTM stack) for local dev and E2E, mirroring OpenShift's observability stack

["Federico Mariani (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-24051 started by Federico Mariani.
------------------------------------------------
> camel-test-infra: add an "observability" service (Grafana/Tempo/Loki OTel-LGTM stack) for local dev and E2E, mirroring OpenShift's observability stack
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24051
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24051
>             Project: Camel
>          Issue Type: New Feature
>          Components: test-infra
>            Reporter: Federico Mariani
>            Assignee: Federico Mariani
>            Priority: Major
>
> h3. Problem / Motivation
> Camel's local dev loop ({{camel run --dev}}) and the Kubernetes export path already wire up {{camel-observability-services}} (Micrometer/Prometheus metrics, health checks, OpenTelemetry tracing) when targeting Kubernetes/OpenShift. However, there is no local backend to receive or visualize that telemetry: {{camel infra run}} can start backing services like Postgres or Artemis, but nothing analogous exists for observability.
> As a result, developers only find out whether traces, metrics, and logs actually work correctly (correct span correlation, meaningful dashboards, sane metric cardinality, etc.) once the application is deployed to a real OpenShift cluster, which typically provides the Red Hat build of OpenTelemetry, the Tempo Operator, Loki/OpenShift Logging, and the Cluster Observability Operator (Grafana). Telemetry problems surface late, in a shared cluster environment, rather than at dev/E2E time on a laptop or in CI.
> h3. Proposed Solution
> Add a new {{camel-test-infra}} service, invocable as {{camel infra run observability}} (same UX as the existing {{camel infra run postgres}} / {{camel infra run artemis}} services), that starts a local all-in-one observability stack via Testcontainers -- for example the {{grafana/otel-lgtm}} image, which bundles an OTel collector plus Prometheus, Tempo, Loki, and Grafana.
> The service should be wired to the same OTLP endpoint / ports / paths that {{camel-observability-services}} already exports (metrics, health, tracing), so that the dashboards, traces, and logs a developer sees locally when running {{camel run --dev}} against this service are the same shape as what they will see after deploying to OpenShift. This closes the local-vs-production observability gap and gives a fast, zero-cluster feedback loop for validating telemetry during the inner dev loop and in E2E test workflows.
> h3. Scope
> * New test-infra module/service following the existing test-infra patterns (e.g. an {{*InfraService}}, {{*LocalContainerService}}, and {{*ServiceFactory}} for the {{grafana/otel-lgtm}} container).
> * Wire the new service into the {{camel-jbang-core}} {{infra}} command so {{camel infra run observability}} works like other {{camel infra run <service>}} commands.
> * Out of scope for this ticket: any changes to {{camel-observability-services}} itself, and cluster-side OpenShift/Kubernetes tooling (traits, {{camel kubernetes doctor}}, PodMonitor/PrometheusRule generation) -- those are separate, larger efforts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)