Federico Mariani created CAMEL-24051:
----------------------------------------
Summary: 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
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)
